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

SQL & AI: Друзья или враги?
Еще пару лет назад мы обсуждали, заменит ли нейросеть разработчика. В 2026 году ответ стал очевиден: AI не заменил SQL-специалиста, но он радикально изменил правила игры.
Сегодня разбираемся, как превратить AI в мощного союзника и где расставлены ловушки, в которые попадают даже мидлы.

🤝 Почему AI - ваш лучший друг
🔹Прощай, шаблонный код
Написать 10 однотипных JOIN или сложную структуру CASE WHEN нейросеть может за секунды. Это экономит до 40% времени на рутине.

🔹Объяснение чужого кода
Получили в наследство legacy-запрос на 200 строк без единого комментария? AI отлично справляется с декомпозицией и объяснением логики «человеческим» языком.

🔹Генерация синтетических данных
Нужно быстро наполнить таблицу для тестов, соблюдая типы данных и связи? AI сделает это лучше любого скрипта-заполнителя.

⚠️ Почему AI - коварный враг
Главная проблема в том, что AI галлюцинирует уверенно.

🔹Каша из диалектов
Модель может предложить изящное решение на функциях PostgreSQL (например, DISTINCT ON), которые просто не существуют или работают иначе в вашей версии MySQL или ClickHouse.

🔹Производительность — не приоритет по умолчанию
Если не попросить специально оптимизировать запрос, AI выдаст код, который просто «работает». Он часто предлагает вложенные подзапросы там, где эффективнее CTE или оконные функции, и редко думает об использовании индексов.

🔹Отсутствие контекста БД
Нейросеть не знает объема ваших данных, наличия индексов и специфики «железа». Запрос, который AI посчитал идеальным, может «положить» ваш прод в пиковую нагрузку.

💡 Как выжить в эпоху AI-SQL?
Чтобы оставаться востребованным профи, фокус должен сместиться с «написания кода» на его аудит и архитектуру.

🔹Валидация — это закон
Никогда не копируйте код из чата в консоль без проверки EXPLAIN ANALYZE.

🔹AI как ревьюер
Попробуйте обратный подход — скормите нейросети свой рабочий запрос и спросите: «Как это оптимизировать?». Иногда она подсвечивает неочевидные узкие места.

🔹Изучайте теорию глубже
Чем лучше вы понимаете работу планировщика запросов и индексов, тем проще вам будет увидеть «галлюцинацию» в ответе нейросети.

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

Views vs Materialized Views: в чем разница?
Когда вы только начинаете работать с SQL, вам быстро надоедает писать один и тот же запрос на 20 строк с кучей джоинов. Чтобы не копипастить код, его можно сохранить прямо в базе. Для этого есть два способа: обычные Views (вьюхи) и материализованные.

Что такое View?
Это просто запрос, которому дали имя. База не создает новую таблицу и не копирует данные. Она просто запоминает ваш SELECT.
Когда вы пишете SELECT * FROM my_view, база «под капотом» подставляет ваш исходный код и выполняет его заново.

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

CREATE VIEW room_owners AS
SELECT r.id, r.home_type, u.name as owner_name
FROM Rooms r
JOIN Users u ON r.owner_id = u.id;

Теперь можно просто писать SELECT * FROM room_owners. База будет каждый раз пересчитывать джойн.
Плюс в том, что данные всегда актуальные.
Минус: если в таблицах миллионы строк, такая View начнет подтормаживать.

Что такое Materialized View
Здесь база выполняет запрос один раз и сохраняет результат в отдельную скрытую таблицу. Это спасение для тяжелых расчетов. Например, если мы хотим посчитать общую выручку по каждой комнате за всё время:

CREATE MATERIALIZED VIEW room_stats AS
SELECT room_id, SUM(total) as total_earned
FROM Reservations
GROUP BY room_id;

Результат читается мгновенно, потому что сумма уже посчитана и лежит на диске. Но есть нюанс: данные в ней «застывают». Если пришла новая бронь, сумма не изменится, пока вы не обновите View командой:

REFRESH MATERIALIZED VIEW room_stats;

Что выбрать?
Все зависит от того, что вам важнее: скорость или актуальность. Если данные нужны «прямо сейчас» — делайте обычную View. Если вы строите отчет за прошлый месяц, который не меняется каждую секунду — Materialized View сэкономит кучу ресурсов.