Разбор сложных вопросов по SQL, индексам и архитектуре БД. Практические задачи для Middle и Senior инженеров с ответами.
Если в 2020-х годах было достаточно знать уровни изоляции транзакций и уметь строить индексы, то сегодня интервьюеры копают глубже. Ожидается понимание того, как база данных взаимодействует с операционной системой, как работают механизмы Write-Ahead Logging (WAL) и почему LSM-деревья вытесняют B-деревья в высоконагруженных системах с интенсивной записью.
На собеседованиях уровня Middle+ стандартный вопрос про индексы часто перерастает в обсуждение внутренней структуры.
Важно различать, где какой индекс эффективнее. B-деревья (PostgreSQL, MySQL) оптимизированы для чтения и выборок по диапазонам. LSM-деревья (RocksDB, Cassandra, ScyllaDB) выигрывают на записи за счет последовательного сброса данных из памяти на диск. В 2026 году часто спрашивают про гибридные решения, например, как реализовано хранение в современных версиях движков типа WiredTiger (MongoDB).
С развитием RAG-систем (Retrieval-Augmented Generation) в SQL-базы добавили поддержку векторного поиска. Ожидайте вопросы про pgvector в Postgres: разницу между IVFFlat и HNSW индексами. HNSW (Hierarchical Navigable Small Worlds) обеспечивает быстрее поиск, но потребляет больше оперативной памяти и дольше строится.
Классика по-прежнему актуальна, но теперь ее проверяют через практические кейсы. Вместо зазубривания определений ACID, вас попросят спроектировать систему перевода денег между кошельками в условиях распределенной БД.
Интервьюеры проверяют понимание Multi-Version Concurrency Control. Как именно база понимает, какую версию строки отдать транзакции? В Postgres это реализуется через скрытые поля xmin и xmax. Нужно уметь объяснить, почему Read Committed в Postgres ведет себя не так, как в Oracle, и в каких случаях возникает Write Skew даже на уровне Snapshot Isolation.
Практическая часть часто включает анализ плана выполнения.
Для Senior-позиций обязательны вопросы по CAP-теореме и PACELC. В 2026 году популярны дискуссии о NewSQL (CockroachDB, TiDB, YugabyteDB).
Нужно понимать разницу между Linearizability и Eventual Consistency. Как работает протокол Raft или Paxos для обеспечения консенсуса при репликации логов. Почему в распределенной системе невозможно добиться идеальной синхронизации без задержек (Latency vs Consistency).
Граница между SQL и NoSQL размылась. Современный PostgreSQL эффективно работает с типом JSONB. На собеседовании могут спросить: когда стоит выносить данные в отдельную таблицу, а когда оставить в JSONB? Ответ кроется в частоте обновлений (JSONB переписывается целиком) и необходимости индексации отдельных полей через GIN-индексы.
Типовая задача: «Напишите запрос для поиска топ-3 категорий товаров по выручке за последний месяц, используя оконные функции».
SELECT category_id, revenue, RANK() OVER (ORDER BY revenue DESC) as rnk FROM (SELECT category_id, SUM(price) as revenue FROM orders WHERE order_date > now() - interval '1 month' GROUP BY category_id) tmp WHERE rnk <= 3;
Вас также попросят оптимизировать этот запрос, если в таблице orders 1 миллиард строк. Здесь стоит упомянуть партиционирование по датам и материализованные представления (Materialized Views).
IVFFlat разбивает векторы на кластеры, он быстрее строится и занимает меньше места, но точность поиска падает при росте базы. HNSW строит граф соседства, он обеспечивает высокую точность и скорость поиска (Sub-linear), но требует значительного объема RAM для хранения графа.
Обычный VACUUM только помечает строки как свободные для повторного использования внутри таблицы. Чтобы вернуть место ОС, нужен VACUUM FULL, который блокирует таблицу. Также очистке могут мешать долгие транзакции (Long-running transactions) или зависшие слоты репликации.
Это аномалия, когда две транзакции читают одни и те же данные, принимают решение о записи на основе прочитанного и фиксируют изменения. В итоге нарушается бизнес-логика, хотя конфликта строк нет. Встречается на уровне Snapshot Isolation (в Postgres это уровень Repeatable Read).
CTE лучше для читаемости и когда данные нужны один раз в рамках запроса. Временные таблицы (Temporary Tables) стоит использовать, если промежуточный результат велик, на него нужно навесить индекс или использовать его в нескольких разных запросах в рамках одной сессии.
Это процесс сброса «грязных» страниц из буферного кеша в памяти на диск. Он необходим для сокращения времени восстановления после сбоя. Чем чаще чекпоинты, тем быстрее восстановление, но выше нагрузка на дисковую подсистему (I/O spikes).
Глубокий разбор оптимизации SQL запросов и работы индексов для собеседований уровня Middle и Senior в 2026 году.
Разбор ключевых вопросов по SQL для начинающих в 2026 году. Практические задачи на JOIN, агрегацию и фильтрацию данных с примерами кода.
Узнайте зарплаты Data Scientist и Data Analyst
Смотреть зарплаты
