🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Основы анализа запросов в SQL на производительность
Такой анализ делается с помощью EXPLAIN PLAN (говорилось ранее). Применяется следующим образом:
EXPLAIN PLAN FOR
select u.*, u2.email from users u
left join users_2 u2 on u.user_id = u2.user_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
Вывод для такого запроса в следующем посте ⬇️
🟠На что обращать внимание при выводе результатов EXPLAIN PLAN?
Есть такие параметры как:
▶️ID - номер шага. Определяет порядок выполнения операций. Вложенные операции имеют больший ID и сдвинуты правее. Также по ID можно отслеживать родительско-дочерние отношения между операциями
▶️Operation - показывает, какие операции выполняет СУБД.
▶️Name - имя объекта (таблицы, индекса, представления), к которому обращается операция
▶️Rows — оценка количества строк
▶️Bytes — объем данных
▶️Cost — затраты на CPU
▶️Time — оценка времени выполнения
🟠В данном примере можно рассуждать так:
SELECT STATEMENT - это корневая операция плана выполнения, представляющая весь SQL-запрос. Все другие операции являются дочерними по отношению к ней. Поэтому она идет под ID = 0.
Основная операция в этом запросе - HASH JOIN OUTER. Внешнее соединение (OUTER) означает, что будут возвращены все строки из левой таблицы (USERS), даже если нет соответствия в правой (USERS_2). В данном примере использование именно HASH JOIN - своего рода проблема, которую можно было бы подкорректировать с помощью NESTED LOOPS, т.к. сами таблицы достаточно маленькие. Но в данном случае, когда таблицы ну уж очень маленькие, запрос выполнится быстро и без этого.
Остальные операции - это 2 TABLE ACCESS FULL - то есть полное сканирование таблицы. Опять же, в данном случае из-за размера таблиц в этом нет ничего такого. Но вообще это - одна из самых частых причин медленной работы SQL-запросов. Если бы таблицы были большие, то желательно бы добавить индексы на столбцы соединения.
Теперь касательно Rows. Весь запрос вернёт 4 строки (ID=0). А именно: джоин даст 4 строки (ID=1), т.к. используется left join по отношению к USERS, которая, свою очередь, даст эти же 4 строки (ID=2). Таблица USERS_2 же вернет 2 строки (ID=3) после джоина.
Bytes - просто ожидаемый объём данных в байтах, который вернёт операция.
Cost (%CPU) - использование CPU. В данном примере общая стоимость запроса = 4% от CPU.
🟠Ну а вообще, ключевые моменты, на которые надо обращать внимание при анализе производительности типовых, не самых заумных SQL-запросов, такие:
▶️Устранять TABLE ACCESS FULL с помощью индексов, если эта операция выполняется ощутимо долго. Можно еще уменьшить размер таблицы с помощью партиционирования.
▶️Если используются джоины, то понимать, где лучше применять HASH JOIN, а где NESTED LOOPS.
▶️Также потенциально медленными могут быть операции сортировки (где будет написано SORT). Решается опять же с помощью индексов.
▶️Операции FILTER могут быть проблемными, особенно если процент отфильтрованных строк слишком высок.
▶️Еще VIEW-операции могут выполняться долго. Основной совет - не путать VIEW с обычной таблицей и не особо нагружать дополнительными функциями те запросы, где фигурируют вьюхи. Особенно если еще создается view на view.
▶️Ну и смотреть на кол-во ожидаемых возвращаемых строк, байтов, смотреть на Cost (%CPU) и, само собой, на время выполнения для понимания того, какая из операций наиболее тяжеловесна и что именно надо оптимизировать.