Базы данных

INNER JOIN оставляет лишь строки, совпавшие в обеих таблицах. LEFT/RIGHT OUTER JOIN берут все строки одной стороны с NULL для отсутствующей. FULL OUTER JOIN хранит несовпавшие строки обеих сторон. Условие — в ON или USING.

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

Сделайте left join с заказами и оставьте несопоставленные строки: SELECT c.id, c.name FROM Customers c LEFT JOIN Orders o ON c.id = o.customer_id WHERE o.customer_id IS NULL. Анти-join LEFT JOIN ... IS NULL оставляет ровно тех клиентов, у кого нет подходящего заказа.

Сгруппируйте по столбцу и оставьте группы размером > 1: SELECT email FROM Person GROUP BY email HAVING COUNT(*) > 1. Фильтровать агрегат нужно через HAVING, а не WHERE — WHERE вычисляется до группировки строк, поэтому не видит COUNT(*).

Транзакция — это последовательность операций БД как одна единица. ACID: атомарность (всё или ничего, иначе откат), согласованность (только корректные состояния), изоляция (транзакции не мешают), долговечность (зафиксированные данные переживут сбой).

COMMIT сохраняет изменения навсегда, ROLLBACK отменяет их, SAVEPOINT отмечает точку частичного отката, а SET TRANSACTION настраивает свойства. Они применяются к DML (INSERT/UPDATE/DELETE), а не к DDL вроде CREATE.

Сделайте left join от отделов и посчитайте соединённый ключ: SELECT d.name, COUNT(e.id) FROM Departments d LEFT JOIN Employee e ON e.dept_id = d.id GROUP BY d.id, d.name. Используйте COUNT(e.id) (а не COUNT(*)), чтобы пустой отдел показал 0 — COUNT(*) посчитал бы одну строку с NULL как 1.

Возьмите максимум зарплаты строго ниже общего максимума: SELECT MAX(salary) FROM Employee WHERE salary < (SELECT MAX(salary) FROM Employee). Это аккуратно возвращает NULL, когда второй зарплаты нет. Альтернатива: ORDER BY salary DESC LIMIT 1 OFFSET 1 по DISTINCT зарплатам.

Проранжируйте внутри каждого отдела и оставьте ранг 1: SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM Employee) t WHERE rn = 1. PARTITION BY dept_id перезапускает ранжирование на каждый отдел — каноничный паттерн top-N в группе.

Сделайте self-join по связи с руководителем и сравните зарплаты: SELECT e.name FROM Employee e JOIN Employee m ON e.manager_id = m.id WHERE e.salary > m.salary. Таблица соединяется сама с собой: одна копия — сотрудник, другая — руководитель, через manager_id → id.

EXPLAIN показывает выбранный план с оценочной стоимостью, не выполняя запрос. EXPLAIN ANALYZE реально выполняет его и сообщает фактические тайминги и число строк — включая побочные эффекты, поэтому INSERT/UPDATE/DELETE оборачивай в транзакцию с откатом.

Они меняют изоляцию на параллелизм, задавая допустимые аномалии: Read Uncommitted (грязное чтение), Read Committed (без него), Repeatable Read (без неповторяющегося), Serializable (без аномалий). Высокие уровни медленнее.

Проранжируйте зарплаты оконной функцией и отфильтруйте по рангу: SELECT salary FROM (SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM Employee) t WHERE rnk = :N. DENSE_RANK даёт равным зарплатам одинаковый ранг без пропусков в нумерации.

PostgreSQL — объектно-реляционная, ближе к стандартам и богаче (богатые типы, CTE, оконные запросы, серверные курсоры). MySQL предлагает подключаемые движки хранения вроде InnoDB и исторически заточена под скорость чтения и поиск по ключу.

Используйте оконный SUM с упорядоченной рамкой: SELECT id, name, salary, SUM(salary) OVER (ORDER BY hire_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_total FROM Employee. Рамка накапливает от первой строки до текущей.

В стандартном SQL/PostgreSQL настоящих вложенных транзакций нет: транзакция, начатая внутри активной, входит в ту же внешнюю транзакцию. COMMIT фиксирует всю внешнюю транзакцию сразу; реальная вложенность эмулируется через SAVEPOINT, позволяющий частичный откат.

При MVCC обновления и удаления оставляют старые версии строк («мёртвые кортежи»), не удаляя их сразу. VACUUM освобождает это место и обновляет видимость и статистику, поэтому его надо запускать периодически, особенно на изменяемых таблицах.

Грязное чтение (видны незафиксированные данные) — блокируется с Read Committed. Неповторяющееся чтение (повтор видит изменённую строку) — с Repeatable Read. Фантомное чтение (повтор запроса видит новые строки) — на Serializable, через 2PL или SSI.

MVCC хранит несколько версий строк; каждая транзакция читает из снимка на момент своего старта, поэтому читатели не блокируют писателей и наоборот, давая повторяемое чтение без блокировок. Старые версии — это мёртвые кортежи, которые убирает VACUUM.