Discussion :

[Boubou2020]

Bonjour a tous

Aujourd’hui j'ai pensé a faire un petit test pour faire voir comment optimiser et retirer l'opération Lookup RID
pour cela j'ai pensé a crée ce scénario ,créer un table nommé source avec un index cluster

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE [dbo].[source](
	[id] [bigint] IDENTITY(1,1) NOT NULL,
	[nom] [varchar](50) NOT NULL,
	[Quantité] [int] NOT NULL,
	[pren] [nvarchar](50) NULL,
 CONSTRAINT [PK_source] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO

Maintenant, j'ai lancer l'opération select et j'ai vérifier leur plan d'exécution

Code :

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

1
2
3
4
5
6
7
/****** Script de la commande SelectTopNRows à partir de SSMS  ******/
SELECT TOP 1000 [id]
      ,[nom]
      ,[Quantité]
      ,[pren]
  FROM [lookup_ssis].[dbo].[source]
  where nom='Abdallah'

-->voir imprime écran 1
vu qu'n index cluster est créé sur la table Il est clair que l'optimiseur du requête a pris le choix de faire un balayage d'index cluster
ensuite j'ai penser a crée un index NONCLUSTERED sur la colonne qui contient la clause where qui dans mon cas le colonne nom

Code :

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

1
2
3
4
5
  CREATE NONCLUSTERED INDEX [IX_OneIndex_nom] ON [dbo].[source]
(
[nom] ASC
) ON [PRIMARY]
GO

Après la création de l'index non-cluster, j'ai penser a lancer du nouveau mon select et vérifions le plan d'exécution , je viens de trouver que l'optimiseur a choisit de faire une autre fois un scan du mon index cluster
alors ma question pourquoi l’optimiseur du requête n'a pas pris en considération mon index noncluster surtout qu'il contiens le colonne de la clause where pour récupérer les données de la table surtout que j'attendais comme un plan d’exécution avec une opération de type seek index sur l'index noncluster avec une opération lookup RID pour les colonnes utilisées dans la clause SELECT et qui ne sont pas encore partie de mon index non cluster
merci pour notre expert

[aieeeuuuuu]

Bonjour,

Combien de lignes contient votre table ?
si elle n'en contient que très peu, alors ce comportement est normal : il sera plus couteux de faire un recherche d'index puis un lookup que de lire directement l’unique page que contient la table et de faire le filtre : l'index n'est pas assez discriminant puisqu'au final, 100% des lignes (si votre table n'a qu'une seule ligne) correspondent au filtre.

Ajoutez des lignes dans votre table qui ne vérifient pas le filtre, l'index sera alors utilisé

[Boubou2020]

veuillez m'excuser pour cet oubli , le nbre des lignes pour le tableau est faible donc c'est normal pour ce comportement

Je vous remercie pour l'intérêt que vous avez donné à mon sujet