Невозможно понять SQL Explain Plan

Question

В настоящее время я работаю над оптимизацией запросов, которая занимает много времени. Когда я googled, я обнаружил, что мы можем проверить производительность запроса, используя sql Explain Plan, ниже - план, который я получил для моего запроса, но я не могу понять, что именно он говорит.!

SELECT STATEMENT ALL_ROWS Cost: 13 Bytes: 187 Cardinality: 1 
     15 NESTED LOOPS Cost: 13 Bytes: 187 Cardinality: 1 
      12 NESTED LOOPS Cost: 11 Bytes: 163 Cardinality: 1 
       9 NESTED LOOPS Cost: 10 Bytes: 146 Cardinality: 1 
        6 MERGE JOIN CARTESIAN Cost: 8 Bytes: 59 Cardinality: 1 
         2 TABLE ACCESS BY INDEX ROWID TABLE QUAD.GROUP_ Cost: 4 Bytes: 27 Cardinality: 1 
          1 INDEX SKIP SCAN INDEX (UNIQUE) QUAD.IX_5BDDB872 Cost: 3 Cardinality: 1 
         5 BUFFER SORT Cost: 4 Bytes: 32 Cardinality: 1 
          4 TABLE ACCESS BY INDEX ROWID TABLE QUAD.USER_ Cost: 4 Bytes: 32 Cardinality: 1 
           3 INDEX SKIP SCAN INDEX (UNIQUE) QUAD.IX_C5806019 Cost: 3 Cardinality: 1 
        8 TABLE ACCESS BY INDEX ROWID TABLE QUAD.IGIMAGE Cost: 2 Bytes: 87 Cardinality: 1 
         7 INDEX RANGE SCAN INDEX QUAD.IX_BE79E1E1 Cost: 1 Cardinality: 1 
       11 TABLE ACCESS BY INDEX ROWID TABLE QUAD.IGFOLDER Cost: 1 Bytes: 17 Cardinality: 1 
        10 INDEX UNIQUE SCAN INDEX (UNIQUE) QUAD.SYS_C00117581 Cost: 0 Cardinality: 1 
      14 TABLE ACCESS BY INDEX ROWID TABLE QUAD.IMAGE Cost: 2 Bytes: 24 Cardinality: 1 
       13 INDEX UNIQUE SCAN INDEX (UNIQUE) QUAD.SYS_C00117585 Cost: 1 Cardinality: 1 

Пожалуйста, дайте мне знать, как это работает и что-то не так с этим выходом?

select ig.largeimageid, ig.groupId, ig.createDate, ig.modifiedDate, ig.folderId, ig.name, ig.imageid, 
ig.description, im.type_, im.height, im.width, im.size_, 
g.name groupname, u.screenname cecuserid, u.firstname, u.lastname, 
fo.name folderName, fo.description folderDesc 
from quad.igimage ig,quad.image im, quad.group_ g, quad.user_ u, quad.igfolder fo 
where ig.groupid= g.groupid 
and u.userid = ig.userid 
and fo.folderid=ig.folderid 
and ig.largeimageid= im.imageid 
and u.screenname='xyz' 
and g.friendlyurl = '/xyz'; 

Answer 1

Oracle использует Optimizer, чтобы определить наиболее эффективный план выполнения. Имейте в виду, что он принимает решения на основе статистической информации . Это означает, что должна быть адекватная статистика. В плане выполнения показаны подробные шаги для выполнения вашего оператора. Таким образом, SELECT первой строки является вашим фактическим запросом. Стоимость этого выбора равна 13, что на самом деле является стоимостью вложенных операций. мощность вашего запроса является 1. Четыре ключевых элементами плана выполнений являются следующими:

1. Cardinality: оценка по количеству строк каждой операции.
2. Метод доступа: Доступ к вашим данным. Может быть сканирование таблицы или через индекс.
3. Способ объединения: Может быть (сортировка-слияние, хэш и т. Д.). На самом деле это тип вашей таблицы.
4. Регистрационный заказ: Порядок, в котором соединения выполняются с таблицами.

Разбирая заявление и исследуя вышеуказанные элементы, у вас есть лучшее представление о том, как оптимизатор Oracle выбирает наиболее эффективный план. Если вы хотите углубиться в стоимость и мощность, взгляните на this post . Вложенные строки показывают операции, которые были сделаны для выполнения вашего запроса. Вы можете видеть свои объединения вместе со своей стоимостью.

Вложенные циклы: Посмотрите на NESTED LOOPS в план выполнения: Как заявляет имя, для каждой строки проживали в первой таблице, Oracle оценивает все строки второй (который на самом деле внутренняя таблица). Вложенные петли используются при объединении небольшого количества данных. Необходимо также получить доступ к второй таблице.

SORT MERGE JOINS, с другой стороны, более эффективны в больших наборах данных.

Методы доступа: Одна интересная информация - это доступ к таблице: там вы можете увидеть, был ли индекс использован для доступа. Если есть большая часть данных, которые необходимо выбрать, и нет относительного индекса, вы можете увидеть FULL TABLE SCAN. В этом случае все строки из таблицы читаются, а строки, которые не соответствуют заданным критериям, отфильтровываются. Эта операция может увеличить стоимость отчета. INDEX RANGE SCAN и таблица поиска ROWID, является суммой стоимости сканирования индекса и стоимости доступа к таблице на ROWID. В общем случае оракул получает ряды в основном от WHERE или через индексное сканирование. Это может привести к созданию нового индекса, если выполняется таблица полного доступа.

Заглянув в ваш поясняющий план, кажется, что оптимизатор Oracle избегает FULL SCAN. Стоимость этого - чтение всех строк таблицы. Это показатель медленного запроса.

Для подробной документации вы можете посмотреть на Oracle's Documentation