La plupart des conseils sont un moyen de communiquer notre intention à l'optimiseur. Par exemple, le leading l'indice que vous mentionnez signifie joindre les tables dans cet ordre . Pourquoi est-ce nécessaire ? C'est souvent parce que l'ordre de jointure optimal n'est pas évident, parce que la requête est mal écrite ou que les statistiques de la base de données sont inexactes.
Donc, une utilisation d'indices tels que leading est de déterminer le meilleur chemin d'exécution, puis de comprendre pourquoi la base de données ne choisit pas ce plan sans l'indice. La collecte de nouvelles statistiques résout-elle le problème ? La réécriture de la clause FROM résout-elle le problème ? Si tel est le cas, nous pouvons supprimer les indices et déployer le SQL nu.
Parfois, il y a des moments où nous ne pouvons pas résoudre cette énigme et devons garder les indices dans la production. Cependant, cela devrait être une rare exception. Oracle a eu beaucoup de personnes très intelligentes travaillant sur l'optimiseur basé sur les coûts pendant de nombreuses années, donc ses décisions sont généralement meilleures que les nôtres.
Mais il y a d'autres indices que nous ne voudrions pas voir dans Production. append est souvent crucial pour le réglage des inserts en vrac. driving_site peut être vital dans le réglage des requêtes distribuées.
A l'inverse d'autres indices sont presque toujours abusés. Oui parallel , Je parle de toi. Mettre aveuglément /*+ parallel (t23, 16) */ ne rendra probablement pas votre requête seize fois plus rapide, et il n'est pas rare qu'elle soit plus lente récupération qu'une exécution monothread.
Donc, en bref, il n'y a pas de conseil universellement applicable pour savoir quand utiliser des indices. Les éléments clés sont :
- comprendre le fonctionnement de la base de données, et en particulier le fonctionnement de l'optimiseur basé sur les coûts ;
- comprendre ce que fait chaque indice ;
- tester les requêtes suggérées dans un environnement de réglage approprié avec des données équivalentes à la production
De toute évidence, le meilleur endroit pour commencer est la documentation Oracle . Cependant, si vous avez envie de dépenser de l'argent, le livre de Jonathan Lewis sur l'optimiseur basé sur les coûts est le meilleur investissement que vous puissiez faire.
