Skip to content

Имеет ли значение порядок в GROUP BY?

Пересказ статьи Brent Ozar. Does Your GROUP BY Order Matter?


Иногда, когда вы используете GROUP BY, порядок столбцов имеет значение. Например, эти два запроса SELECT дают разные результаты:

CREATE INDEX Location_DisplayName
ON dbo.Users(Location, DisplayName);

SELECT TOP 100 Location, DisplayName, COUNT(*) AS Duplicates
FROM dbo.Users
GROUP BY Location, DisplayName
ORDER BY Location, DisplayName;

SELECT TOP 100 DisplayName, Location, COUNT(*) AS Duplicates
FROM dbo.Users
GROUP BY DisplayName, Location
ORDER BY DisplayName, Location;

Их действительные планы выполнения существенно разнятся:

Continue reading "Имеет ли значение порядок в GROUP BY?"

Все, что вам нужно знать об индексе в SQL Server

Пересказ статьи Lorenzo Uriel. Everything you Need to Know About Index in SQL Server





Цель настоящей статьи - рассказать просто об индексах в SQL Server, объяснив фундаментальные понятия и предложив практические советы по обслуживанию.

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

Темы


  • Обзор индексов

  • Типы индексов в SQL Server
    • Кластеризованные индексы.

    • Некластеризованные индексы.

    • Поколоночный и построчный индексы.

  • Фрагментация индексов
    • Внутренняя и внешняя.

    • Перестройка и реорганизация.

Continue reading "Все, что вам нужно знать об индексе в SQL Server"

Принудительное использование планировщиком запросов Postgres правильного индекса с помощью OFFSET 0

Пересказ статьи Julien Van Beveren. Forcing the Postgres query planner into using the correct index using OFFSET 0


MySQL имеет возможность применять хинт USE INDEX для указания, какие индексы использовать при выполнении конкретного запроса. PostgreSQL не имеет такой особенности, полагая, что он лучше знает, когда и какие индексы использовать.

Перед выполнением запроса PostgreSQL строит "план". Это сложный процесс, который я хотел бы понимать досконально, но планировщик запросов главным образом смотрит на существующие индексы, распределение данных и фильтры запроса, чтобы найти различные способы вернуть затребованные вами данные. Затем он оценивает "стоимость" каждой операции и выполняет "самый дешевый" план. Это работает отлично до тех пор, пока не...
Continue reading "Принудительное использование планировщиком запросов Postgres правильного индекса с помощью OFFSET 0"

Сравнение производительности TOP и MAX

Пересказ статьи Andy Brownsword. Comparing Performance of TOP vs. MAX


Как TOP(1), так и MAX могут использоваться для нахождения наибольшего значения в наборе данных. Хотя они приводят к одному и тому же результату, но делают это разными способами.

Для начала разберемся, в чем разница между ними?

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

Давайте перейдем к нескольким примерам с данными StackOverflow, а конкретно таблицы Votes.

Continue reading "Сравнение производительности TOP и MAX"

Исследование производительности: прямые SQL-запросы или ORM в Python

Пересказ статьи Exploring Performance: Raw SQL Queries vs. ORM in Python


В приложениях, управляемых данными, очень важна оптимизация производительности. Когда приходится взаимодействовать с данными, разработчики часто оказываются на распутье: следует ли им непосредственно использовать запросы SQL или выбрать фреймворк объектно-реляционного отображения (ORM)? Эта статья углубляется в эту дискуссию, выделяя преимущества и недостатки обоих подходов, сопровождая их реальными примерами кода Python для более глубокого понимания.

Понимание ландшафта


Прямые запросы SQL встраиваются непосредственно в ваш код для взаимодействия с данными. Они предоставляют разработчикам детальное управление структурой и выполнением запроса, что делает их привлекательными для сложных запросов. С другой стороны, фреймворки ORM типа SQLAlchemy абстрагируют взаимодействие с базой данных в объекты Python, снижая необходимость писать непосредственно на SQL, улучшая при этом читабельность кода.
Continue reading "Исследование производительности: прямые SQL-запросы или ORM в Python"

Немного о тривиальных планах

Пересказ статьи Andy Brownsword. A Bit About Trivial Plans


Тривиальный план создается, когда у SQL Server нет никакого выбора по реализации. Вот пример из базы данных StackOverflow с удаленными индексами:



SELECT *
FROM dbo.Users
WHERE Id = 1234;

Здесь действительно нет никакого выбора помимо поиска в кластеризованном индексе. Это единственный индекс и это настолько же эффективно, насколько это возможно, учитывая, что мы фильтруем по ключу кластеризации для конкретного значения:



Continue reading "Немного о тривиальных планах"

Соединение больших таблиц в SQL. Как быстро загрузить данные: часть 2

Пересказ статьи Mitchell Warr. Joining Big SQL Tables How to Load Data Fast Part 2


В части 1 мы рассмотрели несколько методов ускорения запросов в PostgreSQL.

Давайте исследуем нашу собственную историю и ускорим запрос. Мы создадим набор таблиц для студентов, классов, преподавателей и посещаемости. Для нашего примера диаграмма ERD будет выглядеть как на рисунке ниже.


Continue reading "Соединение больших таблиц в SQL. Как быстро загрузить данные: часть 2"

Оптимизация предложений DISTINCT с помощью EXISTS

Пересказ статьи Andy Brownsword. Optimising DISTINCT Clauses using EXISTS


Предложение DISTINCT может помочь нам быстро убрать дубликаты из результатов запроса. Иногда полезно остановиться и спросить почему. Почему нам необходимо использовать это предложение, почему мы получаем дубликаты из наших данных?

Обычно я вижу это из-за применения JOIN, когда на самом деле нам не нужны все эти результаты. Это может быть проверка «существует ли что-либо», например, делал ли клиент когда-либо заказ раньше. Проблема возникает, когда имеется много возвращаемых строк, например, для постоянного клиента в нашем примере.

Continue reading "Оптимизация предложений DISTINCT с помощью EXISTS"

Параметр log_min_duration_statement в PostgreSQL

Пересказ статьи Dmitry Romanoff. PostgreSQL parameter log_min_duration_statement


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

По умолчанию значение параметра log_min_duration_statement равно -1, что отключает журнализацию операторов.
Установка параметра log_min_duration_statement в 0 приведет к записи операторов любой длительности выполнения.

Замечание. Установка этого параметра в рабочем окружении может привести к большим объемам журналов и значительному выделению дискового пространства.
Continue reading "Параметр log_min_duration_statement в PostgreSQL"

Оценка производительности запросов с помощью pg_stat_statements в PostgreSQL

Пересказ статьи Ömer Naci Soydemir. Query Performance with pg_stat_statements in PostgreSQL


В PostgreSQL производительность запросов является критическим аспектом оптимизации базы данных. Одним из мощных инструментов мониторинга и анализа производительности запросов является расширение pg_stat_statements.

Включение pg_stat_statements: вам необходимо включить расширение в вашей базе данных PostgreSQL. Вот как вы можете это сделать:
Continue reading "Оценка производительности запросов с помощью pg_stat_statements в PostgreSQL"

Полезные расширения PostgreSQL, которые стоит изучить прямо сейчас!

Пересказ статьи SInshiya Nalawala. Useful Postgres Extensions to explore right away!


Вы думали когда-нибудь о том, что делает PostgreSQL больше чем просто системой реляционных баз данных?

Расширения PostgreSQL!

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

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

Пул подключений к базе данных

Пересказ статьи Sujoy Nath. Database Connection Pool





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

Вот как работает пул подключений к базе данных: Continue reading "Пул подключений к базе данных"

PostgreSQL. Как выявить запросы, которые максимально используют временные файлы?

Пересказ статьи Dmitry Romanoff. Postgres. How to check the top queries that use temporary files?


Временные файлы в базе данных PostgreSQL могут стать проблемой по нескольким причинам:

  1. Влияние на производительность.

  2. Использование пространства на диске.

  3. Может выделяться все больше и больше памяти.

  4. Проблемы параллелизма.

  5. Сложность в мониторинге и обслуживании.

Что следует делать, чтобы избежать временных файлов в базе данных PostgreSQL?
Continue reading "PostgreSQL. Как выявить запросы, которые максимально используют временные файлы?"

Секционирование таблицы по диапазону в базе данных PostgreSQL

Пересказ статьи Dmitry Romanoff. Partitioning a table by range in the PostgreSQL database


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

Здесь я на практике продемонстрирую, как работает секционирование. Continue reading "Секционирование таблицы по диапазону в базе данных PostgreSQL"

Оптимизационные трюки в PostgreSQL. Как быстро загрузить данные: часть 1

Пересказ статьи Mitchell Warr. PostgreSQL Optimization Tricks: How to Load Data Fast Part 1


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

Вы открываете объяснение плана запроса и заглядываете под капот в чем-то типа https://explain.dalibo.com. Но что вы фактически можете сделать?

Continue reading "Оптимизационные трюки в PostgreSQL. Как быстро загрузить данные: часть 1"