SQL-Ex blog

Пересказ статьи Jeyaram Ayyalusamy. 32 - PostgreSQL 17 Performance Tuning: Understanding Optimizer Cost Parameters

PostgreSQL известна как одна из наиболее продвинутых реляционных баз данных с открытыми кодами, и одна из основных причин ее силы - оптимизатор запросов на основе стоимости.

Когда вы запускаете запрос, оптимизатор не выполняет его непосредственно. Он генерирует множество возможных планов выполнения и оценивает их стоимость. Выбирается план с самой низкой оценкой стоимости. Стоимость не измеряется в миллисекундах или циклах ЦП - она представляет собой абстрактные единицы, которые PostgreSQL использует для сравнения.

Понимание этих параметров стоимости в PostgreSQL является существенным для настройки производительности, особенно тогда, когда дело касается больших таблиц и сложных запросов.

В этой статье мы:

1. Создадим таблицу с 10 миллионами строк для имитации реальной рабочей нагрузки.


2. Создадим индексы, чтобы дать возможность PostgreSQL построить несколько планов выполнения.


3. Подробно разберем модель стоимости в PostgreSQL.


4. Покажем, как настройка параметров стоимости может изменить решение при выборе плана.

Continue reading "Настройка производительности в PostgreSQL 17: Понимание параметров стоимости оптимизатора"

Пересказ статьи Tomasz Gintowt. PostgreSQL Prepared Queries (Statements) For Beginners

Когда мы пишем запросы SQL, то часто выполняем один и тот же запрос снова и снова лишь меняя значения.

PostgreSQL обладает функциональностью, которая помогает решить эту проблему, - подготовленные запросы (также называемые подготовленными операторами).

В этой статье мы выясним:

• Что такое подготовленные запросы.


• Чем они полезны.


• Как их использовать в PostgreSQL.


• Реальные примеры, которые вы сами сможете опробовать.

Никаких непонятных слов. Никакой сложной теории. Простые ясные примеры.
Continue reading "Подготовленные запросы (операторы) в PostgreSQL для начинающих"

Пересказ статьи Jeyaram Ayyalusamy. 29 - PostgreSQL 17 Performance Tuning: Understanding Estimates vs. Actuals in Query Plans

Настройка производительности в PostgreSQL часто сводится к единственному навыку: умению читать планы выполнения. Команда PostgreSQL EXPLAIN ANALYZE - главный инструмент для этого. Она показывает не только то, как выполняется запрос, но и то, чего ожидал оптимизатор PostgreSQL, и что произошло на самом деле.

При просмотре плана выполнения вы всегда должны задать себе два больших вопроса:

1. Оправданы ли временные параметры, указанные в выводе команды EXPLAIN ANALYZE, для данного запроса?


2. В каком месте происходит внезапный скачок времени выполнения?

Места этих скачков в плане выполнения часто обнаруживают точный узел или операцию, которая замедляет ваш запрос.
Continue reading "Настройка производительности в PostgreSQL 17: понимание преполагаемого и действительного планов выполнения"

Пересказ статьи Robins Tharakan. Settling COUNT(*) vs COUNT(1) debate in Postgres 19

Недавнее изменение в основной ветке PostgreSQL принесло лучшее качество жизни очень общего паттерна SQL в плане оптимизации - улучшение производительности до 64% для SELECT COUNT(h), где h - столбец NOT NULL.

Если вы когда-либо задавались вопросом, что использовать - COUNT(*) или COUNT(1), или вы послушно придерживались использования COUNT(id) на не-NULL столбце, это изменение для вас.

Замечание: Эта функциональность в настоящее время реализована в основной ветке PostgreSQL (зафиксировано в ноябре 2025). Как и любая фиксация на основной ветке, она может подвергаться изменениям или даже отмене до финального релиза, хотя подобное происходит редко для зафиксированных функций. Если все будет нормально, это изменение станет частью релиза основной версии PostgreSQL 19.

Continue reading "Разрешение спора между COUNT(*) и COUNT(1) в Postgres 19"

Пересказ статьи Darren Tan. SQL Best Practices: Hard-Learned Lessons from my years as a Software Engineer

База данных похожа на шутку: если ее приходится объяснять, значит, она, скорее всего, плохо спроектирована...

Представьте: 3 часа утра в субботу, а я сижу за столом, три часа на то, что должно быть простой обработкой пакета производственных данных. Задача казалась простой - обработать набор данных 1200 заказчиков. Что я не мог предвидеть, так это то, что на каждый вызов API должен срабатывать триггер с тысячами операций, происходящих в базе данных, превращая простую работу в ночной кошмар.

Эта бессонная ночь субботы дала мне больше в плане понимания оптимизации SQL, чем все курсы информатики, которые я когда-либо проходил. Хотя бизнес-команда в конце концов получила свои данные (хотя и с некоторым ожиданием), я получил нечто более ценное: глубокое уважение как к силе, так и подводным камням запросов SQL.

Являетесь ли вы начинающим разработчиком, только приступающим к работе, или опытным архитектором, я надеюсь, что, делясь усвоенными мной уроками, я помогу вам избежать некоторого негативного опыта, который я получил той ночью. Continue reading "Лучшие практики SQL: уроки, усвоенные мной за годы работы инженером-программистом"

Автор: Joe Celko, The VALUES clause or building tables out of nothing

Предложение VALUES, вероятно, одна из самых неправильно используемых возможностей в SQL. Если вы посмотрите на онлайн-форумы по SQL, вы увидите, что люди используют его как второе предложение в операторе вставки, но используют его для построения только одной строки за раз, например так:

BEGIN

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Aries', '2025-03-21', '2025-04-19');

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Taurus', '2025-04-20', '2025-05-20');

… 

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Pisces', '2023-05-19', '2026-03-20');

END;

Каждый оператор вставки заканчивается точкой с запятой, поэтому они будут выполняться отдельно и в представленном порядке. Оптимизатор не осмеливается их объединять, потому что может быть прямая ссылка на предыдущие вставки.

Я думаю, люди пишут такой код, потому что именно так вы бы читали перфокарты. Каждая карта поступает в устройство чтения карт, буферизуется и записывается в порядке поступления на магнитную ленту или дисковый файл. Добро пожаловать в 1960-е! Перестаньте подражать старым языкам программирования, таким как FORTRAN или BASIC, в которых были операторы WRITE, помещающие по одной записи за раз в файл. Начните думать о работе с целыми множествами.

Continue reading "Предложение VALUES или создание таблиц из ничего"

Пересказ статьи Matheus dos Santos. Mastering PostgreSQL Performance: A Step-by-Step Guide to pg_hint_plan

Планировщик запросов PostgreSQL - это сложный инженерный механизм, обычно принимающий блестящие решения относительно того, как выполнять ваши запросы. Однако в сложных сценариях или при необычных распределениях данных вы можете знать лучший способ. Именно в таких ситуациях на помощь приходит pg_hint_plan - мощное расширение, которое позволяет вам руководить, или "советовать", планировщиком для выбора специфичного пути выполнения.

Это руководство проведет вас через весь процесс, начиная с установки pg_hint_plan из источника до использования его, чтобы принудительно выполнить сканирование индекса на большом наборе данных, демонстрируя возможности непосредственного управления производительностью вашего запроса.
Continue reading "Повышение производительности PostgreSQL: пошаговое руководство по использованию pg_hint_plan"

Пересказ статьи Udaya Veeramreddygari. Oracle Performance Tuning: Practical Techniques Every DBA Should Master

Как специалисты по базам данных, мы все сталкивались с этим ужасным моментом, когда пользователи начинают жаловаться на медленные запросы, и внезапно все смотрят на вас с выражением «исправьте это сейчас же». Настройка производительности Oracle может показаться невероятно сложной, особенно в условиях стресса, но хорошая новость состоит в том, что большинство проблем с производительностью возникают по нескольким распространённым причинам. Позвольте мне рассказать вам о нескольких проверенных методах, которые спасали мне жизнь больше раз, чем я могу сосчитать.

Начнем с самого простого: статистика и планы выполнения

Прежде чем перейти с сложным стратегиям настройки, всегда проверяйте актуальность вашей статистики. Оптимизатор Oracle на основе стоимости всецело опирается на точность статистики для принятия умных решений относительно путей выполнения запросов. Мне приходилось видеть запросы, которые выполнялись в 10 раз медленнее только потому, что кто-то забыл обновить статистику после загрузки большого объема данных. Continue reading "Настройка производительности в Oracle: практические методы, которыми должен владеть каждый DBA"

Пересказ статьи Sergey Gigoyan. SQL Index Rebuild vs Reorganize Comparison

При модификации данных в базе данных SQL соответствующие индексы тоже изменяются. Эти изменения приводят к фрагментации индексов. Фрагментация означает, что логический порядок данных на страницах индекса не соответствует физическому порядку. Во фрагментированных индексах информация не располагается логически, что делает операции извлечения данных из индекса более затратными по времени, это приводит к проблемам производительности запросов. Таким образом, фрагментацию индексов следует периодически устранять для поддержания высокой производительности. Операции перестройки и реорганизации индекса как раз направлены на дефрагментацию индексов.

В данной статье мы рассмотрим то, что является общим и различным в этих операциях. Прежде чем начать, мы объясним некоторые важные связанные с ними понятия. В частности, ту информацию, которая стоит за коэффициентом заполнения и статистикой, т.к. эти понятия упоминаются при обсуждении операций по перестроению и реорганизации индекса.

Continue reading "Сравнение перестройки и реорганизации индексов SQL"

Пересказ статьи Lorenzo Uriel. Bind Parameters Make Your SQL Queries Faster

Конечно, вы уже использовали параметры привязки, но слышали ли вы такой совет для оптимизации?

Что-то типа: "Использование параметров привязки (параметризованных запросов) вместо конкатенации строки SQL улучшит производительность SQL"?

Почему это так вы поймете из этой статьи.

Continue reading "Параметры привязки ускоряют выполнение SQL-запросов"

Пересказ статьи Christopher Jones. Query result caching for fast database applications

Встроенный в базы данных Oracle “Client Result Cache” (CRC) является эффективным, интегрированным, управляемым кэшем, который резко улучшает производительность запросов и существенно снижает нагрузку на базу данных при повторяющихся запросах к по большей части статическим таблицам, таким как почтовые индексы или номера деталей. Никакие изменения в приложениях не требуются. Никакого отдельное промежуточного кэша устанавливать не нужно. CRC доступен для каждого "толстого" клиента, который использует библиотеки Oracle Client, такие как драйверы для Python, Node.js, Go, PHP, Rust, Ruby и Oracle C API. Он также доступен в JDBC. Эта статья демонстрирует пример для Python.

Преимущества кэширования результатов клиента

• Может использоваться без необходимости изменять код приложения.


• Улучшенное время отклика запроса.


• Операторы не посылаются для выполнения в базу данных.


• Лучшая производительность за счет устранения циклов обмена между серверами.


• Улучшенная масштабируемость сервера баз данных за счет экономии ресурсов сервера.


• Автоматически управляемое аннулирование кэша, поддерживающее соответствие кэша изменениям в базе данных.


• Не требуется сервер промежуточного слоя для кэширования.


• Разработчикам не требуется создавать или использовать собственный кэш.

Continue reading "Кэширование результата запроса для быстрых приложений баз данных"

Пересказ статьи Lukas Vileikis. MySQL Index Overviews: Composite B-Tree Indexes

Индексы в MySQL являются одним из главных средств улучшения производительности запросов. Они особенно полезны, когда основные операции вашего проекта относятся к чтению данных, хранящихся в базе данных. Мы уже обсуждали нюансы индексов в MySQL, где говорилось, что MySQL предлагает вам для выбора различные типы SQL-индексов.

Основной тип индекса в MySQL - это индекс B-Tree, рассмотренный нами в одной из предыдущих статей. Если вы работаете с MySQL, то определенно знаете также о других нюансах индексов, одним из которых является тот факт, что индексы B-Tree могут строиться на нескольких столбцах (обычно их называют составными индексами). В этом примере мы используем MariaDB, хотя Percona Server для MySQL и MySQL Server будут вести себя идентично.

В приложении вы найдете запросы, воссоздающие структуру таблиц и составные индексы, так что давайте начнем.
Continue reading "Обзор индексов в MySQL: составные индексы B-Tree"

Автор: Franck Pachot Improving Your SQL Indexing: How to
Effectively Order Columns

Пользователям нередко трудно подобрать лучший индекс для запроса, особенно
определить правильный порядок столбцов.

Представьте большую таблицу, которую нужно отфильтровать до конкретного
набора данных — всё ещё довольно объёмного. Вы можете использовать простые
условия, вроде эквивалентности или выборки диапазона, но ваш WHERE может
включать и более сложные условия — множественный выбор (IN) и комбинации (OR).

После фильтрации вы хотите показать лишь несколько строк, отсортированных по
некоторым столбцам, и ограничить результат с помощью LIMIT или FETCH FIRST ROWS
— типичный случай разбивки на страницы. Хотя индексы помогают находить
диапазоны значений и упорядочивать результаты, при всех этих условиях трудно
решить, в каком порядке располагать столбцы в индексе.

Continue reading "Улучшаем индексы: эффективный порядок столбцов ключа"

Пересказ статьи Sheikh Wasiu Al Hasib. PostgreSQL Hybrid Transactional/Analytical Processing using

Что такое HTAP?

HTAP - это аббревиатура от гибридной транзакционной/аналитической обработки (Hybrid Transactional/Analytical Processing). Она характеризует системы баз данных, которые могут обрабатывать как транзакционные (OLTP), так и аналитические (OLAP) рабочие нагрузки одновременно на одном и том же наборе данных. Такая возможность позволяет выполнять аналитические запросы к текущим транзакционным данным без необходимости извлекать, преобразовывать и загружать (ETL) данные в отдельное хранилище для последующего анализа.

Continue reading "Использование гибридной транзакционной/аналитической обработки в PostgreSQL"

Пересказ статьи Uzzal Kumar Hore. PostgreSQL Configuration Tuning Best Practices and Tools for Production-Ready Performance

PostgreSQL является одной из наиболее мощных и универсальных баз данных с открытыми кодами, но установка из коробки не является вполне оптимизированной. Если вас серьезно беспокоит производительность - будь то OLTP, OLAP, смешанная нагрузка или данные временных рядов - важным моментом является настройка параметров конфигурации PostgreSQL.

Эта статья посвящена лучшим практикам настройки ключевых параметров PostgreSQL, обоснованию главных параметров конфигурации и разнообразным инструментам (включая, но не ограничиваясь timescaledb-tune), чтобы помочь автоматизировать или усовершенствовать этот процесс.

Почему PostgreSQL требует ручной настройки

Настройки по умолчанию в PostgreSQL намеренно консервативны - они рассчитаны на выполнение при минимальных аппаратных ресурсах. В результате, если вы имеете современную инфраструктуру (многоядерный ЦП, SSD, много оперативной памяти), эти параметры по умолчанию не могут в значительной мере использовать возможности вашей системы.
Continue reading "Настройка конфигурации PostgreSQL: лучшие практики и инструменты для повышения производительности"