like ou substring ?

bonjour à tous,

question dont je ne trouve pas de réponse AFFIRMATIVE

quel est le plus rapide:

Code:

---

Select 1 from Table1 where champ1 like 'Z%'

---

ou

Code:

---

Select 1 from Table1 where substring(champ1,1,1)='Z'

---

De manière générale, le "LIKE" est considéré comme une fonction consommant beaucoup de ressource. La comparaison des méthode dépend des interventions que l'on souhaite effectuer et de la volumétrie des tables utilisées.

A mon avis l'utilisation du substring pourrait être plus efficiente.

Je viens d'avoir le support SYBASE (je ne me souvenais pas qu'on avait un compte chez eux :oops:)

dans les deux cas aucun index ne peut être utilisé mais

en fait il y a deux cas:
1° cas
si like avec un seul % exemple

Code:

---

SELECT 1 FROM Table1 WHERE champ1 LIKE 'X%'

---

il vaut mieux utiliser le like car l'optimiseur le transforme en

Code:

---

SELECT 1 FROM Table1 WHERE champ1 >='X' and champ1 < 'Y'

---

et donc peut utiliser un éventuel index
2° cas
si like avec un deux % exemple

Code:

---

SELECT 1 FROM Table1 WHERE champ1 LIKE '%X%'

---

il faut utiliser le charindex

Code:

---

SELECT 1 FROM Table1 WHERE charindex('X',champ1)> 0

---

voilà

moi je pencherais plus pour le like qui sera peut etre modifié selon ce qu'on en fait en quelque chose de mieux
le substring nécessitant à priori un balayage de table

Bonjour serge0934,

Pour ton exemple, les 2 ordres SQL seront de même performance (index ou non).
Effectivement il y a aura bien un balayage (MAIS de table ou d'index ).
(Donc le support Sybase a peut être mal compris ta question. peut être mal formulé ? ).

Si par contre tu modifie l'odre avec le substring

Code:

---

SELECT 1 FROM Table1 WHERE substring(champ1,2,1)='Z'

---

Là tu peux avoir une très grosse différence si un index était utilisable au départ.
Dans ce cas, pour le LIKE il y aura toujours un balayage de l'index alors que pour le SUBSTRING il y aura un balayage de table.

Attention (on va maintenant relativiser ;) ):
Le fonctionnement des optimiseurs est évidemment bien compliqué.
Pour rappel l'optimiseur SQL Server est de type CBO (il compare des coûts). Aussi, s'il estime que le coût d'un balayage de table est moins couteux que celui de l'index ... bein il y aura un table scan.
Et donc dans mon exemple modifié SUBSTRING(x,2,1) aura le même coût que le LIKE. (TABLE SCAN pour les deux)

Maintenant je vois venir ta question... Comment un balayage de table peut-il être préféré un balayage d'index ?
C'est fonction de la volumétrie de ta table, de ton ordre SQL , etc ...
Si par exemple tu fais un

Code:

---

SELECT * FROM Table1 WHERE champ1 LIKE 'Z%'

---

Il se peut que l'index qui pouvait être utilisé ne le soit pas (sauf index couvrant). le fait de demander tous les champs de la table oblige à servir tous les champs (via l'index ou index+table).
Dans ce cas un TABLE SCAN peut être appliqué.

Si le sujet t'interesse, je te recommande de regarder du coté optimiseur , plan d'éxécution et Index.

PS: un moyen de vérifier les coûts est de comparer les plans d'éxécution
Voila en espérant que cela soit clair

Bonjour,

Ce forum est consacré à Microsoft SQL Server, pas Sybase.
La réponse de Zeus est excellente, j'aimerai néanmoins ajouter un détail :

En utilisant une fonction dans l'opérande de gauche (où on spécifie la colonne), on modifie la valeur de la colonne, et donc aucun index ne peut être utilisé en seek, puisque la clé de l'index ne correspond à rien évalué dans l'expression de recherche.

Par contre, la construction LIKE 'Z%' n'empêche en rien l'utilisation d'un index, et même le seek. SQL Server sait combien de valeurs de clé commencent par Z. Si c'est suffisamment sélectif, l'index va être recherché.
Un LIKE '%Z%' par contre, ne peut pas à la base utiliser d'index. Mais il y a en SQL Server 2005 une optimisation sur le like, nommée résumés de chaînes (http://blogs.digineer.com/blogs/lara.../03/07/58.aspx), qui permet un meilleur choix d'index avec un LIKE '%...' dans certains cas.