Existe-t-il un moyen de déterminer le meilleur moyen de savoir quels index créer pour une table?

Règles simples. (Certains d'entre eux sont créés automatiquement, mais peuvent éventuellement être supprimés manuellement ultérieurement, en fonction de votre dbms. Ne supposez pas que vous travaillerez toujours sur PostgreSQL.)

• Indexez chaque clé primaire.
• Indexer chaque clé étrangère.
• Indexez chaque colonne utilisée dans une clause JOIN.
• Indexez chaque colonne utilisée dans une clause WHERE.
• Étudiez votre documentation pour connaître les options d'indexation "ésotérique" prises en charge par votre dbms.

Chaque clé primaire signifie que les clés primaires multi-colonnes doivent avoir un seul index couvrant toutes les colonnes. PostgreSQL va créer cet index automatiquement si vous déclarez une clé primaire à plusieurs colonnes.

Il existe de nombreux cas dans lesquels un seul index multi-colonne offre de meilleures performances que plusieurs index à une seule colonne. Surveillez les requêtes lentes et effectuez des tests pour déterminer lequel est lequel.

Supposons que tout changement d'indexation améliore certaines activités de la base de données et en dégrade d'autres. Je trouve utile de disposer d'un ensemble d'instructions SQL que je peux profiler avant et après avoir modifié les index. Cet ensemble comprend les instructions SELECT, INSERT, UPDATE et DELETE.

Rien ne peut remplacer l’étude de la documentation pour votre dbms particulier.

• CRÉER UN INDEX
• Index (notez en particulier les sections sur les expressions d'indexation, sur les index partiels et sur l'examen de l'utilisation des index)

En plus de ce que @Catcall a déjà fourni , et pour ajouter un petit correctif:

J'ai également couvert quelques bases dans cette réponse étroitement liée à SO récemment .

Les réponses semblent jusqu'à présent indiquer que vous devez créer des index sur les clés primaires, mais ce n'est pas le cas dans PostgreSQL (des exceptions partielles s'appliquent). Je cite le manuel ici :

PostgreSQL crée automatiquement un index unique lorsqu'une contrainte unique ou une clé primaire est définie pour une table. L' index couvre les colonnes qui constituent la clé primaire ou la contrainte unique (un index multicolonne, le cas échéant), et constitue le mécanisme qui applique la contrainte.

Gras accent mien.

Vous souhaiterez peut -être créer des index supplémentaires pour la deuxième colonne ou les colonnes ultérieures d'un index multicolonne, mais le premier est généralement très bien couvert par un index multicolonne, sauf lorsque des colonnes supplémentaires l'agrandissent beaucoup. Nous avons discuté de cela en détail sous cette question connexe:

Un index composite est-il également utile pour les requêtes sur le premier champ?

Index multicolonnes , les index partiels et les index d'expressions sont des outils particulièrement puissants dans PostgreSQL. Depuis PostgreSQL 9.2, il existe également des analyses d'index seulement , l'équivalent de "couvrir les index" dans d'autres SGBDR. Ce n'est pas un autre type d'index, mais une nouvelle fonctionnalité du SGBDR avec les types d'index existants.

Chaque index induisant des coûts spécifiques , il n’existe donc aucune connaissance de base permettant d’optimiser réellement l’indexation. Créer plus d'index peut faire plus de mal que de bien. En particulier, les index peuvent empêcher les mises à jour HOT d'améliorer les performances.

Généralement, écrivez des opérations (DELETE , UPDATE) deviennent plus chères (mais peuvent aussi en bénéficier!), Alors que les opérations de lecture ( SELECT) en bénéficient généralement. Trop d'index peuvent épuiser la mémoire cache, de sorte que même les opérations de lecture peuvent en souffrir.

Enfin, cette page Wiki de Postgres sur la maintenance des index propose des outils pour rechercher les index en double ou inutilisés (entre autres).

Il y a deux options.

1. Tu le fais.
2. La technologie le fait.

La solution pour le faire vous-même est assez documentée ici. Alors regardons quelque chose d'autre.

Pghero

Pghero pourra peut-être vous aider si vous souhaitez des conseils automatisés.

Cela dit, il y a des lacunes.

1. Cela ne fonctionne que sur WHEREet ORDER BY, non JOINS.
2. Il utilise uniquement des statistiques sur le pourcentage NULL et des valeurs distinctes.

Regardez cette vidéo pour plus d'informations .