JOIN vs. Коррелированный подзапрос: Разрушаем миф о «N+1» на 4 СУБД
JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее» Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN .
Альтернатива чатам с ИИ для анализа и оптимизации SQL запросов. Часть 2
Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов . Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты. За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.
https://habr.com/ru/articles/938806/
#sql #mysql #mariadb #sql_server #mysql_optimization #mysql_tuning #sql_tuning #optimizer #query_optimization #postgresql
Альтернатива чатам с ИИ для анализа и оптимизации SQL запросов
Всем привет! Экспериментировал с оптимизацией SQL запросов в ChatGPT и Claude. В какой-то момент понял, что это превращается в одно и то же: Напиши промт → вставь SQL → подожди → поправь → повтори
https://habr.com/ru/articles/929730/
#sql #mysql #mariadb #mysql_optimization #mysql_tuning #sql_tuning #optimizer #query_optimization #postgresql
Автоматизированное управление расширенной статистикой в PostgreSQL
Здесь я описываю результаты разработки одного расширения Postgres, которое сделал просто ради любопытства. Суть его состоит в автоматическом управлении расширенной статистикой по колонкам таблицы. Идея родилась в момент, когда заканчивая работу над очередным "умным" query-driven продуктом улучшения качества планирования Postgres я осознал, что архитектура этой СУБД пока ещё не готова к полностью автономной работе - автоматическому детектированию плохих планов и подстройки оптимизатора. Так может быть зайти с другой стороны, и попробовать сделать автономный data-driven помогатор?
Нужен ли Postgres альтернативный сборщик статистики таблиц?
Речь здесь пойдёт о стабильности стандартной статистики Postgres и об идее очередного расширения - на этот раз альтернативы команде ANALYZE. Всё началось с того, что заканчивая работу над предыдущей статьёй я вдруг заметил, что результат выполнения одного и того же запроса теста Join Order Benchmark (JOB) в серии последовательных прогонов может отличаться в разы и даже на порядки - причем как по значению параметра execution-time, так и по pages-read. Это выглядело очень странно, поскольку и тест и ноутбук и все настройки оставались теми же - даже погода за окном. И я решил расследовать, что происходит …
https://habr.com/ru/articles/878724/
#postgresql #sql #database_design #statistics #query_optimization #relational_database
Как мы ускорили Trino, научив оптимизатор удалять ненужные Join
Как мы ускорили запросы в Trino, научив оптимизатор удалять из плана лишние операторы Join. Обсудим, почему в аналитических запросах часто возникают избыточные Join, почему это плохо для SQL-движков, какие эквивалентные преобразования позволяют избавиться от ненужных Join, и с какими проблемами мы столкнулись при интеграции данного функционала в наш форк Trino.
https://habr.com/ru/companies/cedrusdata/articles/843882/
#trino #cedrusdata #sql #data_analysis #data_engineering #query_optimization #query_performance #datalake #lakehouse
Habr
