Подборка SQL-запросов для быстрой диагностики PostgreSQL, которые помогают обнаружить проблемы ещё до того, как они перерастут в серьёзные сбои.

В статье собраны готовые запросы для поиска «мёртвых» строк, самых затратных SQL-запросов, таблиц с частыми Seq Scan, неиспользуемых индексов, зависших транзакций и блокировок, а также для оценки эффективности кэша PostgreSQL.

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

👉 @SQLPortal

SQL-совет: ORDER BY может учитывать регистр

Многие считают, что сортировка текста в SQL всегда происходит просто — от A до Z. Но это не всегда так.

В зависимости от СУБД и настроек сортировки (collation), ORDER BY может учитывать регистр символов.

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

apple
banana
cherry

вы можете получить:

Apple
Banana
apple
banana

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

Как отключить чувствительность к регистру? В SQLite для этого можно использовать COLLATE NOCASE:

SELECT *
FROM users
ORDER BY name COLLATE NOCASE;

Так SQL будет сортировать значения без учёта регистра, не изменяя сами данные.

Если результаты ORDER BY выглядят странно, первым делом проверьте настройки collation — именно они часто определяют, как база данных сравнивает и сортирует текст.

👉 @SQLPortal

Сегодня я разбирал реальные бизнес-кейсы на основе финтех-датасета.

Что удалось сделать:

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

Добавил тестовые транзакции вручную.
Автоматически перенёс успешные транзакции свыше ₦100 000 в отдельную таблицу с помощью INSERT INTO ... SELECT.

Но главный урок оказался вовсе не в синтаксисе SQL.

Я столкнулся с классической ошибкой новичков. Исходная таблица использовала стиль именования PascalCase (TransactionAmount), а новую таблицу я создал в snake_case (transaction_amount).

Из-за этого мои запросы постоянно выдавали ошибки.

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

👉 @SQLPortal

Вопрос по SQL:

Что вернёт этот запрос, если значение score равно NULL?

👉 @SQLPortal

20 нюансов PostgreSQL, о которых нужно знать

Подробный разбор основных аспектов работы с PostgreSQL — NULL, JSONB, индексация, вывод и многое другое.

👉 @SQLPortal

Нашли мощный AI-клиент для работы с базами данных

Chat2DB набрал почти 27 тысяч звёзд на GitHub

Что умеет:

Генерировать SQL-запросы по описанию на естественном языке — достаточно написать, что нужно получить, и ИИ сам составит запрос, включая сложные JOIN.

Работать сразу с десятками СУБД: MySQL, PostgreSQL, Oracle, SQL Server, SQLite и многими другими.

Анализировать данные и строить графики — можно просто спросить, например, «покажи продажи за прошлый месяц», и инструмент сам подготовит визуализацию.

Полезный инструмент для тех, кто часто работает с SQL и базами данных или хочет ускорить написание запросов с помощью ИИ.

👉 @SQLPortal

PostgreSQL vs MySQL

Обе СУБД написаны на языке C, но их архитектура устроена по-разному.

PostgreSQL: PostgreSQL использует процессную архитектуру (process-based). Представьте завод, где есть управляющий (Postmaster), который координирует работу отдельных сотрудников. Для каждого нового подключения создаётся собственный процесс, а все процессы используют общую область памяти. Фоновые процессы независимо выполняют запись данных на диск, очистку базы (VACUUM), ведение журналов и другие служебные задачи.

MySQL: MySQL использует потоковую архитектуру (thread-based). Здесь один сервер одновременно обслуживает множество подключений с помощью потоков. Ещё одна особенность — поддержка подключаемых движков хранения (например, InnoDB и MyISAM), которые можно выбирать в зависимости от требований проекта.

А какую СУБД предпочитаете вы — PostgreSQL или MySQL?

👉 @SQLPortal

Google выпустила Open Knowledge Format (OKF) — открытый формат для хранения знаний, понятный и людям, и ИИ-агентам.

Что внутри:

Представляет знания в виде обычных Markdown-файлов с YAML-метаданными — без привязки к конкретному фреймворку или поставщику моделей.

Подходит для описания таблиц БД, API, метрик, документации, плейбуков и других артефактов в едином формате.

Все данные можно хранить в Git, версионировать, связывать между собой и использовать как базу знаний для ИИ-агентов или поисковых систем.

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

👉 @SQLPortal

Фатальная ошибка в pandas

Такой код не фильтрует значения NULL или None:

df[df['user_id'] != None]

В pandas пропущенные значения представлены как NaN или None, но оператор != работает с ними не так, как многие ожидают.

Поэтому такой фильтр не удаляет все пропущенные значения.

Вместо этого используйте:

df[df['user_id'].notna()]

или

df.dropna(subset=['user_id'])

Для проверки пропущенных значений в pandas всегда используйте методы isna() и notna(), а не операторы == или !=.

👉 @SQLPortal

Разобрали, почему PostgreSQL рекомендуют запускать с режимом Strict Memory Overcommit в Linux.

В статье объясняется:

Что такое memory overcommit и почему стандартное поведение Linux может быть опасно для PostgreSQL.

Как OOM Killer способен завершить процесс Postgres при нехватке памяти, оставив сервер без возможности принимать новые подключения.

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

Какие параметры ядра (vm.overcommit_memory, vm.overcommit_ratio) влияют на работу PostgreSQL и как подобрать их для стабильной работы сервера.

Полезный материал для DBA, DevOps и всех, кто администрирует PostgreSQL в Linux и хочет лучше понимать причины OOM-ошибок и настройки памяти.

https://clickhouse.com/blog/strict-memory-overcommit-for-postgres

👉 @SQLPortal

Большой шаг вперёд для PostgreSQL

Долгое время полнотекстовый поиск считался одной из слабых сторон Postgres. Если требовался качественный поиск с ранжированием по релевантности, обычно приходилось разворачивать Elasticsearch, подключать Algolia или использовать другие внешние сервисы, постоянно синхронизируя данные.

Проблема была не в том, что PostgreSQL не умеет искать по тексту. Умеет. Но встроенная функция ts_rank использует относительно простой алгоритм ранжирования, который уступает современным поисковым движкам.

Из-за этого многие команды были вынуждены:

• Поднимать отдельный кластер Elasticsearch только ради поиска.
• Поддерживать пайплайны синхронизации данных между системами.
• Платить за управляемые поисковые сервисы.
• Мириться с не самым качественным ранжированием результатов.

Теперь появилась альтернатива — pg_textsearch, новое open-source расширение для PostgreSQL от TigerData.

Что оно предлагает:

• Поддержку алгоритма BM25 — того самого, который используется в Elasticsearch, Lucene и большинстве современных поисковых систем.
• Простой SQL-синтаксис для поиска:

ORDER BY content <@> 'search terms'

• Совместимость с конфигурациями полнотекстового поиска PostgreSQL для разных языков.
• Возможность объединить поиск по ключевым словам и векторный поиск через pgvector, что особенно полезно для RAG-приложений.

Расширение распространяется с открытым исходным кодом по лицензии PostgreSQL и позволяет реализовать современный поиск прямо внутри Postgres, без необходимости использовать отдельную поисковую инфраструктуру.

https://github.com/timescale/pg_textsearch

👉 @SQLPortal