☕️ Наткнулся на любопытную статью — автор написал собственный in-memory движок для MariaDB.

В этой статье:
• Пошаговая сборка MariaDB из исходников и первые «твики» результатов
• Реализация минимального движка MEMEM с поддержкой CREATE/INSERT/SELECT
• Отличие API движков хранения MariaDB от Postgres

🔊 Подробное руководство лежит на Habr!

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

PARTITION PRUNING — читаем только нужные данные!

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

Чтобы ускорить выборку, разобьём таблицу на разделы по дате с помощью range partitioning:

CREATE TABLE sales (
  sale_date DATE,
  amount NUMERIC
) PARTITION BY RANGE (sale_date);

Теперь создадим конкретные партиции — каждая отвечает за свой месяц:

CREATE TABLE sales_2024_01 PARTITION OF sales
  FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE sales_2024_02 PARTITION OF sales
  FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

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

SELECT SUM(amount)
FROM sales
WHERE sale_date BETWEEN '2024-01-01' AND '2024-01-31';

Добавим EXPLAIN ANALYZE, чтобы увидеть, как именно Postgres выполняет запрос:

EXPLAIN ANALYZE
SELECT SUM(amount)
FROM sales
WHERE sale_date BETWEEN '2024-01-01' AND '2024-01-31';

🔥 Важно: pruning работает только, если условие по дате написано явно — без функций, кастов и переменных.

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

😎 W3Resource — онлайн-площадка, предназначенная для прокачки навыков работы с базами данных!

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

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

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

ON CONFLICT DO NOTHING — апсерты без ошибок!

Когда вы вставляете данные в таблицу с уникальными ограничениями, может прилететь ошибка: дубликат ключа нарушает уникальность. Особенно обидно, если часть данных уже вставлена, а часть — нет.

Чтобы обойти это — используем ON CONFLICT DO NOTHING. Он просто пропустит строки, которые уже есть.

Допустим, у нас есть таблица с пользователями, где email должен быть уникальным:

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

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

INSERT INTO users (email)
VALUES ('[email protected]'),
       ('[email protected]'),
       ('[email protected]');  -- дубликат!

Результат будет неудачным — Postgres выдаст ошибку и отменит всю операцию. Однако с ON CONFLICT всё работает иначе:

INSERT INTO users (email)
VALUES ('[email protected]'),
       ('[email protected]'),
       ('[email protected]')
ON CONFLICT DO NOTHING;

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

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