SEQUENCE (MySQL 8.0.29+) — современная альтернатива AUTO_INCREMENT

💡 Зачем знать
🔹 На собеседованиях всё чаще спрашивают: «Чем SEQUENCE отличается от AUTO_INCREMENT и зачем он нужен?»
🔹 В проде помогает, когда один источник чисел требуется сразу нескольким таблицам или когда нельзя допускать длинной блокировки PRIMARY KEY.

1️⃣ Что такое SEQUENCE?
Это отдельный объект в схеме, хранящий текущее значение счётчика.
🔹 Не привязан к конкретной таблице.
🔹 Умеет шаг ( INCREMENT ), начальное значение (START).
🔹 Получить число можно в любом запросе: NEXT VALUE FOR seq_name.

-- создаём последовательность с шага 1, стартуем с 10 000
CREATE SEQUENCE ticket_seq
    START WITH 10000
    INCREMENT BY 1;

2️⃣ Вставка чисел в таблицу

INSERT INTO tickets (id, user_id, created_at)
VALUES (NEXT VALUE FOR ticket_seq, 42, NOW());

Получаем уникальный id без AUTO_INCREMENT в самой таблице.

3️⃣ Один счётчик — много таблиц
Нужно, чтобы tickets и invoices шли в общей нумерации? Просто используйте ту же последовательность:

INSERT INTO invoices (id, total)
VALUES (NEXT VALUE FOR ticket_seq, 199.00);

4️⃣ Дополнительные возможности

-- увеличить шаг
ALTER SEQUENCE ticket_seq
  INCREMENT BY 10;

-- обнулить (осторожно!)
ALTER SEQUENCE ticket_seq
  RESTART WITH 50000;

-- посмотреть текущее значение
SELECT LAST_VALUE
FROM   INFORMATION_SCHEMA.SEQUENCES
WHERE  SEQUENCE_NAME = 'ticket_seq';

5️⃣ Сравнение с AUTO_INCREMENT 🤔
🔹 Объект:
– SEQUENCE — отдельный объект в схеме
– AUTO_INCREMENT — жёстко привязан к таблице

🔹Один счётчик для нескольких таблиц:
– SEQUENCE — да, можно использовать в любой таблице
– AUTO_INCREMENT — нет, только внутри своей таблицы

🔹Задать старт / шаг:
– SEQUENCE — гибко: START WITH, INCREMENT BY для каждой последовательности
– AUTO_INCREMENT — глобальные AI_OFFSET / AI_INCREMENT, меньше контроля

🔹Сброс счётчика:
– SEQUENCE — ALTER SEQUENCE … RESTART WITH n
– AUTO_INCREMENT — ALTER TABLE … AUTO_INCREMENT = n (только вверх от MAX(id))


✅ Итог
SEQUENCE = гибкий, «шарящийся» счётчик, который:
🔹Позволяет одной командой нумеровать разные таблицы.
🔹Даёт точный контроль над шагом и стартом.

SUBSTRING() / LEFT() / RIGHT() — извлекаем части строки ✂️

❗ Зачем нужно
Чистка и разбор данных — частая задача аналитика. Извлечь код страны из телефона, отделить год из даты в тексте, взять первые 3 буквы артикулы — всё это делается прямо в SQL, без кода на стороне приложения.

1️⃣ SUBSTRING() — получить подстроку

-- с 3-й позиции длиной 4 символа
SELECT SUBSTRING('ABCDEF', 3, 4);   
-- результат: 'CDEF'

-- начиная с 2-го символа до конца
SELECT SUBSTRING('123456', 2);      
-- результат: '23456'

-- отрицательный индекс = отсчёт от конца
SELECT SUBSTRING('hello', -2);      
-- результат: 'lo’

2️⃣ LEFT(str, N) — «первые N символов»

SELECT LEFT('8901234567', 2);   
-- '89'  (код страны)

3️⃣ RIGHT(str, N) — «последние N символов»

SELECT RIGHT('2025-04-30', 2);  
-- '30' (день)

💡 Практический пример: разбираем телефон

SELECT
    phone,
    LEFT(phone, 2) AS country_code,   
    -- первые 2 цифры
    SUBSTRING(phone, 3, 3) AS city_code,
    -- далее 3 цифры
    RIGHT(phone, 4) AS last_digits 
    -- последние 4
FROM contacts;

⚠️ Подводные камни
🔹 Нумерация с 1: первый символ — позиция 1, а не 0.
🔹 NULL → NULL: любое из функций вернёт NULL, если аргумент NULL — учитывайте в отчётах.

✅ Итог
🔹SUBSTRING — универсальный нож: позиция + длина.
🔹LEFT / RIGHT — быстрый способ взять начало или конец строки.

ELT() и FIELD() — превращаем числовой код в текст без JOIN 🏷️

❓ Зачем нужно
Частый кейс: в таблице хранится числовой статус (1 = “pending”, 2 = “done”, 3 = “failed”).
Обычно делают JOIN с маленьким справочником, но MySQL умеет отдать текст прямо в SELECT — скомпилируем «карманный словарь» функциями FIELD() + ELT().

1️⃣ FIELD(needle, list…) — возвращает позицию элемента

SELECT FIELD(3, 1,2,3,4);   
-- Результат: 3
SELECT FIELD('b', 'a','b','c');
-- Результат: 2

2️⃣ ELT(index, list…) — берёт элемент по номеру

SELECT ELT(3, 'pending','done','failed','unknown'); 
-- Результат: 'failed'

💡 Объединяем: число → позиция → текст

SELECT
    order_id,
    status_code,
    ELT(
        FIELD(status_code, 1,2,3,4),
        'pending','in_progress','done','failed'
    ) AS status_text
FROM orders;

🔹 FIELD находит позицию status_code в списке кодов,
🔹 ELT вытаскивает строку из второго списка той же длины.

3️⃣ Удобный вариант через CASE?
Да, но ELT/FIELD короче, особенно для 5-10 значений.

-- аналог на CASE (длиннее)
CASE status_code
  WHEN 1 THEN 'pending'
  WHEN 2 THEN 'in_progress'
  WHEN 3 THEN 'done'
  WHEN 4 THEN 'failed'
  ELSE 'unknown'
END

4️⃣ Подводные камни ⚠️
🔹 Если FIELD вернёт 0 (код не найден) — ELT() даст NULL.
🔹Порядок важен: списки в FIELD и ELT должны совпадать по длине и позиции.

✅ Итог
🔹FIELD() находит позицию кода, ELT() возвращает строку по этой позиции.
🔹Для 3-5 статусов — самый быстрый способ «раскрасить» отчёт без JOIN и CASE.

UUID() и UUID_SHORT() — генерируем уникальный ID без сервера приложений 🎲

❗Зачем знать
🔹Иногда нужно создать уникальный первичный ключ на стороне БД, а не приложения.

1️⃣ UUID() — стандартный 128-битный идентификатор

SELECT UUID();   
-- '550e8400-e29b-41d4-a716-446655440000'

🔹36 символов (32 шестн. + 4 дефисa).
🔹Практически нулевая вероятность коллизии.
🔹Минусы: длинная строка → индекс ~4× крупнее, хуже кэшируется.

2️⃣ UUID_SHORT() — компактный 64-битный вариант

SELECT UUID_SHORT();  
-- 281474976710661

🔹Возвращает BIGINT UNSIGNED (до 18 цифр).
🔹Формируется как: (server_id << 48) + (unix_ts << 24) + increment.
🔹Удобен для числовых PK 👉 индекс меньше, быстрее сортировка.
🔹Риск коллизии есть при одинаковом server_id (на реплике проверьте server_id!).

3️⃣ Практический пример: таблица заказов

CREATE TABLE orders (
  id CHAR(36) DEFAULT (UUID()) PRIMARY KEY,
  user_id INT,
  total DECIMAL(10,2)
);

✅ Итог
🔹UUID() — гарантированная уникальность, но тяжёлый индекс.
🔹UUID_SHORT() — компактный числовой ID, если контролируете server_id.
🔹Оба способа позволяют генерировать ключ прямо в MySQL без внешнего сервиса или кода приложения.

Деньги в MySQL: DECIMAL против FLOAT 💸

❗️Почему это важно
В финансах «копейка рубль бережёт»: ошибка 0.01 в одной транзакции, умноженная на тысячи строк, ломает отчёты и бухгалтерию.
Главный выбор — где хранить деньги: в DECIMAL или FLOAT?

1️⃣ Короткий ответ
🔹 Для сумм, цен, налогов — используйте DECIMAL(precision, scale).
🔹FLOAT/DOUBLE — приблизительные числа (двойичные), для денег не подходят.

2️⃣ Что такое DECIMAL и FLOAT?
🔹 DECIMAL(p, s) — точные десятичные числа.
Хранит каждую цифру (до 65 знаков, обычно s=2 или 4).
🔹 FLOAT/DOUBLE — числа с плавающей запятой в двоичной форме (IEEE 754).
Быстрые, но дают «хвосты» 0.1000000000001.

Пример проблемы с FLOAT:

CREATE TEMPORARY TABLE t_f (a FLOAT, b FLOAT);

INSERT INTO t_f VALUES (0.1, 0.2);
SELECT a + b AS sum_val FROM t_f;
-- sum_val может быть 0.3000000119...

Так же, но с DECIMAL:

CREATE TEMPORARY TABLE t_d (a DECIMAL(10,2), b DECIMAL(10,2));

INSERT INTO t_d VALUES (0.10, 0.20);
SELECT a + b AS sum_val FROM t_d;
-- sum_val = 0.30

3️⃣ Как выбрать размер DECIMAL
Типовой набор:
🔹DECIMAL(19,4) — для сумм и цен (4 знака после запятой хватает для НДС/комиссий).
🔹DECIMAL(10,2) — для розничных цен в «валютах с 2 знаками».

4️⃣ Альтернатива: хранить в «копейках»
Иногда суммы хранят как INT в минимальных единицах (центы/копейки).
Плюсы: быстрые индексы, чёткие сравнения.
Минусы: нужна дисциплина преобразований (делить/умножать на 100), разные валюты ≠ одинаковая точность.

5️⃣ Мини-резюме
🔹 Для денег — только DECIMAL (или INT в минимальных единицах).
🔹 Выберите подходящую точность (часто DECIMAL(19,4)).
🔹 Не складывайте «яблоки и апельсины»: валюты и точности должны быть явными.

Бэкап vs снапшот vs реплика — простое объяснение

Зачем это знать?
В реальной работе регулярно случается одно из трёх: сервер падает, кто-то удаляет данные, выходит неудачное обновление.
Спасают три разных инструмента — бэкап, снапшот и реплика. Они дополняют, а не заменяют друг друга.

Три понятия «на пальцах»
💾 Бэкап (backup)
Это отдельная копия данных, из которой можно развернуть базу заново — даже на другом сервере, через день/неделю.

📸 Снапшот (snapshot)
Это «моментальный снимок» диска/тома в текущем состоянии (LVM/ZFS/EBS и т.п.).
🔹Создаётся быстро, удобно откатиться перед апдейтом.
🔹Хранится на том же хранилище → если диск/массив сломается, снимок пропадёт вместе с ним.

🪞 Реплика (replication)
Это вторая копия базы, которая почти в реальном времени «повторяет» изменения с основной.
🔹Нужна для отказоустойчивости и масштабирования чтения.
🔹Если на мастер попала ошибка/удаление, она уйдёт и на реплику.

Что решает каждый инструмент
Бэкап → «машина времени»
🔹Восстановить состояние за конкретный день/время.
🔹Долгое хранение (архив), юридические требования.

Снапшот → «быстрый откат»
🔹Перед деплоем/миграцией: если что-то пошло не так — откат за минуты.
🔹Клонирование окружения для тестов.

Реплика → «всегда доступно»
🔹Быстро переключиться при падении мастера (failover).
🔹Разгрузить чтение (направить часть трафика на реплику).

Риски и подводные камни ⚠️
Бэкап
🔹«Бэкап есть» не значит «восстановится» — обязательны регулярные тесты восстановления.
🔹Нельзя хранить единственную копию рядом с базой; нужна отдельная площадка и шифрование.

Снапшот
🔹Хранится на том же хранилище → общая точка отказа.

Реплика
🔹Может отставать (лаг) — отчёты «сейчас» иногда смотрят на прошлое.

Практические рекомендации
Минимум для проекта
1️⃣ Ежедневный бэкап (полный или инкрементальный) → хранить вне сервера + шифровать.
2️⃣ Раз в неделю — проверка восстановления на тестовом стенде (restore-drill).
3️⃣ Перед любым рискованным обновлением — снапшот тома.

Мини-квиз по дате и времени в MySQL

1️⃣ Вопрос 1: Что вернёт запрос?

SELECT DATE_FORMAT(
  STR_TO_DATE('16-08-2024 21:15', '%d-%m-%Y %H:%i'),
  '%Y/%m/%d %H:%i'
);

a) 2024/16/08 21:15
b) 16/08/2024 21:15
c) 2024/08/16 21:15
d) Ошибка парсинга

Правильный ответ: c) 2024/08/16 21:15

2️⃣ Вопрос 2: Какой результат вернёт функция LAST_DAY?

SELECT LAST_DAY('2024-02-10');

a) 2024-02-28
b) 2024-02-29
c) 2024-03-01
d) NULL

Правильный ответ: b) 2024-02-29

3️⃣ Вопрос 3: Чему равна разница в минутах?

SELECT TIMESTAMPDIFF(
    MINUTE, 
    '2024-08-16 08:30:00', 
    '2024-08-16 10:05:00'
);

a) 90
b) 95
c) 120
d) 155

Правильный ответ: b) 95

4️⃣ Вопрос 4: Что произойдёт при добавлении интервала, если пересекается полночь?

SELECT TIMESTAMP('2024-08-16', '23:00:00') + INTERVAL 2 HOUR;

a) 2024-08-16 25:00:00
b) 2024-08-17 00:00:00
c) 2024-08-17 01:00:00
d) 2024-08-16 23:02:00

Правильный ответ: c) 2024-08-17 01:00:00

Мини-квиз

1️⃣ Вопрос 1: Что гарантирует LEFT JOIN?

SELECT c.id, o.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id;

a) Вернутся только клиенты с заказами
b) Вернутся все заказы, даже без клиентов
c) Вернутся все клиенты, даже если у них нет заказов
d) Дубликаты строк будут удалены

Правильный ответ: c) Вернутся все клиенты, даже если у них нет заказов

2️⃣ Вопрос 2: Что фильтрует группы после агрегирования?

SELECT department, COUNT(*) AS cnt
FROM employees
GROUP BY department
-- ?

a) WHERE cnt > 5
b) HAVING cnt > 5
c) ORDER BY cnt > 5
d) WINDOW cnt > 5

Правильный ответ: b) HAVING cnt > 5

3️⃣ Вопрос 3: Какой запрос лучше всего использует составной индекс (department, salary)?
a) WHERE salary > 1000
b) WHERE department = 'IT' AND salary > 1000
c) WHERE department LIKE '%IT%'
d) ORDER BY salary

Правильный ответ: b) WHERE department = 'IT' AND salary > 1000

Blob в mysql или ссылки на файлы — как выбрать? 🗂️
Задача: нужно хранить файлы (фото, pdf, видео). Где их держать: прямо в базе (BLOB) или во внешнем хранилище (например, S3) и в БД — только ссылку? Разберёмся коротко и понятно.

Что такое blob и «ссылки»
🔹 BLOB — двоичные данные прямо в таблице MySQL (поле BLOB/LONGBLOB).
🔹 Ссылка — файл лежит во внешнем хранилище, а в БД мы храним URL + метаданные (имя, размер, тип).

Когда хранить в базе (blob) 📦
Подходит, если:
🔹файлы небольшие (аватарки, превью, ≤ ~1 МБ);
🔹важна атомарность: данные и файл сохраняются/откатываются вместе;
🔹проект простой, без CDN и стриминга.

Плюсы: просто, транзакционно, один бэкап.
Минусы: база быстро растёт, бэкапы тяжелее, отдавать большие файлы медленно.

Мини-пример

CREATE TABLE file_blobs (
  id BIGINT PRIMARY KEY,
  name VARCHAR(255), 
  mime VARCHAR(100), 
  size INT,
  -- для дедупликации
  sha256 BINARY(32),
   -- сам файл
  data LONGBLOB NOT NULL,
  created_at TIMESTAMP,
  UNIQUE KEY (sha256)
);

Когда хранить снаружи (ссылки) 🔗
Подходит, если:
🔹файлов много или они крупные (фото/видео/доки);
🔹нужна раздача через CDN (быстрая доставка);
🔹важны дешёвое хранилище и лёгкие бэкапы БД.

Плюсы: масштабируемо, дёшево, быстро отдаётся.
Минусы: две системы (БД + хранилище).

Мини-пример

CREATE TABLE files (
  id BIGINT PRIMARY KEY,
  name VARCHAR(255), 
  mime  VARCHAR(100), 
  size INT,
  sha256 BINARY(32),
  -- https://... или s3://...
  storage_url VARCHAR(2048) NOT NULL,   
  created_at TIMESTAMP,
  UNIQUE KEY (sha256)
);

Быстрый чек-лист выбора ✅
🔹Размер: маленькие → BLOB; большие → ссылка.
🔹Транзакционность (вместе с бизнес-данными): нужна → BLOB.
🔹 Отдача файлов пользователям: нужен CDN → ссылка.
🔹Бэкапы и восстановление: хочется лёгких дампов → ссылка.
🔹Стоимость хранения: экономим → ссылка.

Вывод
🔹BLOB хорош для маленьких файлов и строгой консистентности.
🔹Ссылки — почти всегда лучший выбор для больших объёмов, скорости и экономии.

Топ-вопросы с собеседований по SQL + ответы 📝
Мы собрали самые популярные вопросы и варианты ответов — читайте по ссылке:
https://sql-academy.org/ru/interview-questions

Чтобы было удобнее, подготовили офлайн-версию (PDF). Сохраните и используйте, чтобы быстро освежить знания перед важным собесом.
📥 офлайн-версия — в файле к этому посту

удачи на собеседованиях! 💪

Мини-квиз по дате и времени в PostgreSQL

1️⃣ Вопрос 1: Парсинг даты одной функцией

SELECT to_date('16-08-2024', 'DD-MM-YYYY');

a) 16/08/2024
b) 2024-16-08
c) 2024-08-16
d) Ошибка парсинга

Правильный ответ: c) 2024-08-16

2️⃣ Вопрос 2: Разница в днях

SELECT DATE '2024-03-15' - DATE '2024-03-01';

a) 13
b) 14
c) 15
d) 16

Правильный ответ: b) 14

3️⃣ Вопрос 3: Номер недели (ISO) для актуальной даты

SELECT EXTRACT(WEEK FROM DATE '2026-01-01');

a) 0
b) 1
c) 52
d) 53

Правильный ответ: b) 1

4️⃣ Вопрос 4: Переход через полночь

SELECT TIMESTAMP '2024-08-16 23:00:00' + INTERVAL '2 hours';

a) 2024-08-16 25:00:00
b) 2024-08-17 00:00:00
c) 2024-08-17 01:00:00
d) 2024-08-16 23:02:00

Правильный ответ: c) 2024-08-17 01:00:00