Où puis-je trouver des conseils sur les stratégies d'index?

La plupart d'entre nous conviendront probablement que l'utilisation d'index de base de données est une bonne chose. Trop d'index et de performances peuvent en fait être dégradés.

En règle générale, quels champs doivent être indexés?
Quels champs ne doivent pas être indexés?
Quelles sont les règles d'utilisation des index tout en trouvant un équilibre entre trop d'index et pas assez d'index pour réaliser des améliorations de performances, pas de dégradation?

Court

La règle "trop ​​d'index" est un peu trompeuse je pense.

Longue

Étant donné que la base de données moyenne est d'environ 98% des lectures (ou plus), les lectures doivent être optimisées. Un INSERT est une lecture s'il existe un index unique, par exemple. Ou le WHERE sur une mise à jour. J'ai lu une fois que même une base de données intensive en écriture est encore 85% de lectures.

Ce que vous avez, c'est une indexation de mauvaise qualité. Exemples:

• index en cluster larges (SQL Server en particulier)
• non groupé non monotone indexé
• index qui se chevauchent (par exemple cold, coleetcold, cole, colf)
• de nombreux index à colonne unique (qui se chevauchent également avec des index plus utiles) qui sont inutiles pour vos requêtes
• aucun INCLUDE, ne couvrant pas (par exemple tous les index à colonne unique)
• ...

Notez qu'il est assez courant d'avoir des index plusieurs fois plus grands que vos données réelles, même dans les systèmes OLTP.

En général, je commencerais par

• index clusterisé (généralement PK)
• des index uniques (pas des contraintes, ils ne peuvent pas couvrir)
• colonnes de clé étrangère

Ensuite, je regarderais:

• requêtes courantes et voir ce dont j'ai besoin. Une requête exécutée toutes les secondes doit être optimisée. Le rapport du dimanche à 4h du matin peut attendre.
• avec SQL Server, les DMV d'index manquants pondérés

Cela dit, j'ai enfreint ces règles pour certains systèmes après avoir vu comment les choses se déroulaient (10 milliards de lignes plus tard) pour régler un système. Mais je n'envisagerais jamais de ne pas indexer à moins que je puisse démontrer pourquoi je le fais.

Vous devez profiler l'utilisation et la charge de votre base de données et identifier les goulots d'étranglement dus à des index manquants - ou à un trop grand nombre d'index. Ensuite, vous devez choisir l'index approprié - et cela nécessite une bonne connaissance des techniques d'indexation de base de données spécifiques.

Tout simplement l'une des meilleures séries d'articles écrits sur les index à choisir et pourquoi serait par Gail Shaw. Vous pouvez retrouver les articles en cliquant ici

La question que vous posez peut recevoir une réponse de 50 manières différentes. Tout se résume vraiment aux données dont vous disposez et à la façon dont elles seront interrogées. Une règle générale est que vous devez toujours avoir un index cluster sur chaque table pour éviter les tas. Les index clusterisés doivent généralement être aussi petits que possible. Si la table a un index clusterisé, tous les enregistrements d'index sur les pages feuilles de l'index non clusterisé stockent la valeur d'enregistrement de l'index cluster respectif pour les recherches de signets. Si une table est un tas, SQL créera un identifiant unique pour les recherches de signets. Je ne me souviens pas de la taille, c'est 8 ou 16 octets. Cela pourrait finir par être un type de données beaucoup plus grand, puis dire un INT. Imaginez avoir 8 index non cluster sur une table de tas.

Je veux ajouter ici que différentes bases de données nécessitent des stratégies différentes. Comparons MySQL avec InnoDB et PostgreSQL par exemple.

InnoDB

Les tables InnoDB sont essentiellement un index b-tree de la clé primaire qui est étendu pour inclure les informations de ligne dans l'entrée d'index. Les analyses d'ordre physique ne sont pas prises en charge et toutes les analyses se déroulent dans un ordre logique. Cela signifie deux choses:

1. Un balayage séquentiel dans Innodb génère beaucoup d' E / S de disque aléatoires , et

2. L'index de clé primaire doit être parcouru, que l'on utilise ou non un index secondaire.

3. Les recherches de clé primaire sont plus rapides dans ce modèle que dans toute autre approche.

Dans ce cas, il est très important d'indexer suffisamment de champs dans les tables de plusieurs pages. La règle typique est d'indexer tout ce que vous souhaitez filtrer.

PostgreSQL

PostgreSQL utilise des fichiers tas, une table par fichier (certaines tables peuvent contenir plusieurs fichiers) où les tuples sont alloués à partir de l'espace libre de ce tas. Les analyses d'ordre physique sont prises en charge. Pour qu'une analyse de l'ordre logique fonctionne, un index doit être ajouté.

Les clés primaires de PostgreSQL sont essentiellement un sous-ensemble d'index uniques où aucune valeur ne peut être NULL. Les contraintes UNIQUES sont effectuées à l'aide d'index implicites, et plusieurs autres types d'index sont pris en charge avec différentes opérations possibles dans l'index.

Ça signifie:

1. Recherches de clé primaire, en supposant qu'une table relativement grande nécessite de frapper un fichier d'index et un fichier de table. C'est beaucoup plus lent que l'approche de MySQL où l'index doit uniquement être parcouru et la ligne est contenue dans l'index.

2. Les analyses d'ordre physique fonctionnent beaucoup mieux, réduisant les E / S de disque aléatoires où un nombre important de lignes doivent être traitées.

3. Les analyses d'index secondaire fonctionnent mieux que celles de MySQL car un seul index doit être parcouru pour accéder à la partie physique de la table.

Dans ce modèle, les index sont souvent nécessaires mais le planificateur a plus de liberté pour utiliser un index, et les implications de ne pas en utiliser un sont souvent moins graves. Les tables sont plus généralement optimisées (plutôt que de se spécialiser dans les recherches pkey) et donc moins d'index sont nécessaires.

TL; DR

Apprenez à connaître votre SGBDR.

Dans le manuel Oracle 11.2 Concepts Guide:

• Aperçu des index

Dans le Guide d'optimisation des performances 11.2:

• Choix des colonnes et des expressions à indexer
• Utilisation d'index et de clusters

Dans le Guide de l'administrateur 11.2:

• Lignes directrices pour la gestion des index

Même avec tous les liens ci-dessus, vous devez regarder ce que Kimberly Tripp a écrit concernant les soins, l'alimentation et l'utilisation des index.

Pour commencer, suivez ce lien vers la collection de Kimberly de ses articles de blog liés à l'index. Vous pouvez explorer des sujets spécifiques en utilisant les widgets "Sur cette page" et "Catégories" sur le côté gauche de la fenêtre de votre navigateur.

Il y a beaucoup d'informations ici, mais ne vous laissez pas intimider.

La page À propos de Kimberly est ici

Voici quelques ressources supplémentaires qui pourraient vous être utiles si vous travaillez avec SQL Server:

• http://www.toadworld.com/platforms/sql-server/w/wiki/9624.indexing.aspx
• http://www.sql-server-performance.com/category/tips/index/
• http://sqlfool.com/summit2010/
• http://sqlfool.com/2011/06/index-defrag-script-v4-1/