Est-il mauvais d'avoir un espace d'index plus grand que l'espace de données?
Souvent, je dois exécuter des requêtes sur de grandes tables qui n'ont pas le bon index. Je demande donc au DBA de créer un tel index. La première chose qu'il fait est de regarder les statistiques de la table et de voir la taille de l'espace d'index.
Souvent, il me disait de trouver une solution alternative car "l'indice est déjà plus grand que le tableau". Il pense que l'index doit être plus petit que les données, car, m'a-t-il dit, "avez-vous déjà vu l'index dans un livre? Il est beaucoup plus petit que le livre lui-même, et c'est ainsi qu'un index de table devrait être".
Je ne pense pas que sa philosophie soit correcte, mais je ne peux pas le contester car il est un DBA principal et je suis développeur. Je pense que si une requête a besoin d'un index, l'index doit simplement être créé, au lieu de trouver des "solutions de contournement" qui rendent les SP illisibles et non maintenables.
Je sélectionne uniquement les colonnes requises. Le problème est que je filtre par date, le moteur effectuera donc nécessairement une analyse de table pour correspondre aux colonnes. La requête s'exécute une fois par jour, la nuit, pour recueillir des statistiques, mais son exécution prend 15 minutes (nous avons une autre règle stricte et rapide: aucune procédure ne devrait prendre plus de 3 minutes).
Le DBA m'a montré les statistiques de l'indice. Il y avait environ 10 index sur cette table, dont seulement 6 ont été utilisés (les statistiques ont montré zéro hit pour 4 d'entre eux). Il s'agit d'un grand système auquel participent plus de 20 développeurs. Les index ont été créés pour une raison quelconque et ne sont probablement plus utilisés.
Nous devons prendre en charge SQL Server 2008, car c'est sur cela que les bases de données de test s'exécutent. Mais les clients sont tous sur 2014 et 2016.
Pensez à la conception d'index comme à un interrupteur coulissant. Vous pouvez déplacer ce bouton de commutation de triangle rouge n'importe où le long de la ligne souhaitée:
Je ne le mesure généralement pas en termes de taille - je pense généralement en termes de quantité d'indice, mais la taille conviendrait également.
Il semble que votre administrateur de base de données pense que le commutateur est trop à droite - que vous avez ajouté trop d'index et que les suppressions/mises à jour/insertions fonctionnent trop lentement.
Plutôt que de discuter de l'emplacement du commutateur, essayez de lui poser des questions sur les problèmes de performances que vous rencontrez en raison du nombre élevé d'index. Peut-être que vos utilisateurs se plaignent de la vitesse de suppression/mise à jour/insertion, ou qu'il voit des verrous attendre, ou qu'il a du mal à sauvegarder la base de données en raison de sa taille.
Mon point de départ est généralement 5 et 5: environ 5 index par table, avec environ 5 champs ou moins par index. Ce nombre n'a rien de magique - il vient du fait que j'ai 5 doigts sur chaque main, il est donc facile de tenir mes mains et d'expliquer la règle.
Vous devrez peut-être avoir de nombreux index MOINS de 5 lorsque votre charge de travail est fortement biaisée vers les opérations de suppression/mise à jour/insertion, et que vous n'avez pas assez de puissance matérielle pour suivre.
Vous pouvez avoir de nombreux index PLUS lorsque votre charge de travail est principalement en lecture seule ou lorsque vous investissez massivement dans du matériel (comme mettre en cache la base de données entière en mémoire et avoir tout le stockage à semi-conducteurs en dessous).
J'aime la réponse de Brents et j'ai voté pour. Je voudrais cependant ajouter une autre perspective. J'ai travaillé en tant qu'utilisateur, développeur et DBA et je pense que les opinions ne sont pas pertinentes. Je pense qu'il appartient à l'utilisateur (ou à la partie prenante) de décider du fonctionnement d'une requête et du temps nécessaire pour obtenir des résultats. Il appartient ensuite au développeur et au DBA de travailler ensemble pour y arriver.
Si le poste DBA dans votre entreprise est "en charge" de ce sujet, il peut analyser votre requête et faire des suggestions sur une meilleure conception de la requête ou répondre aux performances.
Si la requête et/ou la structure des données ne peuvent pas être modifiées pour atteindre l'objectif, je pense que cela se résume à trois choix.
- Récupération lente des données
- Mise à jour lente des données
- Plus de ressources matérielles $$$$
Bien sûr, chaque situation a de nombreuses variables en fonction de multiples facteurs commerciaux et technologiques, mais je pense que les trois options s'appliquent à la plupart, sinon à tous les cas.
De plus, le désir d'avoir plus que "The Ozar 5" index sur une table indique probablement que vous avez beaucoup de différents types de requêtes lourdes en lecture sur le table.
Ce qui indique probablement que vous pourriez bénéficier d'un cluster ou non index columnstore sur la table.
Au lieu d'avoir l'index optimtimal pour chacun des N chemins d'accès différents, un magasin de colonnes vous offre une analyse ultra-rapide et la possibilité d'ignorer les colonnes inutiles et les segments de ligne. Vous pouvez donc avoir un petit nombre d'index BTree pour les transactions super-critiques et revenir au magasin de colonnes pour tout le reste.
Les index Columnstore sont conçus pour fonctionner dans des charges de travail lourdes OLTP avec SQL Server 2016+. Voir la documentation pour Analyses opérationnelles en temps réel .
Semble trop strict pour interdire les index> table. Si votre table change rarement (ou change la nuit quand il n'y a pas beaucoup de concurrence pour les ressources) et qu'elle est beaucoup interrogée de nombreuses manières différentes, de nombreux gros indices peuvent être justifiés. Les administrateurs de base de données doivent également veiller à ne pas coller leur nez là où il n'appartient pas. S'il vous donne/votre système une limite de gigaoctets, il ne devrait pas trop se soucier de la façon dont cet espace est utilisé. S'il est surmené, c'est peut-être pourquoi.
Cependant, il y a beaucoup de choses à considérer:
- De nombreux index ralentissent les insertions/mises à jour/suppressions. Donc, si votre table change beaucoup, faites attention de ne pas en faire trop.
- L'espace peut aussi être un problème. Non seulement parce que les gigaoctets coûtent de l'argent (pas beaucoup de nos jours), mais aussi du temps car la sauvegarde sera plus lente (selon la façon dont la sauvegarde est effectuée).
- La plupart des bases de données sérieuses peuvent être surveillées pour trouver des index rarement ou jamais utilisés. Pensez à en supprimer certains.
- Parfois, vous pensez avoir besoin d'un index, mais lorsque vous examinez votre requête de plus près, elle peut être réglée et réécrite différemment avec le même résultat et sans avoir besoin de l'index. Utilisez le plan d'explication pour voir si l'index est utilisé ou non.
- Parfois, la ou les dernières colonnes peuvent être supprimées d'un index multi-colonnes sans trop de performances. Et parfois, cela peut même rendre les requêtes plus rapides car l'espace de stockage d'index est plus petit et une plus grande partie de l'index sera conservée/mise en cache en mémoire à tout moment.
- Les index basés sur les fonctions peuvent remplacer les index normaux pour économiser plus d'espace. Exemple: au lieu de rechercher le nom complet, recherchez également les deux premières lettres (
where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) etcreate index i on customers(substr(surname,1,2)). Cela pourrait être assez rapide et votre index sera plus petit. - Les bases de données prennent en charge différents types d'index. Certains types utilisent moins d'espace que d'autres. Peut-être que certains de vos index peuvent être convertis en un type moins gourmand en espace? Assurez-vous d'abord de comprendre les différents types d'index et les situations dans lesquelles ils sont bons et mauvais.
- Si un travail par lots peu fréquent est la seule chose qui nécessite un index spécifique, envisagez de créer cet index uniquement pour ce travail par lots et supprimez-le ensuite.