SQL-Ex blog

Joe Celko, SQL GROUP BY Basics

Предложения GROUP BY и HAVING в SQL существуют с самого начала языка, в своей простейшей форме. Изначальная идея заключалась в том, что вы создаёте рабочую таблицу с помощью предложений SELECT ... FROM ... WHERE, а затем разбиваете этот результирующий набор на группы. Группа определяется как набор строк с одинаковыми значениями для столбцов группировки. Негруппируемые столбцы должны были быть свойствами группы (обычно агрегатными функциями), формулами или вычислениями, выполненными на них, либо константами (что технически также является свойством группы).

Затем каждая группа сводится к одной строке. Важное понятие здесь — исходная таблица больше не существует. Однако если вы достаточно взрослый, чтобы работать с самыми ранними версиями SQL Server, синтаксис Sybase не избавлялся от исходной таблицы. Это приводило к некоторым проблемам. Он предоставлял доступ к исходным данным строк вместе с агрегированными данными.

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

Позже мы добавили оконные функции, расширения для GROUP BY в форме ROLLUP, CUBE и GROUPING SETS. Но с исходными простыми конструкциями GROUP BY – HAVING всё ещё можно сделать довольно много. Их преимущество в том, что они выполняют свою работу за один просмотр таблицы, в то время как более новые конструкции могут требовать временного хранения или нескольких проходов по данным. Исходные версии переносимы и предсказуемы. Спустя все эти десятилетия они теперь хорошо оптимизированы.

Продолжить чтение "Основы GROUP BY в SQL"

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 40 (SELECT)		6		8
 149 (SELECT)		5		4
 189 (SELECT)		3		3

§ Авторы недели на форуме

Автор		Сообщений
 pegoopik  	5
 selber  	5
 gennadi_s  	2
 Paulus73	2

Продолжить чтение "Новости за 2026-01-03 - 2026-01-09"

Пересказ статьи DbVisualizer. PostgreSQL REGEXP_MATCH Explained: Syntax, Use Cases, Pitfalls

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

Если вам когда-либо требовалось извлечь номер телефона из текста, проверить адрес электронной почты или захватить поименованный фрагмент строки, REGEXP_MATCH поможет вам сделать это за один шаг SQL.

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

Joe Celko, Looking at VIEWs, Close Up

Первые стандарты SQL-86 ввели немного «стандартного языка»: слово, которое продолжает использоваться до сих пор. Это слово — «эффективно». «Эффективно» используется для описания конечного эффекта оператора. Мы не определяем реализацию. Мы определяем результат. Вы, вероятно, предположили бы, что так должны делать все стандарты для языков, но стандарты как для FORTRAN, так и для COBOL изначально определяли непрерывное хранение и другие подобные детали реализации. Насколько мне известно, мы были первыми, кто отошёл от этой модели в стандарте SQL.

Представления (VIEW) — это виртуальные таблицы, определяемые оператором SELECT, и они должны эффективно вести себя так, как если бы результат этого оператора был реальной физической базовой таблицей. Это означало, что в любом месте грамматики, где разрешена таблица, вы можете использовать представление. Для данных представлений не выделяется место до тех пор, пока они не будут вызваны, поэтому они экономичны с точки зрения ресурсов.

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

Синтаксис VIEW в Standard SQL

CREATE VIEW <имя таблицы> [(<список столбцов представления>)]

AS <выражение запроса>

[WITH [<уровневая клауза>] CHECK OPTION]

<уровневая клауза> ::= CASCADED | LOCAL

    

<view column list> необязателен; когда он не указан, представление унаследует имена столбцов из запроса. Количество имён столбцов в <view column list> должно совпадать со степенью (количеством столбцов) выражения запроса. Если какие-либо два столбца в запросе имеют одинаковое имя столбца, вы должны указать <view column list>, чтобы разрешить неоднозначность. Одно и то же имя столбца не может быть указано более одного раза.

Опция <levels clause> в WITH CHECK OPTION не существовала в SQL-89 и не влияет на запросы, а только на операторы UPDATE, INSERT INTO и DELETE FROM. Мы подробно рассмотрим эту недооценённую возможность. Она связана с вложенными представлениями и тем, как они «разворачиваются» при событии в базе данных.

Продолжить чтение "Всматриваясь в ПРЕДСТАВЛЕНИЯ (VIEW)"

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

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

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

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

§ С Новым Годом, коллеги!
Здоровья и благополучия в новом году!

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 25 (Learn)		6		10
 122 (SELECT)		4		8
 27 (Learn)		2		7

§ Авторы недели на форуме

Автор		Сообщений
 pegoopik  	7
 selber  	2
 Rujan  	2

Продолжить чтение "Новости за 2025-12-27 - 2026-01-02"

Пересказ статьи Tudor Golubenco. Going down the rabbit hole of Postgres 18 features

Особое внимание в статье уделяется таким фундаментальным функциям, как инфраструктура асинхронного ввода-вывода и поддержка Oauth 2.0, оптимизации производительности, например, пропуску сканирования btree, а также долгожданным функциям, например, встроенной поддержке UUIDv7.

Но при свыше 3000 вкладах в релиз имеется множество других изменений помимо упомянутых, о которых вы можете захотеть узнать. Мы поставили себе задачу осветить как можно больше изменений и в итоге рассмотрели около 30 функций в этой длинной записи блога (почти 5000 слов).

Если вы все это не прочитаете, я вас не виню, итак, вот попытка на "слишком много букв":
Продолжить чтение "Ныряем в кроличью нору возможностей Postgres 18"

Пересказ статьи Mamadou Cisse. Booleans vs Integers in Databases: Understanding the Trade-Offs

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

При проектировании базы данных разработчики часто сталкиваются с выбором казалось бы простого решения: следует ли использовать булевы значения или целые для представления поля? Хотя на первый взгляд разница может показаться тривиальной, выбор может оказать существенное влияние на хранилище, поддержку и масштабируемость. Давайте исследуем "за" и "против" каждого подхода, сосредоточив внимание на размере хранилища, накладных операционных расходах и обслуживании в долгосрочной перспективе.
Продолжить чтение "Булевы значения и целые числа в базах данных: понимание компромиссов"

Joe Celko, Missing Data

Наше знание о реальности, которую мы пытаемся смоделировать в базе данных, не всегда является полным. Наиболее общие подходы к обработке таких отсутствующих данных сводились либо к их игнорированию, либо к их выводу, либо к их импутации (заполнению).

Игнорирование чего-либо говорит само за себя. В SQL мы очень часто используем NULL, когда у нас нет значения. Хотя использование NULL является спорным, они действительно дают нам единый, согласованный и чётко определённый набор правил для обработки отсутствующих значений. Но с точки зрения моделирования с ними есть проблемы. Помимо специальных вычислительных правил и общего принципа, что «NULL распространяются», который может быть сложным для изучения, более фундаментальная проблема заключается в том, что универсальный NULL в SQL охватывает по крайней мере два очень разных случая. Доктор Кодд позже исправил это в пересмотренной версии своей реляционной модели, добавив типы отсутствующих значений A и I. В одном случае значение неизвестно, но сущность обладает атрибутом. С таким типом NULL всегда возможно, что мы обнаружим (известное) значение. Пример, который мне нравится приводить: когда я ношу шляпу, всегда возможно, что у меня может быть цвет волос. Чтобы быть очень полным в выборе значений по этой шкале, я мог бы также включить «лысый» или даже «варикозные вены и пигментные пятна» в домен моих значений для цвета волос. С таким типом NULL (теоретически) возможно придумать какое-то осмысленное значение или маркер.

Второй тип NULL никогда не будет иметь значения, потому что сам атрибут отсутствует у сущности. Я могу с уверенностью сказать, как примат, что у меня не вырастут перья и не появится вариант цвета перьев. Такой тип NULL возникает в OUTER JOIN и других конструкциях, которые их генерируют. Например, конструкции GROUPING SETS, ROLLUP и CUBE должны иметь предикат для проверки NULL, который был создан, в отличие от NULL, который был в исходных данных. GROUPING (<список ссылок на столбцы>) возвращает двоичное число, в котором каждая позиция с единицей соответствует созданному NULL.

Продолжить чтение "Отсутствующие данные"

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 45 (DML)		8		7
 1 (Learn)		2		19
 24 (Learn)		2		12

§ Авторы недели на форуме

Автор		Сообщений
 rock_4  	8
 selber  	3
 hongweibin	3
 Канатоходец	2

Продолжить чтение "Новости за 2025-12-20 - 2025-12-26"

Пересказ статьи Vaitheeswaran L M. PostgreSQL Internals: Heaps, Pages, and CTIDs

Строки не просто "сидят" в таблице в PostgreSQL. Они живут внутри страниц, перемещаются при обновлении и всякий раз получают новые "адреса" (CTID). Давайте разберемся подробнее и посмотрим, как это работает на самом деле.

1. Куча: Движок хранилища PostgreSQL

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

Куча - это просто неупорядоченная коллекция строк (кортежей). В отличие от некоторых баз данных, PostgreSQL автоматически не сохраняет строки в неком отсортированном порядке или по первичному ключу. Вместо этого она просто добавляет их на доступное пространство внутри страниц (блоков фиксированного размера 8Кб на диске).


Продолжить чтение "PostgreSQL изнутри: кучи, страницы и CTID"

Пересказ статьи Brent Ozar. Which Should You Use VARCHAR or NVARCHAR?

Вы строите новую таблицу или добавляете столбец, и вы хотите знать, какой тип данных использовать: VARCHAR или NVARCHAR?

Если вам необходимо хранить данные Unicode, выбор сделан за вас: NVARCHAR говорит, что это буду я.

Но если вы не уверены, то можете подумать: "Я должен использовать VARCHAR, поскольку он занимает вдвое меньше места". Я это знаю, потому что чувствовал то же самое, но множество комментаторов указали мне на это, когда я опубликовал ответ в «Office Hours» о том, что по умолчанию я использую VARCHAR. Один за другим разработчики говорили мне, что я неправ и что в 2025 пришло время вместо этого по умолчанию использовать NVARCHAR. Давайте проведем эксперимент!

Чтобы выяснить это, давайте возьмем большую базу данных Stack Overflow и создадим две копии таблицы Users. Я использую здесь таблицу Users, чтобы сделать демонстрацию краткой и понятной, поскольку у меня нет возможности целый день загружать гигабайты данных (и перезагружаться, как вы сейчас увидите). Мы просто собираемся сфокусироваться на строковых столбцах, поэтому я создал одну с типами VARCHAR, а другую - с NVARCHAR. Затем для простоты мы загрузим только те данные, которые являются чисто VARCHAR (потому что некоторые чудаки могли добавить какие-нибудь необычные данные Unicode в столбец AboutMe).
Продолжить чтение "Что использовать: VARCHAR или NVARCHAR?"

Автор: Mayur B, The OOM-Killer Summoning Ritual: “Just Increase work_mem”

Вы, вероятно, видели такую картину инцидента:

1. Процессы (backend) PostgreSQL начинают исчезать.


2. dmesg / journalctl -k показывает, что OOM-Killer в ядре завершает процесс postgres.


3. Кто-то замечает «out of memory» и рефлекторно рекомендует: «Увеличь work_mem».

Эта рекомендация часто является обратной для случаев, когда OOM-Killer завершает процессы на уровне ОС.

Лингвистическая ловушка: «Out of memory» звучит как «недостаточно work_mem»

work_mem — это не «память для запроса». Это базовый бюджет на операцию для узлов исполнителя (executor nodes), таких как сортировки и хеш-таблицы, прежде чем они начнут сбрасывать данные во временные файлы (spill). В документации PostgreSQL прямо предупреждают, что сложный запрос может выполнять несколько операций сортировки/хеширования параллельно, и многие сеансы могут делать это одновременно, поэтому общий объём используемой памяти может во много раз превышать work_mem.

Если вы глобально повышаете work_mem, вы повышаете потолок для многих потенциальных одновременных потребителей памяти. Это может превратить «редкий скачок» в «частое завершение процессов OOM-Killer».

Продолжить чтение "Ритуал призвания OOM-Killer: «Просто увеличь work_mem»"

§ Усилена проверка задачи 186 (SELECT, обуч. этап) данными от Komov S.M.

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 779 (SELECT)		10		7
 44 (DML)		5		7
 188 (SELECT)		3		4
 780 (SELECT)		2		9
 1 (Learn)		2		9

Продолжить чтение "Новости за 2025-12-13 - 2025-12-19"

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

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

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

Продолжить чтение "Сравнение перестройки и реорганизации индексов SQL"