Discussion :

[Donpi]

Bonjour,
en parcourant le net à la recherche d'information je me suis créer ce petit script que je trouve bien pratique pour analyser les indexes manquants dans certaines zones de programmes.

J'aimerais juste un avis sur l’interprétation des 3 dernières colonnes, notamment unique_compiles. Je visualise mal ce qu'est une compilation dans une requête, et par extension pourquoi le nombre de recherches n'est pas identique au nombre de compilations.

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
17
18
19
20
21
22
23
24
25
26
SELECT
	COUNT(*) OVER (PARTITION BY statement,mig.index_group_handle) AS NbColonnesIndex
	,NbCTbl.NbColonnes NbColonnesTotal
	,mig.index_group_handle,
	statement AS [database_scheme_table],
	column_id , column_name, column_usage,
	migs.user_seeks, migs.user_scans,
	migs.last_user_seek, migs.avg_total_user_cost,
	migs.avg_user_impact
	,migs.unique_compiles,migs.user_scans,migs.user_seeks
 
FROM		sys.dm_db_missing_index_details AS mid
INNER JOIN	sys.dm_db_missing_index_groups AS mig		ON mig.index_handle = mid.index_handle
INNER JOIN sys.dm_db_missing_index_group_stats AS migs	ON mig.index_group_handle=migs.group_handle
CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle)
cross apply(
		Select Count(*) NbColonnes from sys.columns C_ where C_.object_id=MID.object_id
	) NbCTbl
 
where statement like '%maBase%'
 
ORDER BY unique_compiles desc 
		,migs.avg_user_impact DESC
		,mig.index_group_handle
		,mig.index_handle
		,column_id

[elsuket]

Bonjour,

Lorsqu'on soumet une requête à SQL Server, celle-ci est transformée en un plan de requête, qui est le découpage en opérations physiques à réaliser par SQL Server pour résoudre la requête.
En outre, SQL Server procède à une estimation de cardinalité, c'est à dire qu'il estime le nombre de lignes qui va être retourné l'enchaînement des opérations, de façon a sélectionner la meilleure suite d'opérateurs physiques qui résoudra la requête en utilisant un minimum de ressources système.
Cette estimation se fait à l'aide de statistiques qui sont collectées et mises à jour sur tous les index, et sur les colonnes non indexées mais qui ont été filtrées.
Enfin une recompilation consiste pour SQL Server à recalculer le plan de requête, la plupart du temps suite à une mise à jour (automatique ou non) de statistiques impliquées dans la génération du plan.
Si vous voulez en savoir plus là-dessus, je vous invite à lire ce billet.

Ce qu'exposent les DMV d'index manquants est une estimation du gain qu'aurait pu procurer l'ajout de l'index suggéré. En aucun cas vous ne devez prendre la définition de tous ces index et les appliquer directement sur votre base de données. La majeure partie de ceux-ci ont des définitions qui méritent d'être revues (par exemples des colonnes de l'index cluster incluses dans un index non-cluster sur la même table), voire qui n'ont pas lieu d'être (comme un index (non filtré) sur une colonne de type bit, qui n'est pas sélective du tout).

La colonne unique_compiles indique donc le nombre de (re)compilations pour lesquelles l'optimiseur de requêtes a estimé que l'ajout de l'index serait bénéfique au plan de requête.

La colonne user_seeks indique le nombre de recherches de lignes qui auraient pu bénéficier de cette index, il en est de même pour user_scans, à la différence qu'il s'agit de parcours complets d'index.

Vous pouvez vous inspirer de ce billet que j'ai publié sur le sujet

@++

[Donpi]

Merci