Je veux juste mettre un mot d'avertissement :s'il vous plaît très attentivement choisissez votre index cluster ! Chaque table de données "normale" devrait avoir un index clusterisé, car avoir un index clusterisé accélère en effet beaucoup d'opérations - oui, accélérer , même des insertions et des suppressions ! Mais seulement si vous choisissez un bon index clusterisé.
C'est le le plus reproduit structure de données dans votre base de données SQL Server. La clé de clustering fera également partie de chaque index non clusterisé de votre table.
Vous devez faire preuve d'une extrême prudence lors de la sélection d'une clé de clustering - elle doit être :
-
étroit (idéalement 4 octets)
-
unique (c'est le "pointeur de ligne" après tout. Si vous ne le rendez pas unique, SQL Server le fera pour vous en arrière-plan, ce qui vous coûtera quelques octets pour chaque entrée multipliée par le nombre de lignes et le nombre d'index non clusterisés que vous avoir - cela peut être très coûteux !)
-
statique (ne jamais changer - si possible)
-
idéalement en constante augmentation vous ne vous retrouverez donc pas avec une horrible fragmentation d'index (un GUID est tout le contraire d'une bonne clé de clustering - pour cette raison particulière)
-
il devrait être non nullable et idéalement aussi de largeur fixe - un
varchar(250)fait une très mauvaise clé de clustering
Tout le reste devrait vraiment être le deuxième et le troisième niveau d'importance derrière ces points ....
Découvrez quelques-uns des articles de Kimberly Tripp (La reine de l'indexation ) articles de blog sur le sujet - tout ce qu'elle a écrit dans son blog est absolument inestimable - lisez-le, digérez-le - vivez-en !
- GUID en tant que CLÉ PRIMAIRE et/ou clé de clustering
- Le débat sur l'index clusterisé se poursuit...
- Clé de clustering en constante augmentation - le débat sur l'index clusterisé...encore !
- L'espace disque est bon marché - c'est pas l'essentiel !
