La plupart des bases de données d'entreprise, y compris Oracle, utilisent un optimiseur basé sur les coûts pour déterminer le plan de requête approprié pour une instruction SQL donnée. Cela signifie que l'optimiseur utilise des informations sur les données pour déterminer comment exécuter une requête plutôt que de s'appuyer sur des règles (c'est ce que faisait l'ancien optimiseur basé sur des règles).
Par exemple, imaginez un tableau pour une simple application de suivi des bogues
CREATE TABLE issues (
issue_id number primary key,
issue_text clob,
issue_status varchar2(10)
);
CREATE INDEX idx_issue_status
ON issues( issue_status );
Si je suis une grande entreprise, je pourrais avoir 1 million de lignes dans ce tableau. Parmi ceux-ci, 100 ont un issue_status
sur ACTIVE, 10 000 ont un issue_status
de FILE D'ATTENTE et 989 900 ont le statut TERMINÉ. Si je veux exécuter une requête sur la table pour trouver mes problèmes actifs
SELECT *
FROM issues
WHERE issue_status = 'ACTIVE'
l'optimiseur a le choix. Il peut soit utiliser l'index sur issue_status
puis effectuez une recherche sur une seule ligne dans la table pour chaque ligne de l'index qui correspond ou il peut effectuer une analyse de table sur les issues
table. Le plan le plus efficace dépendra des données contenues dans le tableau. Si Oracle s'attend à ce que la requête renvoie une petite fraction des données de la table, l'utilisation de l'index serait plus efficace. Si Oracle s'attend à ce que la requête renvoie une fraction substantielle des données de la table, une analyse de la table serait plus efficace.
DBMS_STATS.GATHER_TABLE_STATS
est ce qui rassemble les statistiques qui permettent à Oracle de faire cette détermination. Il indique à Oracle qu'il y a environ 1 million de lignes dans la table, qu'il y a 3 valeurs distinctes pour le issue_status
colonne et que les données sont inégalement réparties. Oracle sait donc utiliser un index pour la requête afin de trouver tous les problèmes actifs. Mais il sait aussi que lorsque vous vous retournez et essayez de rechercher tous les problèmes résolus
SELECT *
FROM issues
WHERE issue_status = 'CLOSED'
qu'il sera plus efficace de faire un balayage de table.
La collecte de statistiques permet aux plans de requête de changer au fil du temps à mesure que les volumes de données et les distributions de données changent. Lorsque vous installez le suivi des problèmes pour la première fois, vous aurez très peu de problèmes TERMINÉS et plus de problèmes ACTIFS et EN ATTENTE. Au fil du temps, le nombre de problèmes TERMINÉS augmente beaucoup plus rapidement. Au fur et à mesure que vous obtenez plus de lignes dans la table et que la fraction relative de ces lignes qui se trouvent dans les différents statuts change, les plans de requête changent de sorte que, dans le monde idéal, vous obtenez toujours le plan le plus efficace possible.