Filtres LinqToSQL DateTime?

Question

J'ai un filtrage de requête linqtosql et un ordre par un colonne de données qui prend 20 secondes pour s'exécuter. Lorsque j'exécute la sqlquery générée directement sur la base de données, elle retourne 0 seconde.

var myObjs = DB.Table 
.Where(obj => obj.DateCreated>=DateTime.Today) 
.OrderByDescending(obj => obj.DateCreated); 

La table contient seulement 100 000 enregistrements et la colonne DateHeure est indexée.

Juste un autre dans une longue lignée de griefs de performance linqtosql. Mais celui-ci est tellement mauvais que je suis sûr que je dois faire quelque chose de mal.

Answer 1

Je suppose que la différence est que même si l'exécution de la requête générée ne prend que 0 secondes, c'est parce qu'elle ne vous montre pas tous les résultats si vous utilisez quelque chose comme Enterprise Manager. Le simple fait de récupérer (et de désérialiser) toutes les données pour 100 000 résultats peut prendre beaucoup de temps, mais votre requête manuelle ne vous montre probablement que les 20 premiers résultats ou quelque chose de similaire.

Si vous exécutez le même SQL dans .NET et utilisez un DataReader pour récupérer toutes les données, combien de temps cela prend-il alors?

Si vous exécutez le serveur avec le profilage activé, combien de temps la requête a-t-elle pris pour s'exécuter de LINQ vers SQL?

Answer 2

Je ne vois rien de mal dans votre requête. Ce serait génial de voir le T-SQL généré par Linq. Avez-vous essayé cela?

Answer 3

Merci les gars ...

Le problème des mines était pas LINQ de. Par souci de brièveté, j'ai raccourci la requête dans la question mais il y avait en fait un autre filtre qui avait été appliqué à une colonne NON indexée. L'ajout de l'index a résolu le problème. Ce qui m'a traversé une boucle, c'est que, comme Jon Skeet l'a suggéré, exécuter la requête dans Sql Mgmt studio a donné un faux sentiment de confiance parce que la requête a été paginée, et très rapidement retourné les 20 premières lignes, me laissant pense que Linq était à blâmer. Donc, le problème d'index n'apparaissait que dans linq et non dans sql mgmt studio.