«Его открывал мой муж. Поэтому и покинул нас в 45», - добавила она

👉 @SQLPortal

Вы можете использовать ORDER BY по столбцам, которых нет в SELECT-списке запроса.

...за исключением случая:

SELECT DISTINCT this FROM t ORDER BY that  --  некорректно!

Почему так?

DISTINCT удаляет дубликаты из выбранных значений и формирует новую таблицу,
поэтому доступны только те столбцы, что явно указаны в SELECT

Объяснение от Lukas Eder — blog.jooq.org

👉 @SQLPortal

SQL-приём, о котором мало кто знает

Знал ли ты, что внутри транзакции можно создавать контрольные точки с помощью SAVEPOINT? Вместо сценария, где при ошибке теряется вся работа.

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

SAVEPOINT — это как контрольные точки в трубопроводе. Если проблема возникает дальше по потоку, можно локализовать последствия, вернувшись к последней стабильной точке, не останавливая всю систему.

Следующий код откатывает всё:

BEGIN;

INSERT INTO orders VALUES (1, 'Laptop');
INSERT INTO payments VALUES (1, 'FAILED');

-- Здесь что-то пошло не так
ROLLBACK;  -- Удалит И заказ, И платёж

Если добавить SAVEPOINT, можно откатиться только к последней контрольной точке:

BEGIN;

INSERT INTO orders VALUES (1, 'Laptop');
-- Создаём контрольную точку
SAVEPOINT before_payment;

INSERT INTO payments VALUES (1, 'FAILED');

-- Платёж не прошёл — откатываем только его
ROLLBACK TO SAVEPOINT before_payment;

-- Пробуем альтернативный способ оплаты
INSERT INTO payments VALUES (1, 'SUCCESS');

COMMIT;

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

SAVEPOINT не устраняет ошибку, а ограничивает её последствия.

👉 @SQLPortal

Нужно быстро выгрузить данные? \copy записывает результат любого запроса в локальный файл.

\copy (SELECT * FROM users WHERE created_at > now() - interval '7 days') TO '~/new_users.csv' WITH CSV HEADER

Кейсы:

- Быстрый экспорт выборки без поднятия отдельного пайплайна или воркфлоу.
- Выгрузка данных для аналитики в CSV с последующей обработкой в pandas/BI.
- Отладка: снятие среза таблицы для локального воспроизведения бага.
- Миграции: подготовка данных перед переносом между окружениями.
- Интеграции: передача данных в сторонние системы через файл.
- Бэкап части данных по фильтру (например, последние 7 дней).
- Проверка гипотез: выгрузка подвыборки без нагрузки на основную систему.

👉 @SQLPortal

Для фоновых задач, таких как vacuum и создание индексов, Postgres использует специальное выделение памяти под названием maintenance_work_mem. Обычные запросы используют work_mem, чтобы определить, сколько памяти может быть выделено на одну операцию или соединение.

Если требуется ускорить выполнение задач, таких как:

> выполнение vacuum,
> создание индексов,
> создание индексов для материализованных представлений,

используйте:

SET maintenance_work_mem = '8GB';

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

👉 @SQLPortal

Понимание порядка выполнения SQL-запроса критично для написания корректных и оптимизированных запросов.

Запомни последовательность: FROM и JOIN, WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, затем LIMIT.

Освоение этого порядка ускоряет отладку и помогает мыслить как СУБД. #SQL #DataAnalytics #LearnSQL #Database

👉 @SQLPortal

Сегодня мы изучим импорт и экспорт данных в SQL:

SQL предоставляет механизмы для импорта данных в базу данных и экспорта их во внешние файлы.

Импорт данных:

Использование команды INSERT INTO SELECT для импорта данных из одной таблицы в другую:

INSERT INTO destination_table (column1, column2)
SELECT column3, column4 FROM source_table;

Экспорт данных:

Использование команды SELECT INTO OUTFILE для экспорта данных в файл:

SELECT column1, column2 INTO OUTFILE 'file_path.csv'
FIELDS TERMINATED BY ',' FROM table_name;

Эти операции полезны для:
🔻 Переноса данных между базами данных.
🔻 Архивации данных.
🔻 Обмена информацией с другими системами.

👉 @SQLPortal

Нужна быстрая задержка в скрипте или тесте?

SELECT pg_sleep(2); -- 2 секунды
SELECT pg_sleep(0.5); -- полсекунды
SELECT pg_sleep_for('5 minutes'); -- самодокументируемо

Удобно для симуляции медленных запросов, тестирования таймаутов или просто чтобы добавить драматизма в демо.

👉 @SQLPortal

Шпаргалка для изучения SQL и NoSQL баз данных

Выбор правильной базы данных имеет решающее значение для успеха проекта:

⏩Базы данных SQL предлагают структурированное хранилище данных, поддержку SQL и реляционной модели
⏩Базы данных NoSQL обеспечивают гибкость, масштабируемость и распределенную архитектуру
⏩Специализированные базы данных, такие как столбчатые, графовые, пространственные и базы данных временных рядов, удовлетворяют конкретные потребности

👉 @SQLPortal

NocoDB — превращает любой MySQL, PostgreSQL, SQL Server, SQLite и MariaDB в интеллектуальную электронную таблицу.

⛓ Ссылка: тык

👉 @SQLPortal

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

⛓ Ссылка: тык

👉 @SQLPortal

Держите потрясающе полезную шпаргалку по SQL ⚡️

👉 @SQLPortal

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

⛓ Ссылка: тык

👉 @SQLPortal

В PostgreSQL есть специальный параметр для логирования долго выполняющихся запросов — log_min_duration_statement.

После установки этого параметра PostgreSQL будет записывать в лог длительность и текст запроса, если он выполняется дольше указанного времени.

ALTER DATABASE postgres SET log_min_duration_statement = '500ms';

Это полезно для того, чтобы:

> определить, какие запросы работают медленно;
> понять, где можно добавить индексы для повышения производительности.

Параметр можно задать и на уровне сессии, если нужно логировать (или, наоборот, исключить из логирования) только конкретные запросы:

SET log_min_duration_statement = '20000ms';

log_min_duration_statement — действительно мощный инструмент, но мы обычно не рекомендуем устанавливать его на очень низкие значения (0, 1 или 5 мс), так как это приведёт к логированию практически всех операций базы данных. Это создаст шум в логах и может занять много места на диске.

👉 @SQLPortal

Не пиши SELECT DISTINCT, если проблему создаёт плохой JOIN

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

Плохо:

SELECT DISTINCT u.id, u.name
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days';

Лучше так:

SELECT u.id, u.name
FROM users u
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
      AND o.created_at >= CURRENT_DATE - INTERVAL '30 days'
);

DISTINCT часто добавляет sort или hash aggregation на огромном объёме.
EXISTS превращает задачу в semijoin:
• оптимизатору проще остановиться на первом совпадении
• меньше памяти, меньше лишних строк, стабильнее план

Это один из тех рефакторингов, который на больших таблицах реально даёт заметный буст.

👉 @SQLPortal

До сих пор разворачиваете PostgreSQL вручную?

Сэкономьте силы для задач разработки.

21 апреля в 16:00 (мск) пройдёт вебинар от MWS Cloud Platform, где эксперты компании расскажут, как получить готовую базу для бэкенда за несколько минут.

Что будет в эфире:

⚫️️️ облачный PostgreSQL: плюсы/минусы решения;
⚫️️️ как устроен управляемый сервис в новом облаке от MWS Cloud;
⚫️️️ машинерия под капотом бэкапов, автообновлений, switch и failover;
⚫️️️ создадим кластер за несколько минут и настроим подключение.

Вебинар будет интересен администраторам баз данных (DBA), бэкенд-разработчикам, DevOps- и SRE-инженерам, техническим лидам и архитекторам, владельцам продуктов и стартапам.

Зарегистрироваться

Совет для аналитиков данных;

Если проект в твоём портфолио почти не показывает, как он сэкономил компании деньги или время, с вероятностью 99% он никого не впечатлит.

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

👉 @SQLPortal

Когда-нибудь случайно удаляли таблицу? 👍

Oracle Database помещает её в корзину (recyclebin), так что вы можете восстановить её с помощью

FLASHBACK TABLE ... TO BEFORE DROP

и база данных восстановит её, включая индексы и (не внешние) ограничения.

Если хотите удалить её окончательно, используйте

DROP TABLE ... PURGE

👉 @SQLPortal

На этой неделе разбираем расширения Postgres, которые у тебя уже есть — они идут в составе библиотеки contrib.

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

Что делает: после включения отслеживает статистику запросов

Как включить:
CREATE EXTENSION pg_stat_statements;
добавить в shared_preload_libraries

Как использовать:
SELECT * FROM pg_stat_statements
или писать кастомные запросы для просмотра самых долгих и самых часто выполняемых запросов

Самые медленные запросы по суммарному времени

SELECT
  LEFT(query, 80) AS query,
  calls,
  ROUND(total_exec_time::numeric, 2) AS total_ms,
  ROUND(mean_exec_time::numeric, 2) AS avg_ms,
  rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

👉 @SQLPortal

Некоторые cron-задачи не должны покидать базу данных.
И Postgres даёт механизм, чтобы это реализовать.

Background Workers в Postgres — это процессы, которые работают внутри самого сервера базы данных. Не рядом, не «поблизости», а внутри него.

Типичный паттерн, который используют команды:
scheduler → приложение → база → логика в приложении → запись в базу

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

Инструменты вроде pg_cron построены на Background Workers. Задача выполняется как фоновый процесс внутри Postgres: читает состояние, выполняет логику, записывает результат — без участия приложения.

Это не просто «ближе к данным».
Это когда данные сами обрабатывают себя.

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

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

Но для небольших задач, завязанных на состояние и локальные данные — фоновый воркер внутри Postgres даёт более чистую архитектуру.

Проблема не в использовании cron.

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

Background Workers в Postgres позволяют это исправить.

Используешь pg_cron или фоновые воркеры в проде?

👉 @SQLPortal