Index sur un Varchar?

Question

Nous sommes confrontés à de graves problèmes de verrouillage de la table en production. J'ai remarqué que j'ai créé une procédure stockée qui obtient une liste de commandes par numéro de commande. Le numéro de commande est un VARCHAR (150). Il n'y a aucun index de n'importe quel type sur cette colonne.

À l'heure actuelle, il existe beaucoup de valeurs NULL dans cette colonne. Cependant, au fil du temps (ce tableau est entré en ligne récemment), la table va croître de manière significative. Plus de valeurs NULL ne seront ajoutées à ce moment.

Ma question est double. Premièrement, un indice serait-il bénéfique ici? Le proc est très utilisé. Et si oui, devrait-il être regroupé ou non? Les données sont des choses comme CP123456, DR126512.

La deuxième question, qui influence probablement la première question est - serait-il avantageux de changer la colonne à un CHAR (10), car il semble que le numéro de commande est toujours la même taille. Y a-t-il un avantage de vitesse à mettre un index sur un CHAR à longueur fixe, par opposition à un VARCHAR (150)?

(La taille différente est due à des exigences inconnues lors de la création de la colonne).

SQL Server 2008.

Answer 1

1. Oui, absolument! Allez-y et ajoutez un index. La mise en cluster de l'index est probablement inutile ici, et ne sera pas possible de toute façon si vous avez déjà un autre index cluster (tel que la clé primaire) sur la table. La modification de la colonne en CHAR(10) peut présenter certains avantages en termes de taille de stockage, mais il est peu probable qu'elle fasse une différence particulièrement importante dans les performances de l'index. Je passerais ça pour le moment.

Answer 2

Je n'ai pas de références à citer à ce sujet, seulement une preuve d'expérience/anecdotique.

Tout d'abord, les requêtes peuvent presque toujours être améliorée grâce à l'utilisation des index. Le bénéfice exact dépend de la requête.
- Si une requête ne nécessite que des enregistrements spécifiques/une petite partie de la table, un indice aidera
- Si une requête nécessite toute la table, mais pourrait bénéficier de données ordonnées, un indice aidera

Les index clusterisés offrent généralement des avantages en termes de performances par rapport aux index non clusterisés. Dans un sens très simplifié, utiliser un index non clusterisé revient à utiliser deux tables et à les joindre (l'index convivial est utilisé en premier, qui est ensuite joint aux données elles-mêmes - sauf si l'index contient tous les champs de données nécessaires).

Une considération ici, cependant, est l'ordre dans lequel les données sont ajoutées à votre table. Si votre index clusterisé signifie que les données sont souvent insérées ou supprimées au milieu de la table, vous obtiendrez une fragmentation et d'autres artefacts. D'après mon expérience, cependant, la prise de conscience et la prise en compte de cela ne sont nécessaires que dans des situations extrêmes.

En bref, l'indice DEFINITIF vos données. Et l'index clusterisé est normalement le mieux placé pour répondre aux requêtes les moins performantes.

En ce qui concerne la différence entre VARCHAR et CHAR? Dans le passé, il était important de conserver des champs de longueur variable à la fin de vos données, afin de faciliter l'identification des champs de longueur fixe. Cela signifiait qu'avoir un champ VARCHAR comme premier champ, et l'utiliser comme identifiant unique, était plutôt mauvais.

De nos jours, la différence de performance est marginale. Personnellement, je garderais cependant des identifiants uniques comme étant de longueur fixe. Les données de longueur variable n'auront normalement pas de coûts de performance notables, mais lorsque vous effectuez des comparaisons pour les prédicats de jointure, etc., il est préférable d'avoir des champs de longueur fixe si possible.