Indexation d'un identificateur unique et des performances

Question

J'ai une requête qui était en haut de mon moniteur d'activité en tant que requête la plus coûteuse avec une durée moyenne> 18 000 ms. Ma table est actuellement à 2 533 081 lignes. Mon index est sur une autre colonne bigint, que j'ai générée pour que je puisse avoir un index unique en cluster. Le GUID est un type de données uniqueidentifier dont je n'ai aucun contrôle (provient d'une interface) et la décision de conception a été prise il y a une dizaine d'années.

Malheureusement, la requête de mise à jour nécessitait de vérifier le GUID (identifiant unique). C'est celui qui cause des problèmes de performance maintenant après 2 mois d'exécution. Le seul paramètre que je reçois pour la réinitialisation est le GUID, donc je ne peux pas utiliser la date, l'heure ou tout autre paramètre pour réinitialiser l'enregistrement du journal.

update Log 
set reset = @sockettime 
where guid = @guid 
and reset is null 

J'ai créé hier sur le GUID uniqueidentifier seulement un second indice nonclustered, et il est revenu à la performance de retour encore une fois un bon niveau.

Ce que je veux demander dans ce forum est: qu'est-ce qui s'oppose à la création d'un tel second index sur uniqueidentifier? Que dois-je faire pour maintenir les performances de l'index uniqueidentifier?

Merci d'avance.

Answer 1

Je ne vois rien de mal à créer le second index. Le guid a parfait cardinality. La recherche en utilisant un tel index est parfaite. En ce qui concerne la maintenance, il n'y a rien de spécial - comme n'importe quel autre indice. Si vous effectuez beaucoup de suppressions, certaines reconstruire ou réorganiser ne feront pas de mal de temps en temps. Vous pouvez trouver une procédure de maintenance prête à l'emploi sur Internet ou peut-être même en avoir une appliquée et vous ne la connaissez même pas.