Accepted answer

well to start with, i'd find out what query is being generated (in linq to sql you'd set the log on the data context) and then profile it in sql server management studio. play with it there until you've found something that is fast enough (either by changing the query or adding indexes) and if you've had to change the query, work out how to represent that in linq.

i suspect the problem is that you're combining orderby and take - which means it potentially needs to find out all the results in order to work out which the top 100 would look like. is code indexed? if not, try indexing that - it may help by allowing the server to consider records in the order in which they'd be returned, so it can stop after it's found 100 records. you should look at indexes for the other columns too.


the take(100) translates to "select top 100" etc. this would help if your problem was an otherwise huge result set, where there are a lot of columns returned. i bet though that your problem is a table scan resulting from the query. in this case, .take(100) might not help much at all.

so, the likely culprit is the same as if you were doing sql using how are your indxes? are the fields being searched fields for which you don't have good indexes? this would cause a drastic decrease in performance compared to queries that do utilize good indexes. add an index that includes code and name and see what happens. not using an index for code is guaranteed to hose you, because of the order by. also, what field links genealogy_accounts and genealogy_accountclass? a lack of index on either table could hose things. (i would guess an index including searchable is unlikely to help.)

use sql profiler to see the actual query being run (though you can do this in vs too), and to see how bad it really is on the server.

the problem might be linq doing something stupid generating the query, but this is probably not the case. we're finding linq-to-sql often makes better queries than we do. even if it looks goofy, it's usually very efficient. you can put the sql in query analyzer, and check out the query plan. then rewrite the sql to be more human-simple and see if it improve things -- i bet it won't. i think you'll still see a table scan, indicating something is wrong with your index.

Related Query

More Query from same tag