🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Проблемы в оптимизации SQL-запросов
Иногда приходится сталкиваться с запросами, где должно быть большое количество условий. Например, много условий в WHERE, много полей в GROUP BY, много JOIN и т.п. И такие запросы будут выполняться очень медленно и даже не факт, что выполнятся вообще.
🟠Но почему такое происходит?
▶️WHERE сам по себе работает как фильтр данных. Если вспомнить порядок выполнения SQL-запроса, то WHERE выполняется одним из первых. И по идее, если добавлять в WHERE по 5-10 условий через AND, то лишних данных может отсеяться очень много, что в итоге сделает запрос легче и быстрее. И в целом, это так и работает, и запрос реально может стать быстрее или хотя бы не измениться.
Но в случае, если у нас прописаны индексы на 1-2 самых часто используемых столбцах, то добавление дополнительных неиндексированных столбцов может значительно замедлить работу. Происходит это из-за того, что оптимизатор перестает эффективно использовать индексы, и СУБД вынуждена тратить дополнительные ресурсы на проверку каждого условия для каждой строки.
▶️В случае с GROUP BY заложена другая логика. И тут замешана банальная математика. Чем больше столбцов в условие GROUP BY мы добавляем, тем больше разных вариантов система вынуждена отработать. И количество вариантов растет мультипликативно.
Например, если группировать по полю "day", то мы будем иметь 365 разных комбинаций. Если добавить поле "country", то добавится условно еще 50 вариантов, итого будет 365*50 = 18 250. И каждое такое крупное поле в разы увеличивает нагрузку и, как следствие, время выполнения.
▶️Большое кол-во JOIN тоже имеет чисто математическую причину замедления. Например, мы присоединяем к таблице с клиентами таблицу с их счетами. Очевидно, что если у каждого клиента в среднем по 3 счета, то кол-во строк увеличится в 3 раза. Если еще к каждому счету присоединить транзакции, которые с него совершались, то кол-во строк увеличится еще в 50 раз. И так будет продолжаться и далее.
Ну и также не стоит забывать, что чем больше таблиц, тем сложнее СУБД просчитать идеальный порядок их объединения (количество вариантов растет экспоненциально).
▶️Много COUNT(DISTINCT) тоже желательно не использовать в одном запросе. Это очень "дорогостоящая" операция сама по себе, потому что заставляет базу держать в памяти полный список всех уникальных значений, чтобы отсечь дубликаты. И если это делать по 3-4 колонкам одновременно, то СУБД будет строить несколько гигантских структур данных в памяти. И это будет медленно.