dans une requête, est-il de performance due en faisant une clause where comme siQuestion de performances SQL (pas where vs où la colonne comme '%')
select bunchofstuff from sometable where column like '%'
vs
select bunchofstuff from sometable
bâtiment quelques requêtes dynamiques, juste curieuses. Merci.
sur SQL 2005, SP3 exécutant la commande suivante
set statistics io on
select * from sys.columns where name like '%'
set statistics io off
set statistics io on
select * from sys.columns
set statistics io off
suggère que le coût sera presque identique, puisque les deux renvoient le sam ensemble e résultat:
(1134 row(s) affected)
Table 'syscolpars'. Scan count 1, logical reads 50, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Commutation sur les plans de requête et/ou statistiques IO montre que select * from sys.columns where name like '%' est légèrement plus cher (51% du coût de la requête contre 49% pour select * from sys.columns), car il semble que le filtre est analysé et appliqué même si cela n'a aucun effet.
mais les ensembles de résultats peuvent être différents si la recherche sur une colonne qui permet des –
nulles, ce qui est probable si vous construisez tout votre SQL dynamique comme ceci –
Chaque fois que vous filtrez les résultats, la performance va être un peu plus lent (à moins, bien sûr, l'optimiseur de requêtes optimise à un vide like)
Mon hypothèse serait que, puisque ceci est une requête dynamique, il y a va être quelque chose après le joker. Selon la taille de la table, la clause générique like peut provoquer un léger ralentissement ou quelque chose de l'ordre de quelques secondes/minutes.
La plupart du temps il n'y aurait rien après la wild card. Je peux faire quelque chose comme où (param est null ou une colonne comme param + '%'), juste faire beaucoup de thèses, espérait faire juste une colonne où '%' si param n'a pas de valeur (par défaut à '') ne serait pas un coup de performance. On dirait que c'est pourtant. Je peux me permettre un peu de frappe supplémentaire je suppose :) – infocyde
ce sont des requêtes différentes et retourneront des résultats différents si la colonne en question autorise NULL!
si vous voulez toutes les lignes, il suffit de retirer le WHERE
Quand je suis SQL générateur de code et il est plus facile d'essayer d'insérer un no-op que d'essayer d'obtenir toutes les parenthèses et les principaux et les choses arrière droite - Je l'habitude d'utiliser quelque chose comme WHERE (0 = 1) OR ... ou WHERE (1 = 1) AND ...
Il y a un tas de facteurs à considérer:
HTH
Vous demandez nous une question qui vous êtes dans la meilleure position pour répondre. Nous n'avons aucune idée de l'aspect de votre environnement spécifique (base de données, système d'exploitation, configuration matérielle, configuration frontale, etc.).
Vous devez exécuter cette requête dans les deux sens et vérifier vous-même les performances, soit en synchronisant chaque requête, soit en utilisant les outils/options de profilage de votre base de données.
Il est vrai que les tests de performance de base de données peuvent être difficiles. Si vous n'êtes pas sûr de la façon de tester, vous pouvez poster une nouvelle question demandant comment tester la performance. Assurez-vous que vous êtes spécifique à propos de votre version de SGBD, car il s'agit généralement d'une base de données hautement spécifique.
La meilleure chose à propos de cette approche est que vous serez mieux équipé pour répondre à ce genre de questions dans le futur.
Ce que Cade Roux a écrit ... en cas de SP, vous auriez un paramètre: @ApplyFilter int
et dans votre instruction select vous auriez:
SELECT ....
WHERE
(@ApplyFilter = 1) and ....
De cette façon - Niveau d'application déciderait si le filtre est applicable et le transmettrait au SP. Ce qui précède retournera 0 lignes; si votre logique était de retourner toutes les lignes quand aucun filtre vous appliqué aurait:
SELECT ....
WHERE
(@ApplyFilter = 0) and ....
que vous attendez que à optimiser sur –