Oracle
 sql >> Base de données >  >> RDS >> Oracle

Pourquoi Oracle utilise-t-il DBMS_STATS.GATHER_TABLE_STATS ?

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.