🤔 DBA1 — материалы по администрированию PostgreSQL и базам данных!

Сайт посвящён изучению PostgreSQL и администрированию баз данных. Здесь собраны учебные материалы по установке и настройке PostgreSQL, работе с сервером, архитектуре СУБД, управлению пользователями, резервному копированию, репликации и другим задачам, с которыми сталкиваются DBA и backend-разработчики.

📌 Оставляю ссылочку: dba1.ru

➡️ SQL Ready | #ресурс

📂 MySQL JOIN: шпаргалка по объединению таблиц!

Разобраны способы объединения таблиц, получение связанных данных, поиск совпадающих и отсутствующих записей, а также использование EXISTS и NOT EXISTS для проверки связей между таблицами.

На картинке — основные типы JOIN в MySQL с примерами SQL-запросов и визуальным объяснением.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

👍 PingCAP Talent Plan — практический курс по разработке системного уровня!

Этот репозиторий содержит учебные материалы и практические задания по разработке высоконагруженных систем. Основной фокус — внутреннее устройство баз данных, распределённые системы, хранение данных, производительность и инженерные подходы, которые используются в реальных проектах.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Разбираем почему REINDEX не заменяет VACUUM в PostgreSQL!

После большого количества операций UPDATE и DELETE в PostgreSQL часто используют команды VACUUM и REINDEX. Несмотря на то что обе относятся к обслуживанию базы данных, они решают разные задачи и не являются взаимозаменяемыми.

Создадим таблицу:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT
);

Добавим данные:

INSERT INTO users (email)
SELECT 'user' || g || '@mail.com'
FROM generate_series(1, 100000) AS g;

Удалим половину строк:

DELETE
FROM users
WHERE id <= 50000;

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

Для их обработки используется:

VACUUM users;

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

При этом обычный VACUUM обычно не уменьшает размер файла таблицы на диске — освободившееся место остаётся внутри таблицы и используется последующими операциями INSERT и UPDATE. Теперь перестроим индекс:

REINDEX INDEX users_pkey;

Или сразу все индексы таблицы:

REINDEX TABLE users;

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

При этом REINDEX не очищает таблицу от мёртвых версий строк и не заменяет выполнение VACUUM. Если же необходимо физически уменьшить размер таблицы и вернуть свободное место операционной системе, используется другая команда:

VACUUM FULL users;

VACUUM FULL полностью переписывает таблицу в новый компактный файл, освобождает место на диске, но требует блокировку уровня ACCESS EXCLUSIVE, поэтому на время выполнения таблица становится недоступной для чтения и записи.

Важно понимать, что в большинстве случаев регулярное обслуживание выполняет autovacuum. Ручной запуск VACUUM, VACUUM FULL или REINDEX обычно является следствием анализа конкретной проблемы, а не стандартной процедурой после большого количества изменений данных.

🔥 Главное отличие: VACUUM обслуживает таблицу и связанные с ней индексы, освобождая пространство, занятое мёртвыми версиями строк, для повторного использования. REINDEX занимается исключительно перестроением индексов. Эти команды решают разные задачи и используются в разных ситуациях.

➡️ SQL Ready | #практика

👨‍💻 Мега информативная статья на Хабре: «Что мы находим при аудите PostgreSQL: 10 распространенных ошибок»!

В этой статье:
• Разбираются реальные проблемы, которые DBA чаще всего находят при проверке PostgreSQL в продакшене;
• Показывается, почему бэкапы могут оказаться бесполезными, а широкие права, открытый доступ и отсутствие логов создают серьезные риски;
• Разбираются настройки производительности, долгие транзакции, BLOAT, автовакуум и архитектурные ошибки, которые могут привести к сбоям.

🔊 Продолжайте читать на Habr!

➡️ SQL Ready | #статья

📂 Как SQL-запрос выполняется внутри СУБД!

От отправки запроса до результата SQL проходит несколько этапов: парсинг, оптимизация, построение плана выполнения, доступ к данным, кэширование и управление транзакциями.

На схеме — архитектура обработки SQL-запроса и основные компоненты базы данных.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

👨‍💻 Yandex Cloud — инженерные материалы по SQL и базам данных!

На сайте собраны статьи и документация по работе с базами данных и SQL. Материалы помогают разобраться не только с написанием запросов, но и с тем, как работают внутренние механизмы СУБД: транзакции, индексы, оптимизация запросов, распределённые базы данных и эксплуатация систем.

📌 Оставляю ссылочку: yandex.cloud

➡️ SQL Ready | #ресурс

📂 Git Fundamentals: шпаргалка по основным операциям и workflow!

Разобраны основные элементы Git-экосистемы: структура репозитория, работа с индексом (staging area), создание коммитов, управление ветками, слияние изменений, взаимодействие с remote-репозиториями и основные команды для ежедневной разработки.

На картинке — визуальное представление Git workflow, жизненный цикл изменений от рабочей директории до удалённого репозитория, а также базовые операции commit, branch, merge, fetch, pull и push.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

🧐 Материалы по базам данных — информатвный набор для изучения SQL и СУБД!

Большая подборка учебных материалов по базам данных: книги, лекции, лабораторные работы и задания по SQL, PostgreSQL и Microsoft SQL Server. Внутри собраны материалы по ключевым темам, которые нужны разработчику при работе с базами данных: основы реляционной модели и проектирования БД, нормализация данных и ограничения (constraints), агрегатные функции, JOIN, подзапросы и др.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Сравнивайте несколько колонок как одно значение!

В PostgreSQL необязательно расписывать сравнение нескольких полей через длинные цепочки AND и OR. Можно использовать row constructor comparison — сравнить сразу кортежи значений.

Например, условие для keyset pagination часто пишут так:

WHERE user_id > :user_id
   OR (user_id = :user_id AND id > :id)

Но PostgreSQL умеет выразить то же самое напрямую:

WHERE (user_id, id) > (:user_id, :id)
ORDER BY user_id, id
LIMIT 100;

Сравнение идёт слева направо: сначала user_id, а если значения равны — id. Поэтому конструкция естественно совпадает с лексикографическим порядком составного ORDER BY.

И это не просто сокращение синтаксиса. Под такой запрос можно сделать обычный составной B-tree индекс:

CREATE INDEX orders_user_id_id_idx
ON orders (user_id, id);

Тот же приём работает с диапазонами составных ключей:

WHERE (year, month) >= (2026, 4)
  AND (year, month) <  (2027, 1)

🔥 Row comparison позволяет заменить громоздкую булеву логику сравнением кортежей и особенно хорошо ложится на keyset pagination и составные B-tree индексы. Важно только помнить про NULL: обычные сравнения с ним могут дать UNKNOWN.

➡️ SQL Ready | #совет

👨‍💻 Наткнулся на интересную статью на Хабре: «Реализация автоудаления блокирующих сессий в MS SQL»!

В этой статье:
• Разбирается механизм поиска корневых блокирующих сессий с помощью системных представлений MS SQL Server;
• Показывается, как реализовать автокиллер на T-SQL с логированием, анализом цепочек блокировок и безопасным удалением зависших транзакций;
• Объясняется, как автоматизировать мониторинг блокировок через SQL Server Agent и сохранить историю для последующего анализа.

🔊 Продолжайте читать на Habr!

➡️ SQL Ready | #статья