💃💃💃Оптимизируй!

Когда я работала в банке, у нас периодически приходило письмо с особо отличившимися сотрудниками, которые своими запросами бессовестно выжрали все ресурсы в одну мордочку. Знаю, что в других банках за такое дают «желтую карточку», а если 2 раза провинился - ограничение доступа и иди учись на корм курсах как правильно себя вести. Так что советую для развития почитать книжку «Оптимизация запрос в PostgreSQL» (Домбровская Г.) и глянуть видео внизу поста.

Основные поинты из книги: 1. Селективность запроса - это соотношения количества строк, составляющих результат операции, к общему количеству строк в таблице. 2. Запрос является коротким, когда количество строк, необходимых для получения результата, невелико независимо от того, насколько велики задействованные таблицы. Короткие запросы могут считывать все строки из маленьких таблиц, но лишь небольшой процент строк из больших таблиц. 3. Запрос считается длинным, если селективность запроса высока по крайней мере для одной из больших таблиц; то есть результат, даже если он невелик, определяется почти всеми строками. 4. Когда мы оптимизируем короткий запрос, мы знаем, что в конечном итоге мы выбираем относительно небольшое количество записей. Это означает, что цель оптимизации – уменьшить размер результирующего множества как можно раньше. Если на первых этапах выполнения запроса применяется самый строгий критерий фильтрации, дальнейшие сортировки, группировки и даже соединения будут менее затратными. В плане выполнения не должно быть сканирований больших таблиц. 5. Если вы выполняете какие-то преобразования над полем индекса (функции lower, преобразование типов данных), то запрос не сможет воспользоваться таким индексом. Нужно либо переписывать условие в запросе без использования преобразования, либо создавать функциональный индекс. 6. В случае с длинными запросами используются две стратегии оптимизации: избегать многократных сканирований таблиц и уменьшать размер результата на как можно более ранней стадии. 7. Как правило, составной индекс по столбцам (X, Y, Z) будет использоваться для поиска по X, XY, XYZ и даже XZ, но не только по Y и не по YZ. Таким образом, при создании составного индекса недостаточно решить, какие столбцы в него включить; необходимо также учитывать их порядок. 8. Иногда попытка разработчиков SQL ускорить выполнение запроса, наоборот, может привести к замедлению. Такое часто случается, когда они решают использовать временные таблицы. Сразу возникает проблема с:

• индексами (мы не можем использовать индексы, созданные в исходной таблице, нам либо придется обойтись без индексов, либо создать новые во временных таблицах, что требует ресурсов)
• местом на диске (когда промежуточные результаты не помещаются в доступную оперативную память, временные таблицы сохраняются на диске), - операциями чтения-запись (дополнительно тратится время)
• статистикой (поскольку мы создали новую таблицу, оптимизатор не может использовать статистические данные о распределении значений из исходной таблицы (или таблиц), поэтому нам придется либо обойтись без статистики, либо выполнить команду ANALYZE для временной таблицы)

Неплохое видео про базовые принципы оптимизации от Евгения Кудашева ЦИАН: https://www.youtube.com/watch?v=y6CWIBKEw_g

Еще интересная серия постов на хабре о том, как читать план запроса: https://habr.com/ru/articles/275851/ https://habr.com/ru/articles/276973/ https://habr.com/ru/articles/279255/

А тут два моих поста про код-стайл SQL: https://t.me/data1sm/215 https://t.me/data1sm/217