Un premier post qui j’espère me conduira à une série sur l’indexation dans SQL Server. Je traiterai les points un peu dans le désordre mais n’est-ce pas là l’attrait d’un blog ? Je sais que je ne commence pas par les bases mais bon, j’attend vos questions :-).

Un index de type HEAP indique en réalité le fait qu’il n’y ait aucun index sur la table et surtout pas d’index CLUSTERED. C’est à dire que seul le CREATE TABLE a été exécuté, sans aucune option, sans PRIMARY KEY.

Cela signifie que les données sont rangées n’importe comment ou plutôt dans l’ordre de leur création. C’est comme si je prenais un annuaire et que je mélangais les villes et les noms.

La conséquence d’avoir ce type d’indexation dans sa base de données est très souvent d’avoir des performances catastrophiques lors de la selection de données. D’autant plus quand la volumétrie augmente. Ceci vient du fait que l’opération qui est faite sur la table pour récupérer un jeu d’enregistrement est un TABLE SCAN (aussi appelé Full Scan).

Pour en revenir à mon annuaire, c’est comme si je vous demandais de me trouver toutes les personnes qui habitent au 12, rue des saules, quelque soit la ville. Vous seriez obligé de lire (scanner) toutes les pages.

Pour limiter cela, on peut mettre un index clustered ou une PRIMARY KEY (équivalent d’un index unique non null) pour optimiser la recherche.

Pour retrouver toutes les tables concernées :

select OBJECT_NAME(sys.indexes.object_id)
from sys.indexes
  inner join sys.tables on sys.tables.object_id = sys.indexes.object_id
where sys.indexes.[type] = 0 --0 = HEAP

Donc faite un petit check-up de vos bases et vérifier vos tables stockées sur un index HEAP… Et pourquoi pas les mettre sur un index CLUSTERED… mais je reviendrai sur ce point 😉