Le concept de Rowid :
rowid est une pseudo-colonne Puisqu'il s'agit d'une pseudo-colonne, cette colonne n'est pas définie par l'utilisateur, mais ajoutée par le système lui-même. Il existe une pseudo-colonne rowid pour chaque table, mais la valeur de la colonne ROWID n'est pas physiquement stockée dans la table. Cependant, vous pouvez l'utiliser comme n'importe quelle autre colonne, mais vous ne pouvez pas supprimer ou modifier la colonne, ni modifier ou insérer la valeur de la colonne. Une fois qu'une ligne de données est insérée dans la base de données, le rowid est unique pendant le cycle de vie de la ligne, c'est-à-dire que même si la ligne subit une migration de ligne, le rowid ne changera pas.
Pourquoi utiliser ROWID
rowid fournit la méthode d'accès la plus rapide à une ligne donnée dans une table. Le bloc de données correspondant peut être directement localisé via ROWID puis lu en mémoire. Lorsque nous créons un index, l'index stocke non seulement la valeur de la colonne d'index, mais stocke également le ROWID de la ligne correspondant à la valeur de l'index. De cette façon, après avoir trouvé rapidement le ROWID de la ligne correspondante via l'index, nous pouvons rapidement interroger les données via le ROWID. C'est pourquoi c'est plus rapide lorsque nous utilisons des requêtes d'index.
Dans les versions précédentes d'ORACLE8, ROWID était composé de FILE, BLOCK et ROW NUMBER. Avec l'expansion du concept d'objet dans Oracle8, ROWID a changé et se compose d'OBJECT, FILE, BLOCK et ROW NUMBER. Vous pouvez utiliser DBMS_ROWID pour décomposer le rowid en parties ci-dessus, ou vous pouvez combiner les parties ci-dessus en un rowid valide.
Concept SQL récursif Parfois, pour exécuter une instruction SQL émise par l'utilisateur, Oracle doit exécuter des instructions supplémentaires. Nous appelons ces instructions supplémentaires « appels récursifs » ou « instructions SQL récursives ». Par exemple, lorsqu'une instruction DDL est émise, ORACLE émet toujours implicitement des instructions SQL récursives pour modifier les informations du dictionnaire de données afin que l'utilisateur puisse exécuter avec succès l'instruction DDL. Les appels récursifs se produisent souvent lorsque les informations requises du dictionnaire de données ne se trouvent pas dans la mémoire partagée. Ces appels récursifs lisent les informations du dictionnaire de données du disque dur vers la mémoire. Les utilisateurs ne se soucient pas de l'exécution de ces instructions SQL récursives. ORACLE exécutera automatiquement ces instructions en interne en cas de besoin. Bien entendu, les instructions DML et SELECT peuvent provoquer du SQL récursif. En termes simples, nous pouvons considérer les déclencheurs comme du SQL récursif.
Source de la ligne
Utilisé dans les requêtes, l'ensemble de lignes qualifiantes renvoyé par l'opération précédente peut être un ensemble de toutes les données de ligne de la table ; il peut également s'agir d'un ensemble de données de lignes partielles de la table ou il peut s'agir d'un ensemble des deux données ci-dessus ; sources de lignes. Une collection de données de lignes obtenues après une opération de connexion (telle qu'une connexion de jointure).
Prédicat
WHERE contraintes dans une requête
Table de conduite
Cette table est également appelée table externe (OUTER TABLE). Ce concept est utilisé dans les jointures imbriquées et HASH. Si la source de ligne renvoie plus de données de ligne, cela aura un impact négatif sur toutes les opérations ultérieures. Notez que bien que cela soit traduit par table de pilotage, il est en réalité plus précisément traduit par source de ligne motrice. De manière générale, après avoir appliqué des restrictions de requête, la table avec moins de sources de lignes est renvoyée comme table pilote. Par conséquent, si une grande table a des restrictions (telles que des restrictions d'égalité) dans la condition WHERE, la grande table sera également utilisée comme table pilote. table. Approprié, ce n'est donc pas que seules des tables plus petites peuvent être utilisées comme tables de pilotage. L'instruction correcte devrait être qu'après avoir appliqué les contraintes de requête, la table qui renvoie moins de sources de lignes est utilisée comme table de pilotage. Dans le plan d'exécution, il doit s'agir de la source de la ligne supérieure. Des instructions spécifiques seront données plus tard. Dans notre description ultérieure, cette table est généralement appelée ligne source 1 de l'opération de jointure.
Table sondée (table sondée)
Cette table est également appelée table intérieure (INNER TABLE). Après avoir obtenu une ligne de données spécifique de la table des pilotes, nous recherchons les lignes de la table qui répondent aux conditions de jointure. La table doit donc être une grande table (en fait, elle doit être une table qui renvoie une source de lignes plus grande) et il doit y avoir des index sur les colonnes correspondantes. Dans notre description ultérieure, cette table est généralement appelée ligne source 2 de l'opération de jointure.
index combiné (index concaténé)
Un index composé de plusieurs colonnes, comme create index idx_emp on emp(col1, col2, col3, ...), alors nous appelons l'index idx_emp un index composite. Il y a un concept important dans l'index combiné : la colonne de tête. Dans l'exemple ci-dessus, la colonne col1 est la colonne de tête. Lorsque nous effectuons une requête, nous pouvons utiliser "where col1 = ?" ou "where col1 = ? et col2 = ?". De telles restrictions utiliseront l'index, mais la requête "where col2 = ?" Par conséquent, ce n'est que lorsque la première colonne est incluse dans la restriction que l'index combiné sera utilisé pour la restriction.
Sélectivité :
La comparaison du nombre de clés uniques dans une colonne avec le nombre de lignes du tableau détermine la sélectivité de la colonne. Si le rapport « nombre de clés uniques/nombre de lignes dans le tableau » de la colonne est plus proche de 1, la sélectivité de la colonne est plus élevée, la colonne est plus adaptée à la création d'un index, et la sélectivité de l'index est également plus élevé. Lors d'une requête sur des colonnes hautement sélectionnables, moins de données seront renvoyées, les requêtes d'index sont donc plus adaptées.
Une fois ces connaissances de base en place, nous commençons à présenter le plan d’exécution. Afin d'exécuter une instruction, Oracle peut devoir mettre en œuvre de nombreuses étapes. Chacune de ces étapes peut consister à récupérer physiquement les lignes de données de la base de données ou à les préparer d'une manière ou d'une autre pour être utilisées par l'utilisateur émettant l'instruction. La combinaison de ces étapes qu'Oracle utilise pour exécuter une instruction est appelée plan d'exécution. Le plan d'exécution est la partie la plus complexe et la plus critique de l'optimisation SQL. Ce n'est qu'en sachant comment ORACLE exécute l'instruction SQL en interne que nous pouvons savoir si le plan d'exécution sélectionné par l'optimiseur est optimal. Les plans d’exécution sont aussi importants pour les administrateurs de base de données que les états financiers le sont pour le personnel financier. Les principaux problèmes auxquels nous sommes confrontés sont donc : comment obtenir le plan d'exécution ; comment analyser le plan d'exécution pour découvrir les principaux problèmes affectant les performances. Ce qui suit commencera par analyser le plan d'exécution de l'arborescence, puis présentera comment obtenir le plan d'exécution, puis présentera comment analyser le plan d'exécution.
Exemple:
Cet exemple montre le plan d'exécution de l'instruction SQL suivante.
SELECT ename, job, sal, dname
DE emp, dept
OÙ emp.deptno = derpt.deptno
ET N'EXISTE PAS
(SÉLECTIONNER *
DE salgrade
OÙ emp.sal ENTRE losal ET hisal );
Cette instruction interroge le nom, le poste, le salaire et le nom du service de tous les employés dont le salaire ne se situe dans aucune des échelles salariales recommandées.
Cet article provient du blog CSDN Veuillez indiquer la source lors de la réimpression : http://blog.csdn.net/lcyhjx/archive/2009/12/20/5044672.aspx.