2021-09-08 13:41:51
Начал для себя собирать
#Типичные_ошибки проектирования запросов
● Отсутствие индекса → Полное сканирование
Бывают очень казусные случаи, например, с отсутствием индекса на боевой схеме. У нас был конкретный пример, когда запрос долгое время работал быстро без индекса. Но там было полное сканирование, и поскольку размер таблицы постепенно рос, то запрос начал работать медленнее, и из квартала в квартал требовал чуть больше времени. В конечном итоге мы обратили на него внимание и оказалось, что индекса там нет.
● Большая выборка → Полное сканирование
Вторая типичная ошибка — это большая выборка данных — классический случай полного сканирования. Все знают, что полное сканирование надо использовать только тогда, когда это действительно оправдано. Иногда бывают случаи, когда попадается полное сканирование там, где можно было бы обойтись без него, например, если перенести условия фильтрации из pl/sql-кода в запрос.
● Неэффективный индекс → Длинный INDEX RANGE SCAN
Может быть, это даже самая распространенная ошибка, про которую почему-то очень мало говорят, — так называемый неэффективный индекс (длинное индексное сканирование, длинный INDEX RANGE SCAN). Например, у нас есть таблица по реестрам. В запросе мы пытаемся найти все реестры данного агента, и в конечном итоге добавляем какое-нибудь условие фильтрации, например, за некий период, или с определенным номером, или конкретного клиента. В таких ситуациях индекс обычно строят только по полю «агент» из соображений универсальности использования. В итоге получается такая картина: в первый год работы, скажем, у агента было 100 записей в этой таблице, в следующем году уже 1 000, еще через год может быть 10 000 записей. Проходит некоторое время, этих записей становится 100 000. Очевидно, что запрос начинает медленно работать, потому что в запрос нужно добавлять не только сам идентификатор агента, но еще и какой-то дополнительный фильтр, в данном случае по дате. Иначе будет получаться, что объем выборки из года в год будет увеличиваться, поскольку число реестров для данного агента растет. Эту проблему надо решать на уровне индекса. Если данных становится слишком много, тогда надо уже думать в сторону секционирования.
● Ненужные ветки дистрибутивного кода
Это тоже курьезный случай, но, тем не менее, и так бывает. Мы смотрим в топ запросов, и видим там какие-то странные запросы. Приходим к разработчикам и говорим: «Мы нашли некоторые запросы, давайте разберемся и посмотрим, что с этим можно сделать». Разработчик задумывается, потом приходит через некоторое время и говорит: «В вашей системе этой ветки кода быть не должно. У вас эта функциональность не используется». Потом разработчик рекомендует включить какую-то специальную настройку, чтобы работать в обход этого участка кода.
Иcточник: ссылка
234 viewsedited 10:41
O
