Подборка 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

Нашли удобный инструмент для миграций баз данных на Go — goose.

Что умеет:

• Управлять миграциями схемы базы данных через SQL-файлы или Go-функции.
• Работать с PostgreSQL, MySQL, MariaDB, SQLite, ClickHouse, SQL Server и другими популярными СУБД.
• Поддерживает откат миграций, применение до нужной версии, проверку статуса, сидирование данных и миграции, встроенные прямо в Go-приложение.

Полезный инструмент для Go-разработчиков, который помогает поддерживать структуру базы данных в актуальном состоянии, автоматизировать развёртывание и интегрировать миграции в CI/CD.

https://github.com/pressly/goose

👉 @SQLPortal

Нашли отличный материал о том, какие проблемы может создавать MVCC (Multi-Version Concurrency Control) в PostgreSQL и почему этот механизм не так прост, как кажется.

В статье разбирается, как MVCC позволяет чтению и записи выполняться без взаимных блокировок, но одновременно приводит к появлению «мёртвых» версий строк (dead tuples), росту размера таблиц, дополнительной нагрузке на VACUUM и другим скрытым издержкам. Автор объясняет, почему каждое UPDATE фактически создаёт новую версию строки и как это влияет на производительность базы данных.

Отличный материал для тех, кто хочет глубже понять внутреннее устройство PostgreSQL, разобраться в работе MVCC, механизмах видимости строк, VACUUM, HOT Updates и причинах деградации производительности при больших объёмах обновлений.

https://boringsql.com/posts/mvcc-bad-bad/

👉 @SQLPortal

Полезный совет для PostgreSQL

Знаете ли вы, что автоматизировать задачи в PostgreSQL можно с помощью расширения pg_cron?

Оно позволяет создавать задания по расписанию прямо внутри базы данных — без использования внешнего планировщика.

С помощью pg_cron можно автоматизировать, например:

• запуск VACUUM;
• обновление материализованных представлений (Materialized Views);
• выполнение регулярных SQL-запросов;
• другие задачи обслуживания базы данных.

Чтобы посмотреть список всех запланированных заданий, выполните:

SELECT * FROM cron.job;


pg_cron — удобный инструмент для автоматизации рутинных операций и поддержки PostgreSQL в рабочем состоянии без внешних средств планирования.

👉 @SQLPortal

Оптимизируйте работу с SQL

Улучшаем процесс разработки, добавив две мощные возможности: оператор Flow (->>) и UNION BY NAME.

Оператор Flow позволяет объединять SQL-запросы в цепочки по аналогии с Unix-конвейерами, где результат одного шага автоматически становится входными данными для следующего. Это делает код чище, избавляет от необходимости использовать временные таблицы или RESULT_SCAN() и позволяет строить более гибкие аналитические пайплайны.

UNION BY NAME выводит объединение данных на новый уровень. Вместо сопоставления столбцов по их порядку он автоматически объединяет их по именам. Это значительно упрощает работу с изменяющимися схемами данных, а отсутствующие столбцы автоматически заполняются значением NULL. Больше не нужно вручную переименовывать столбцы перед объединением.

Используя эти возможности вместе, вы сможете создавать более надежные, понятные и удобные в сопровождении SQL-пайплайны.

Подробности и примеры использования по ссылке.

👉 @SQLPortal

Добро пожаловать в мир разработки

Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков

🎓 Практические курсы и задания

🪽 Книги и статьи известных авторов

😮‍💨 Полезные инструменты и ресурсы

🌟 IT-новости и инсайды

Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, GIT, Linux, QA, Java, Vibe-coding, Infosec и др.

Ценишь знания, подпишись: Terminal_tg

Не направляйте каждый аналитический запрос или задачу поиска данных для ИИ-агентов напрямую в рабочую базу данных.

Spice — это open-source рантайм на языке Rust для разработчиков, которым нужны SQL-запросы, поиск и LLM-инференс рядом с существующими источниками данных.

Он помогает создавать приложения и ИИ-агентов, работающих с реальными данными, объединяя различные источники и предоставляя SQL, гибридный поиск и OpenAI-совместимые API из единого переносимого рантайма.

Основные возможности:

• Нативный CDC (Change Data Capture) — реплицирует изменения из PostgreSQL, MySQL и MongoDB, создавая готовые для аналитики реплики.
• Федеративные запросы — подключается более чем к 30 источникам данных и поддерживает query push-down для выполнения части запроса непосредственно в источнике данных.
• Гибридный поиск — объединяет векторный и полнотекстовый поиск с поддержкой RRF (Reciprocal Rank Fusion) и SQL-функций для повторного ранжирования результатов.
• Интерфейсы для ИИ — включает OpenAI-совместимые API, MCP-сервер и шлюз, а также поддержку Text-to-SQL.
• Гибкое развёртывание — может работать как один исполняемый файл, контейнер, sidecar или распределённый кластер.

https://github.com/spiceai/spiceai

Проект полностью open-source и распространяется по лицензии Apache 2.0.

👉 @SQLPortal

Нашли лёгкую альтернативу phpMyAdmin для работы с SQL-базами

Adminer — это веб-клиент, состоящий всего из одного PHP-файла.

Что умеет:

• Поддерживает PostgreSQL, MySQL, MariaDB, SQLite, Oracle, MS SQL и другие СУБД.
• Позволяет выполнять SQL-запросы, управлять таблицами, индексами, пользователями, а также импортировать и экспортировать данные.
• Поддерживает плагины, расширяющие возможности и добавляющие поддержку других источников данных.

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

https://github.com/vrana/adminer

👉 @SQLPortal