→ Проверьте реальную природу таблиц, появляющихся в запросе. Если это представления, переместите их в оператор как подзапросы (этот процесс может оказаться рекурсивным) и удалите из этих подзапросов все, что не относится к текущему запросу (глава 3). Опасайтесь также распределенных запросов: вложенные циклические запросы между далекими таблицами могут убить любой запрос.
→ Если у вас не получается модифицировать программу, возможно, вы сможете увеличить производительность, просто переписав представления, которые ссылаются на другие представления, так, чтобы они ссылались только на исходные таблицы.
→ Проверьте, не являются ли операторы update, insert и delete медленными из-за блокировок, захваченных другими, более медленными операторами.
→ Для операторов update, insert и delete проверьте также, не сработали ли триггеры. Проблема может заключаться именно в этом.
→ Удалите все директивы оптимизатора и сократите запрос до его ядра.
→ Хранится ли среди возвращаемых столбцов информация в одном столбце для всех таблиц или столбец является столбцом соединения, общим для нескольких таблиц? Изменится ли что-нибудь, если вернуть информацию из другой таблицы?
→ Идентифицируйте таблицы, которые вам нужны для получения данных, таблицы, которые вам нужны для указания условий, и таблицы, которые вам нужны только для соединений. Переместите таблицы, которые вам нужны только для указания условий, в подзапросы. Если они очень велики, а ожидаемый результирующий набор мал, сделайте эти запросы согласованными. В противном случае продумайте применение in () или соединение с подзапросом во фразе from. Опасайтесь, что in ( subquery ) добавит неявный distinct, который должен стать явным, если подзапрос находится во фразе from.
→ При работе с подзапросами опасайтесь значений null, которые не могут быть ни равны чему-либо еще, ни отличаться от чего-то иного, ни даже быть равными другим значениям null. Не забывайте указывать условия is not null для столбцов, которые не являются обязательными.
→ Будьте осторожны: согласованные и несогласованные подзапросы не должны опираться на различные условия индексирования.
→ Какой критерий должен управлять запросом, быть его исходной точкой? Если среди возможных «кандидатов» есть несколько критериев, применяемых к разным таблицам, будет ли возможность изолировать строки-кандидаты каждого запроса, а затем объединить их с помощью соединений или операций над множествами типа intersect?
→ Имеются ли какие-нибудь определенные пользователем функции? Часто ли они вызываются? Вызываются ли они снова и снова с одними и теми же параметрами? Если они могут вызываться часто, могут ли их результаты быть кэшированными (глава 3)? Каков исходный код этих функций? Можно ли перенести их логику в один запрос (глава 6)? Можете ли вы использовать этот единственный запрос в соединении?
→ Есть ли функции, которые могли бы препятствовать использованию индекса? Опасайтесь неявных преобразований типов. Убедитесь, что столбцы и значения на обеих сторонах условий имеют один и тот же тип.
→ Находятся ли столбцы композитных индексов в нужном порядке (глава 2)? Не может ли индекс, который выглядит как имеющий неправильный порядок, быть нужен кому-то еще? Вряд ли вы захотите испортить другим квартальный отчет.
→ Не забывайте, что обращения к базе данных эффективнее тогда, когда столбец композитного индекса, к которому применяются условия неравенства, находится после столбца, к которому применяются условия равенства.
→ Будьте очень внимательны с индексами, поскольку они могут добавить большие накладные расходы к операциям вставки и удаления. Если требуется новый индекс, попытайтесь идентифицировать тот индекс, без которого можно обойтись, поскольку он избыточен или недостаточно избирателен. Постарайтесь сохранять количество индексов постоянным.
→ Есть ли какие-либо шаблоны, повторяющиеся на протяжении всего запроса? Есть ли определенные таблицы, обращение к которым происходит несколько раз? Можете ли вы обойтись только одним обращением?
→ Характеризуют ли подзапросы особенный порядок исполнения запроса через зависимости? Например, зависит ли согласованный подзапрос от значения столбца, что требует исполнения другого подзапроса или соединения? Можно ли сделать этот порядок исполнения менее жестким и дать больше свободы оптимизатору?
→ Если в запросе есть операции над множествами, можно ли их вынести за скобки?
→ Можно ли заменить какие-либо рефлексивные соединения на функции ранжирования?
Концентрированная книга издательства LIVREZON складывается из сотен и тысяч проанализированных источников литературы и масс-медиа. Авторы скрупулёзно изучают книги, статьи, видео, интервью и делятся полезными материалами, формируя коллективную Базу знаний.
Пример – это фактурная единица информации: небанальное воспроизводимое преобразование, которое используется в исследовании. Увы, найти его непросто. С 2017 года наш Клуб авторов собрал более 80 тысяч примеров. Часть из них мы ежедневно публикуем здесь.
Каждый фрагмент Базы знаний относится к одной или нескольким категориям и обладает точной ссылкой на первоисточник. Продолжите читать материалы по теме или найдите книгу, чтобы изучить её самостоятельно.
📎 База знаний издательства LIVREZON – только полезные материалы.