Discussion :

[camboui]

Supposons une table qui contienne un champ NAME et un index sur ce champ.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE INDEX my_index ON my_table (NAME)

Une requête comme celle qui suit va utiliser l'index:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM my_table WHERE NAME="Alexandre"

Maintenant j'aimerais faire des requêtes sur valeurs partielles (des préfixes pour être précis) mais je souhaite que l'index soit aussi utilisé, comme ceci par exemple,:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM my_table WHERE NAME="Alex%"

En retour j'obtiendrais tous les Alex, Alexandre, Alexandra, etc.

Techniquement parlant, rien ne l'empêche. En C il suffirait d'utiliser la fonction strncmp() au lieu de strcmp() pour faire des comparaisons (et donc des recherches) sur valeur partielle.

Est-ce possible de forcer SQL d'en faire autant ?
Merci.

[mikedavem]

Pas de besoin de forcer SQL en réalité.
L'optimiseur pourra utiliser l'index dans ce cas (mais dans votre requête il faut utiliser l'opération LIKE) :

Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE name
(
 nom varchar(50)
)
 
INSERT name VALUES ('TOTO')
GO 100000
 
INSERT name VALUES ('alex')
INSERT name VALUES ('alexandre')
INSERT name VALUES ('alexandra')
 
CREATE CLUSTERED INDEX PK_name
ON dbo.name ( nom )
 
SELECT * FROM name WHERE nom LIKE 'alex%'

++

[camboui]

C'est bon à savoir que même avec LIKE les index peuvent être utilisés !
D'habitude je vérifie mes requêtes avec le "execution plan" (Ctrl-M dans le menu "Query", désolé j'ai des softs en anglais). Est-ce suffisant pour vérifier dans ce cas ?

Merci !

[mikedavem]

Vous pouvez le vérifier avec le plan d'exécution réel également ou encore en utilisant les options SET STATISTICS IO pour voir le nombre de pages lues pour votre recherche ou scan d'index selon le cas

++

[SQLpro]

ATTENTION : votre jeu d'essais n'étant pas consistant il est probable que votre index ne soit pas utilisé et qu'il en résulte un SCAN de table !

En effet, pour faire des essais d'utilisation d'index il faut un volume de données et une distribution des données proche de la réalité, c'est à dire au moins quelques dizaines de milliers de lignes au minimum !

A +

[camboui]

OK m3rci mikedaven

J'ai d'autres questions à propos d'index qui sont un peu en marge du sujet initial, mais je les pose ici afin d'éviter d'ouvrir un nouveau sujet.

Quelle différence entre une "table" et un "index" du point de vue de l'écriture sur disque ?
En fait je voudrais constater qu'il n'y en a pratiquement aucune. Exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE my_table
(
 id INT,
 name VARCHAR(50)
)
 
CREATE CLUSTERED INDEX idx1_id ON my_table (id)
 
CREATE NON CLUSTERED INDEX idx2_name ON my_table (name) INCLUDE (id)

Si j'ai bien compris, il y a 2 B+tree qui seront créés sur disque et qui contiendront les mêmes données à peu de choses près. Toutes les paires (id, name) seront stockées en double, une fois ordonnées selon 'id' et l'autre selon 'name'. A partir du moment où un index est aussi stocké comme une table, pourquoi ne pourrions nous pas faire une requête de ce genre afin de voir le contenu d'un index ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from idx2_name

[camboui]

SQLpro,
Je ne donnais qu'un exemple pour illustrer mes propos sur le forum.

Mais je n'ai pas compris ton intervention. Les index ne sont utilisés que s'il y de gros volumes de données, sinon jamais ?

[Sergejack]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE my_table
(
 id INT,
 name VARCHAR(50)
)
 
CREATE CLUSTERED INDEX idx1_id ON my_table (id)
 
CREATE NON CLUSTERED INDEX idx2_name ON my_table (name) INCLUDE (id)

Normalement dans ce scénario, id serait une clé primaire.
Comme ça ne l'est pas j'ai un léger doute mais je pense qu'il est inutile d'inclure (clause INCLUDE) id dans le second index.
Car celui-ci serait d'office inclu (puisque c'est LUI qui permet de retrouver physiquement la ligne sur le disque).

Concernant votre question, si vous n'employez (sélection et filtre) d'une table des colonnes qui appartiennent toutes à un index, sql server va lire uniquement l'index.
Il est donc inutile (et encombrant) d'avoir une syntax SELECT ... FROM INDEX...