Знаете, какая фраза чаще всего дорого обходится компании? "Работает — и ладно" 🥂

Результат есть, да и дашборд вроде выводит корректные данные, какие-то dq проверки отбегали — ну красота же. Но где-то в это время система сканирует 300+ столбцов вместо трёх, разворачивает пятнадцать условий LIKE там, где справилось бы одно регулярное выражение, и три раза читает одну и ту же таблицу, потому что так написалось и на маленьком семпле данных работало шустро. В облаке всё это превращается в чёрную дыру, куда буквально улетают деньги — каждое лишнее сканирование, каждое вычисление прямо в условии JOIN, каждый ненужный DISTINCT тихо утекают кредитами. С on-premise примерно та же история, только счёт приходит очередями, перегруженным сервером и дашбордами, которые "ну грузятся долго, но это норм, мы привыкли".

Спойлер: это не норм 🙂

Сейчас ещё популярна идея, что можно особо не заморачиваться — оптимизатор же умный, а уж ИИ и подавно напишет нормальный производительный код, только вопрос правильно сформулируй. Отчасти это правда (пока у вас запросы на 25 строк). Но понимать, что происходит внутри системы в момент выполнения запроса, всё равно нужно — хотя бы для того, чтобы оценить, что тебе написали, и не тащить в прод красиво выглядящий, но дорогой запрос.

Поэтому оптимизация, за которую я регулярно топлю — это не занудство и не перфекционизм, а базовое понимание механики. Именно оно позволяет не просто писать SQL, а понимать, чего это стоит системе.

А вы доверяете ИИ писать запросы в прод — или всё-таки смотрите, что там внутри? 👀

#sql #dwh