Je ne connais pas les composants internes de Microsoft SQL Server, mais je peux répondre pour MySQL, que vous avez marqué pour votre question. Les détails peuvent varier pour d'autres implémentations.
Q1. Bon, aucun espace supplémentaire n'est nécessaire pour l'index clusterisé.
Que se passe-t-il si vous supprimez l'index cluster ? Le moteur InnoDB de MySQL utilise toujours la clé primaire (ou la première clé unique non nulle) comme index clusterisé. Si vous définissez une table sans clé primaire, ou si vous supprimez la clé primaire d'une table existante, InnoDB génère une clé artificielle interne pour l'index cluster . Cette clé interne n'a pas de colonne logique pour la référencer.
Q2. L'ordre des lignes renvoyées par une requête qui utilise un index non clusterisé n'est pas garanti. En pratique, c'est l'ordre dans lequel les lignes ont été accédées. Si vous avez besoin que les lignes soient renvoyées dans un ordre spécifique, vous devez utiliser ORDER BY dans votre requête. Si l'optimiseur peut déduire que l'ordre souhaité est le même que l'ordre dans lequel il accédera aux lignes (ordre d'indexation, que ce soit par index clusterisé ou non clusterisé), il peut ignorer l'étape de tri.
Q3. L'index non cluster InnoDB n'a pas de pointeur vers la ligne correspondante à une feuille de l'index, il a la valeur de la clé primaire. Ainsi, une recherche dans un index non clusterisé est en réalité deux recherches B-tree, la première pour trouver la feuille de l'index non clusterisé, puis une seconde recherche dans l'index clusterisé.
C'est le double du coût d'une seule recherche B-tree (plus ou moins), donc InnoDB a une fonctionnalité supplémentaire appelée Indice de hachage adaptatif . Les valeurs fréquemment recherchées sont mises en cache dans l'AHI, et la prochaine fois qu'une requête recherche une valeur en cache, elle peut effectuer une recherche O(1). Dans le cache AHI, il trouve un pointeur directement sur la feuille de l'index clusterisé, il élimine donc les deux Recherches B-tree, une partie du temps.
L'ampleur de l'amélioration des performances totales dépend de la fréquence à laquelle vous recherchez les mêmes valeurs que celles déjà recherchées. D'après mon expérience, le rapport entre les recherches avec hachage et les recherches sans hachage est généralement d'environ 1:2.
Q4. Construisez les index pour servir les requêtes que vous devez optimiser. Généralement, un index clusterisé est une clé primaire ou unique, et au moins dans le cas d'InnoDB, cela est nécessaire. Ni age ni salary est susceptible d'être unique.
Vous aimerez peut-être ma présentation, Comment concevoir des index, vraiment .
Q5. InnoDB crée automatiquement un index lorsque vous déclarez une contrainte d'unicité. Vous ne pouvez pas avoir la contrainte sans un index existant pour elle. Si vous n'aviez pas d'index, comment le moteur garantirait-il l'unicité lorsque vous insérez une valeur ? Il faudrait rechercher dans toute la table une valeur en double dans cette colonne. L'index permet de rendre les vérifications uniques beaucoup plus efficaces.
