Par exemple, si j'ai deux index:
CREATE INDEX IDX_1 ON MY_TABLE_1
(ITEM, DATE, LOCATION)
COMPUTE STATISTICS;
CREATE INDEX IDX_2 ON MY_TABLE_1
(DATE, LOCATION, ITEM)
COMPUTE STATISTICS;Serait-ce IDX_2redondant? Sinon, comment déterminer l'ordre de déclaration des colonnes?
Dois-je adapter les index aux requêtes régulières?
Oui, l'avantage survient lorsque vous souhaitez interroger une partie de l'index. Si vous placez d'abord les prédicats partiellement utilisés, l'index peut être utilisé pour les requêtes qui impliquent ces prédicats, mais pas toutes les colonnes de l'index.
De plus, à moins que vous n'ayez d'autres exigences, cela peut aider à placer les prédicats les plus sélectifs en premier, car cela peut réduire les opérations de recherche d'index plus rapidement.
Dans votre cas, ce IDX_2n'est pas nécessairement redondant selon la nature des requêtes sur la table. Cependant, il peut ne pas être nécessaire d'inclure toutes les colonnes. Si, par exemple, vous effectuez un grand nombre de requêtes avant locationet datepuis IDX_2peut être utile pour aider à résoudre ces requêtes car ce IDX_1n'est pas dans le bon ordre pour être utile pour cela. Vous pourriez cependant trouver que itemc'est redondant IDX_2.
À partir de 9i, Oracle a introduit un opérateur de «saut de balayage» où les colonnes d'index de fin peuvent être interrogées plus efficacement, ce qui peut réduire le besoin d'index supplémentaires de ce type.
Dans un cas plus spécifique, si vous interrogez itempar locationet dateet n'avez pas besoin d'autres colonnes, la requête peut être complètement résolue via l'index sans avoir à lire quoi que ce soit dans la table. Vous pouvez également créer des index de couverture auxquels des colonnes non indexées sont attachées. Si toutes les colonnes nécessaires peuvent être résolues à partir de l'index de couverture, la requête n'a pas du tout besoin de toucher la table principale.
Enfin, en réponse à votre dernière question: si vous avez un ensemble de requêtes régulièrement utilisées qui consomment beaucoup de ressources et pourraient être ajustées à l'aide d'un index, cela vaut certainement la peine d'être considéré. Cependant, la maintenance des index s'accompagne d'une surcharge sur les insertions, vous devrez donc échanger les performances des requêtes contre la surcharge que les index placent sur les opérations d'insertion ou de mise à jour.
Une autre chose à prendre en considération sont les colonnes avec beaucoup de valeurs nulles.
Si ces colonnes ont des colonnes spécifiées après elles dans l'index, les valeurs nulles doivent être indexées. Sinon, comme d'habitude, les valeurs nulles ne sont pas indexées (bien sûr, cela suppose que vous utilisez un index b-tree).
Donc, si vous avez des colonnes avec un grand nombre de valeurs nulles, les placer à la fin de l'index peut vous faire économiser une quantité importante d'espace disque.
la source