La requête SQL et le paramètre datetime prennent beaucoup de temps à s'exécuter

Question

J'ai une requête qui prend datetime comme paramètre, ce que nous avons observé est que si vous fournissez le paramètre datetime à travers une variable, Query prend 2 à 3 fois plus de temps à exécuter que si vous le paramètre directement coder en dur, est-il une raison quelconque ou d'une solution à ce

Après requête prend environ 5 minutes pour retourner le résultat

Declare @Date as DateTime 
Set @Date = '01/01/2009' 

Select * from TempTable where effdate = @Date 

Alors que

Select * from TempTable where effdate = '01/01/2009' 

il revient en 10-20 sec

Ce n'est pas toujours que j'aurais index sur la colonne en utilisant ce que je veux faire la recherche. Comme recommandé par kevchadders, j'ai vu une énorme différence dans le plan d'exécution. La requête avec la variable de date effectuait l'analyse d'index en cluster et l'autre effectuait une recherche d'index.

Answer 1

J'ai déjà vu cela, et je l'ai fait en utilisant une table de paramètres plutôt qu'une variable.

if object_id('myParameters') is not null drop table myParameters 
Select cast('1996-05-01' as datetime) as myDate into myParameters 

Select * from TempTable where effdate = (select max(myDate) from myParameters) 

Answer 2

Avez-vous regardé le plan d'exécution sur les deux pour voir si cela apporte des indices?

Answer 3

Avec une telle requête simple, l'heure de retour devrait être beaucoup, BEAUCOUP plus bas. Essayez d'exécuter la requête avec EXPLAIN, c'est-à-dire EXPLAIN Select * from TempTable where effdate = '01/01/2009'. Si aucun index n'est utilisé, vous devez en ajouter un (see the web for a tutorial lors de l'optimisation de la requête).

CREATE INDEX 'date_index' ON `TempTable` (`effdate`); 

Il est pas tout à fait clair pour moi pourquoi la variable prend plus de temps, mais ayant un indice devrait accélérer suffisamment la requête pour faire la différence négligeable.

Answer 4

Vous devriez regarder le plan d'exécution des requêtes pour voir s'il y a une différence. Ils doivent avoir exactement la même apparence, dans ce cas, il n'y a aucune différence dans l'exécution des requêtes, et toute différence de performance est due aux requêtes que la base de données a mises en cache depuis.

Même 30-40 secondes, c'est beaucoup pour une requête aussi simple. Si vous avez un index sur le champ, vous devriez obtenir le résultat en quelques secondes même pour une très grande table.

Pour la requête actuelle, vous devez bien sûr spécifier les champs que vous souhaitez renvoyer au lieu d'utiliser "select *". En ne renvoyant que les données dont vous avez réellement besoin, vous pouvez réduire la quantité de données envoyées par le serveur de base de données. Dans cette requête par exemple, vous savez quelle sera la valeur du champ effdate pour toutes les lignes du résultat, il n'est donc pas nécessaire de le renvoyer.

Answer 5

Le suspect habituel est un défaut de type de données, ce qui signifie que la colonne est smalldatetime ou varchar. "Datetime" a une priorité plus élevée de sorte que la colonne sera convertie.

Answer 6

Cela peut être un problème de «reniflage de paramètres». Essayez d'inclure la ligne:

OPTION (RECOMPILE) 

à la fin de votre requête SQL.

Il y a un article expliquant ici ce reniflement paramètre est: http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx