Собеседования по MySQL — особый жанр. Можно отлично писать запросы в работе, а на интервью растеряться, когда спросят, чем REPEATABLE READ отличается от READ COMMITTED. Или почему запрос с LIKE ‘%text%’ не использует индекс. Или что такое кластерный индекс и при чём тут первичный ключ.
В статье — не только список актуальных вопросов. Мы разобрали, что на самом деле проверяет интервьюер, какие ответы считаются правильными для junior, а какие ожидают от middle, и как действовать, если не знаешь, что отвечать.
Информация актуальна на середину 2026 года. Это важно: MySQL 8.0 достигла конца поддержки (End-of-Life) в апреле 2026. Если на собеседовании назовёте 8.0 актуальной версией — покажете, что не следите за экосистемой. Для консервативных продакшен-систем остаётся актуальной MySQL 8.4 LTS: Premier Support действует до апреля 2029 года, Extended Support — до апреля 2032-го. В апреле 2026 года вышла следующая LTS-линия — MySQL 9.7. Про это тоже поговорим. А начнём с того, как вообще устроены собеседования по MySQL.
У НАС ЕСТЬ КАРЬЕРНЫЙ БОТ
Внутри бота актуальные дорожные карты по профессиям, разборы карьерных треков и истории тех, кто уже прошёл этот путь. Иногда там же лежит промокод на курсы Практикума.
Откройте бота (можно просто кликнуть) и узнайте как расти в IT, если вы джун, мидл или сеньор!
Как устроены собеседования по MySQL
Формат бывает разный. Одним дают тест из 10–15 вопросов на знание синтаксиса. Других сажают за ноутбук с пустым редактором и просят написать запрос по описанию таблиц. Третьим задают вопросы устно и оценивают, как они рассуждают.
У junior проверяют базу: типы данных, ключи, JOIN, простые запросы с GROUP BY. Могут спросить, что такое транзакция и зачем нужны индексы. Ответы должны быть уверенными, но глубокого погружения в механизмы не ждут.
На уровне middle проверяют не столько знание синтаксиса, сколько понимание причин. Почему запрос медленный и как это исправить. Почему в этой таблице InnoDB, а не MyISAM. Почему уровень изоляции по умолчанию именно REPEATABLE READ. Важно объяснить это простыми словами, а не просто выдать заученное определение.
Лайвкодинг — практическая часть собеседования. Вам дают описание двух-трёх таблиц и просят написать запрос. Например: «выведите список клиентов, у которых нет заказов». Или «найдите отделы со средней зарплатой выше 50 000». Интервьюер оценивает и запрос, и ход мыслей. Проговаривание рассуждений вслух часто даёт больше очков, чем молчаливый правильный ответ. Если вы ошиблись, но объяснили, как рассуждали, — это плюс.
Ещё один важный момент: на собеседованиях любят задавать один и тот же вопрос в разных формулировках. «Чем INNER JOIN отличается от LEFT JOIN?» и «Что вернёт LEFT JOIN, если совпадений нет?» — по сути одно и то же, но проверяют разные грани понимания. Будьте к этому готовы.
Теперь пройдёмся по темам в том порядке, в каком их чаще всего спрашивают.
Базовые вопросы: типы данных и ключи
Это входной билет. Если на этих вопросах запинаетесь — дальше, скорее всего, даже не станут слушать.
Вопрос: чем PRIMARY KEY отличается от UNIQUE?
Короткий ответ: PRIMARY KEY — уникальный и не может содержать NULL. UNIQUE — уникальный, но NULL допускает. В таблице может быть только один PRIMARY KEY и несколько UNIQUE-ограничений; их максимальное количество зависит от версии MySQL и движка хранения.
Разбор (что проверяет интервьюер): Интервьюер проверяет, понимаете ли вы базовые ограничения целостности. PRIMARY KEY — это не просто уникальность, это ещё и способ идентификации записи. В InnoDB строки хранятся в кластерном индексе, ключом которого обычно служит PRIMARY KEY. Если первичного ключа нет, InnoDB выбирает первый подходящий UNIQUE-индекс с полями NOT NULL, а если нет и его — создаёт скрытый служебный идентификатор. Это важно для понимания производительности, но на уровне junior достаточно знать про NULL и количество ключей.
Вопрос: зачем нужен FOREIGN KEY и что произойдёт при удалении родительской записи?
Короткий ответ: FOREIGN KEY обеспечивает ссылочную целостность — связывает записи в двух таблицах. При удалении родительской записи поведение зависит от ON DELETE: CASCADE — удаляются и дочерние записи; RESTRICT или NO ACTION — удаление блокируется, если есть дочерние записи; SET NULL — внешний ключ в дочерних записях становится NULL.
Разбор: Здесь проверяют не столько знание синтаксиса, сколько понимание каскадных операций и их последствий. В реальных проектах FOREIGN KEY используют не всегда — иногда ограничения переносят на уровень приложения. Но знать, как они работают, обязаны. Интервьюер может спросить, что случится, если попытаться удалить родительскую запись с ON DELETE RESTRICT — правильный ответ: ошибка, операция не выполнится.
Вопрос: в чём разница между CHAR и VARCHAR?
Короткий ответ: CHAR хранит строки фиксированной объявленной длины, а VARCHAR — строки переменной длины и дополнительно использует один или два байта для хранения длины. Фактический объём зависит от кодировки, формата строк и используемого движка.
Разбор: Вопрос кажется простым, но интервьюер проверяет понимание того, как MySQL хранит данные на диске. CHAR быстрее для фиксированных значений (например, коды стран, пол), потому что не нужно читать информацию о длине. VARCHAR подходит и для строк длиннее 255 символов. TEXT выбирают, когда нужен больший объём текста или это лучше соответствует структуре данных. Важно: в MySQL 8.4 CHAR и VARCHAR ведут себя так же, как и в предыдущих версиях, никаких сюрпризов.
Вопрос: когда использовать DATETIME, а когда TIMESTAMP?
Короткий ответ: TIMESTAMP хранит количество секунд с 1970-01-01 и автоматически конвертируется в часовой пояс клиента. DATETIME хранит дату и время как есть, без привязки к часовому поясу. TIMESTAMP ограничен диапазоном 1970–2038, DATETIME — с 1000 до 9999 года.
Разбор: Это вопрос про осознанный выбор типа данных. TIMESTAMP удобен, когда важна привязка к часовому поясу пользователя — например, время создания заказа. DATETIME — когда часовой пояс не имеет значения или дата выходит за пределы 2038 года. В 2026 году проблема 2038 года уже не гипотетическая — до неё меньше 12 лет. Если вы проектируете систему с расчётом на долгую жизнь, DATETIME выглядит безопаснее.
Полезный блок со скидкой
Если хотите систематизировать знания о базах данных и чаще отвечать на технические вопросы без фразы «сейчас быстро погуглю», присмотритесь к курсам Практикума. На курсе «SQL для разработки» изучают запросы, индексы и транзакции, «Python-разработчик» подойдёт для погружения в бэкенд, а «Инженер данных» — для работы с хранилищами и потоками данных.
При оплате используйте промокод: KOD (можно просто нажать) он даст скидку на обучение.
Бесплатная часть тоже есть — карту привязывать не нужно.
JOIN: вопрос номер один на любом уровне
JOIN спрашивают всегда. На любом собеседовании по SQL. Это та тема, где ошибка стоит дорого.
Вопрос: в чём разница между INNER JOIN и LEFT JOIN?
Короткий ответ: INNER JOIN возвращает только те строки, где есть совпадение в обеих таблицах. LEFT JOIN возвращает все строки из левой таблицы и совпадающие из правой. Если совпадения нет — поля из правой таблицы будут NULL.
Разбор: Классика. Интервьюер проверяет, понимаете ли вы разницу между «только совпадающие» и «все из одной таблицы + совпадающие из другой». Часто просят объяснить на примере: есть таблицы employees и orders. INNER JOIN покажет только сотрудников, у которых есть заказы. LEFT JOIN покажет всех сотрудников, даже тех, у кого заказов нет — для них поля заказов будут NULL.
Вопрос: что вернёт LEFT JOIN, если совпадений нет?
Короткий ответ: Все строки из левой таблицы, а поля из правой таблицы будут заполнены NULL.
Разбор: Вопрос-ловушка. Неопытные прогеры думают, что LEFT JOIN без совпадений работает как INNER JOIN — и возвращает пустой результат. Это не так. Интервьюер хочет убедиться, что вы понимаете: LEFT JOIN всегда сохраняет левую таблицу, независимо от наличия совпадений.
Вопрос: как найти записи из одной таблицы без пары в другой?
Короткий ответ: LEFT JOIN + проверка на NULL в правой таблице.
Пример:
SELECT employees.*
FROM employees
LEFT JOIN orders ON employees.id = orders.employee_id
WHERE orders.id IS NULL;Разбор: Это типовая задача на лайвкодинге. Интервьюер смотрит, умеете ли вы применить LEFT JOIN для поиска отсутствующих записей. Для такой задачи используют LEFT JOIN с проверкой на NULL или NOT EXISTS. Какой вариант окажется быстрее, зависит от данных, индексов и плана выполнения; с NOT IN нужно отдельно учитывать NULL. Если на собеседовании дают такую задачу — проговаривайте, почему выбрали LEFT JOIN, а не NOT EXISTS.
Вопрос: что такое CROSS JOIN и почему случайный CROSS JOIN кладёт базу?
Короткий ответ: CROSS JOIN — декартово произведение: каждая строка из первой таблицы соединяется с каждой строкой из второй. Если в таблицах по миллиону записей — результат будет триллион строк. Это катастрофа.
Разбор: Интервьюер проверяет, понимаете ли вы вычислительную сложность JOIN-ов. CROSS JOIN без условий — это O(n*m). Случайный CROSS JOIN может резко увеличить число обрабатываемых строк и нагрузку на базу. Использовать его можно только после оценки размеров таблиц и ожидаемого результата: один LIMIT не всегда предотвращает дорогой план выполнения.
Агрегация: GROUP BY и HAVING
Здесь проверяют, умеете ли вы считать статистику и группировать данные.
Вопрос: почему нельзя выбрать негруппированный столбец при GROUP BY?
Короткий ответ: Потому что MySQL не знает, какое значение из группы выбрать. Это нарушает логику группировки. В режиме ONLY_FULL_GROUP_BY такие запросы вообще не выполняются.
Разбор: Интервьюер хочет услышать про режим ONLY_FULL_GROUP_BY — он включён по умолчанию в MySQL 5.7 и новее. Если вы скажете: «Можно, но MySQL выберет случайное значение из группы» — это устаревший ответ. В современных версиях такой запрос просто выдаст ошибку. Правильный ответ: «В режиме ONLY_FULL_GROUP_BY можно выбирать столбцы из GROUP BY, агрегатные выражения и столбцы, функционально зависимые от сгруппированных полей».
Вопрос: в чём разница между WHERE и HAVING?
Короткий ответ: WHERE фильтрует строки до группировки. HAVING фильтрует группы после группировки.
Разбор: Снова классика. Интервьюер проверяет порядок выполнения операций в запросе. WHERE применяется к исходным данным, HAVING — к результатам агрегации. Например, «найти отделы со средней зарплатой выше 50 000» — это HAVING, потому что сначала нужно посчитать среднюю зарплату по каждому отделу, а потом отфильтровать отделы. А «найти сотрудников с зарплатой выше 50 000» — это WHERE, фильтрация до группировки.
Задача: выведите отделы со средней зарплатой выше 50 000.
Решение:
SELECT department, AVG(salary) as avg_salary
FROM employees
GROUP BY department
HAVING AVG(salary) > 50000;Разбор: Простая задача, но интервьюер смотрит на детали: использовали ли вы HAVING, а не WHERE; правильно ли написали агрегатную функцию. Если в ответе WHERE AVG(salary) > 50000 — это ошибка, потому что WHERE не видит агрегированных значений.
Индексы: главная тема для middle
Индексы — это водораздел между junior и middle. Junior знает, что индексы ускоряют чтение. Middle объясняет, как именно они работают, почему замедляют запись и как понять, что индекс используется.
Вопрос: как работает индекс и почему ускоряет чтение, но замедляет запись?
Короткий ответ: Индекс — это структура данных (в InnoDB — B+дерево), которая позволяет быстро находить строки по значению столбца без полного сканирования таблицы. При вставке или обновлении данных индекс нужно обновлять — это дополнительные операции записи, поэтому индексы замедляют модификацию данных.
Разбор: Интервьюер проверяет, понимаете ли вы компромисс. Индексы могут ускорять SELECT, но зависит от запроса, объёма данных и селективности индекса. Каждый INSERT, UPDATE, DELETE требует обновления всех индексов на таблице. Поэтому индексы нужно создавать осознанно, а не «на все столбцы подряд». Правильный ответ включает упоминание B+дерева и того, что индекс хранит отсортированные значения с указателями на строки.
Вопрос: что такое составной индекс и правило левого префикса?
Короткий ответ: Составной индекс — это индекс на нескольких столбцах, например ( last_name, first_name, birth_date ). Правило левого префикса: запрос может использовать индекс, если условие содержит левую часть индекса — первый столбец, первый и второй, или все три. Условие только на first_name без last_name индекс не использует.
Разбор: Это один из самых частых вопросов для middle. Интервьюер хочет убедиться, что вы умеете проектировать индексы, а не просто создаёте их наугад. Например, индекс ( a, b, c ) будет работать для условий WHERE a = 1, WHERE a = 1 AND b = 2, WHERE a = 1 AND b = 2 AND c = 3. Но не сработает для WHERE b = 2 или WHERE c = 3. Правильный ответ — с примерами.
Вопрос: почему запрос с функцией над колонкой не использует индекс?
Короткий ответ: Потому что MySQL сравнивает не значения индекса, а результат функции. Индекс хранит сырые значения, а не их преобразования.
Разбор: Классический пример: WHERE DATE(created_at) = ‘2026-01-01’. Индекс на created_at не поможет, потому что MySQL должен применить функцию к каждому значению индекса. Правильное решение — хранить дату без времени или использовать диапазон: WHERE created_at >= ‘2026-01-01’ AND created_at < ‘2026-01-02’. Интервьюер проверяет, понимаете ли вы, как MySQL работает с индексами на уровне оптимизатора.
Вопрос: что такое покрывающий индекс?
Короткий ответ: Покрывающий индекс — это индекс, который содержит все столбцы, нужные для запроса. MySQL может выполнить запрос, читая только индекс, без обращения к таблице.
Разбор: Это продвинутая тема. В EXPLAIN такой запрос показывает Using index в колонке Extra. Покрывающие индексы сильно ускоряют запросы, потому что данные читаются из индекса (который обычно меньше таблицы и лучше кешируется). Интервьюер может спросить, как создать покрывающий индекс для конкретного запроса — правильный ответ: включить в индекс все столбцы из SELECT и WHERE.
Вопрос: как проверить использование индекса через EXPLAIN?
Короткий ответ: Запросом EXPLAIN SELECT … — в выводе смотрим колонки: possible_keys (какие индексы мог бы использовать), key (какой индекс использовал на самом деле), type (тип доступа, ALL означает полное сканирование таблицы, а ref и range — более выборочный доступ). Но оценивать план нужно вместе с размером таблицы, селективностью условия, rows и фактическим временем: для маленькой таблицы полное сканирование может быть нормальным
Разбор: Интервьюер хочет увидеть, что вы не просто знаете про индексы, а умеете диагностировать проблемы. На вопрос «запрос медленный, с чего начать» правильный ответ — EXPLAIN и slow query log. Дальше смотрим type=ALL — полное сканирование таблицы, нужно добавить индекс. rows сильно больше ожидаемого — индекс неэффективен. Extra с Using filesort — нужен индекс для сортировки.
Транзакции и ACID
Это тема, где junior и middle расходятся окончательно. Junior расшифровывает аббревиатуру ACID. Middle объясняет их на примерах.
Вопрос: расшифруйте ACID своими словами.
Короткий ответ: Atomicity — всё или ничего: транзакция либо выполняется полностью, либо откатывается. Consistency — данные после транзакции остаются в согласованном состоянии. Isolation — параллельные транзакции не влияют друг на друга. Durability — после подтверждения транзакции данные сохранены надёжно.
Разбор: Интервьюер проверяет, понимаете ли вы суть или просто вызубрили аббревиатуру. Хороший ответ — с примерами: «Атомарность — это как перевод денег: если списали с одного счёта, но не зачислили на другой — всё откатывается». Если вы просто перечислили буквы без пояснений — это слабый ответ даже для junior.
Вопрос: что такое уровень изоляции и какой у InnoDB по умолчанию?
Короткий ответ: Уровень изоляции определяет, видят ли транзакции изменения друг друга. InnoDB по умолчанию использует REPEATABLE READ.
Разбор: Это вопрос-маркер. Если вы не знаете дефолтный уровень изоляции InnoDB — вы не middle. В InnoDB уровень REPEATABLE READ использует MVCC. Для обычных согласованных чтений снимок, как правило, создаётся при первом таком чтении внутри транзакции и используется последующими согласованными чтениями. Явно зафиксировать снимок при старте можно через START TRANSACTION WITH CONSISTENT SNAPSHOT. В PostgreSQL, кстати, дефолтный уровень другой — READ COMMITTED. Поэтому важно не путать базы данных.
Вопрос: объясните грязное чтение и неповторяющееся чтение на бытовом примере.
Короткий ответ: Грязное чтение — одна транзакция читает данные, которые другая транзакция изменила, но ещё не подтвердила. Неповторяющееся чтение — в одной транзакции два раза читаем одну строку и получаем разные значения, потому что между чтениями другая транзакция её изменила и подтвердила.
Разбор: Интервьюер проверяет, понимаете ли вы проблемы параллелизма не абстрактно, а на практике. Хороший пример: два кассира работают с одним счётом. Кассир А читает баланс — 1000 рублей. Кассир Б списывает 200 и подтверждает. Кассир А снова читает баланс — уже 800. Это неповторяющееся чтение. REPEATABLE READ предотвращает эту проблему, показывая кассиру А тот же снимок данных, что и в начале транзакции.
Вопрос: чем InnoDB отличается от MyISAM и почему MyISAM в новых проектах не используют?
Короткий ответ: InnoDB поддерживает транзакции и блокировки на уровне строк. MyISAM — нет, только блокировки на уровне таблицы. InnoDB использует кластерный индекс. MyISAM — нет. InnoDB надёжнее при сбоях.
Разбор: В 2026 году MyISAM — это исторический артефакт. На собеседовании вопрос задают, чтобы проверить, знаете ли вы, почему InnoDB стал стандартом. MyISAM был популярен в 2000-х из-за скорости на чтение, но отсутствие транзакций и блокировки таблиц делают его непригодным для современных приложений. В MySQL 8.4 MyISAM всё ещё поддерживается, но использовать его в новых проектах не рекомендуют.
Оптимизация запросов
Здесь от middle ждут системного подхода. Не «добавить индекс», а «посмотреть EXPLAIN, найти узкое место, предложить решение, обосновать».
Вопрос: с чего начать разбор медленного запроса?
Короткий ответ: Включить slow query log, найти медленные запросы, выполнить EXPLAIN для каждого, посмотреть тип доступа, используемые индексы и количество просмотренных строк.
Разбор: Интервьюер проверяет, есть ли у вас методика. Правильный ответ — предложить конкретные инструменты: slow_query_log, long_query_time, mysqldumpslow для анализа логов, EXPLAIN для каждого подозрительного запроса. Дальше — смотреть на type=ALL (полное сканирование), rows (слишком много), Extra (Using filesort, Using temporary).
Вопрос: почему SELECT * — плохая практика?
Короткий ответ: SELECT * читает все столбцы, даже те, которые не нужны. Это увеличивает объём передаваемых данных, нагрузку на сеть и память. Кроме того, если в таблице есть индексы, SELECT * не может использовать покрывающий индекс — нужно обращаться к таблице за всеми данными.
Разбор: Интервьюер проверяет, понимаете ли вы, что запросы пишутся не «чтобы работало», а «чтобы работало эффективно». В больших таблицах разница между SELECT * и SELECT нужных столбцов может быть в десятки раз. Особенно если нужные столбцы есть в покрывающем индексе.
Вопрос: что такое N+1 и как её увидеть со стороны базы?
Короткий ответ: N+1 — это когда вы сначала выполняете один запрос, чтобы получить N записей, а потом для каждой записи выполняете ещё один запрос. Итого N+1 запросов вместо одного с JOIN.
Разбор: Типичная проблема ORM. Например, выбрали всех пользователей (1 запрос), потом для каждого пользователя запросили его заказы (N запросов). Вместо этого нужно было сделать один запрос с JOIN или использовать жадную загрузку. Интервьюер хочет услышать, что вы знаете про эту проблему и умеете её диагностировать — например, по логам базы, где видно много мелких запросов вместо одного большого.
Вопрос: когда JOIN лучше подзапроса?
Короткий ответ: Нельзя заранее утверждать, что JOIN быстрее подзапроса. Оптимизатор MySQL умеет преобразовывать многие подзапросы и выбирать сопоставимые планы, поэтому варианты нужно сравнивать через EXPLAIN на конкретных данных.
Разбор: В MySQL 8.4 оптимизатор стал умнее и может преобразовывать некоторые подзапросы в JOIN. Выбирать JOIN или подзапрос стоит по смыслу запроса, читаемости и фактическому плану выполнения. Интервьюер может попросить переписать подзапрос в JOIN — это стандартное задание.
Задача: дан медленный запрос, найдите проблему по выводу EXPLAIN.
Представим, что на собеседовании показывают вывод EXPLAIN:
id | select_type | table | type | possible_keys | key | rows | Extra
1 | SIMPLE | orders| ALL | NULL | NULL| 100000 | Using whereРешение: type=ALL означает полное сканирование таблицы, rows=100000 — примерную оценку количества строк для проверки, а possible_keys=NULL — отсутствие подходящих индексов для этого запроса. Дальше нужно изучить условие WHERE и решить, поможет ли индекс на используемый в нём столбец.
Интервьюер проверяет, умеете ли вы читать EXPLAIN и делать обоснованные выводы. Сам по себе type=ALL ещё не означает, что индекс обязательно нужно добавить: решение зависит от запроса, размера таблицы и селективности данных.
Вопросы про версии и экосистему
Эти вопросы задают не всегда, но если задают — ошибаться нельзя. Показать, что не знаете актуальную версию MySQL, — значит, существенно понизить свои шансы.
Вопрос: какая версия MySQL сейчас актуальна?
Короткий ответ: Для продакшена — MySQL 8.4 LTS с поддержкой до 2032 года. Свежий LTS-релиз — MySQL 9.7.0, вышел в апреле 2026. MySQL 8.0 достигла EOL в апреле 2026, использовать её в новых проектах не рекомендуется.
Разбор: Интервьюер проверяет, следите ли вы за экосистемой. MySQL 8.0 была хорошей версией, но её время прошло. Oracle перешла на модель с LTS и Innovation-релизами: LTS — для продакшена, Innovation — для тех, кто хочет новые функции. 8.4 — первый LTS в этой модели. 9.7 — новый LTS. Если вы скажете «8.0» — это красный флаг.
Вопрос: чем MySQL отличается от PostgreSQL? Когда что выбрать?
Короткий ответ: MySQL — классический OLTP-движок, силён в простых CRUD-операциях и высоких нагрузках на чтение. PostgreSQL — более функциональный, лучше для сложных запросов, аналитики и mixed-нагрузок. В 2026 году разница в производительности на простых операциях небольшая.
Разбор: Важно не начинать холивар. Обе базы хороши. MySQL 8.4 с InnoDB выдаёт высокую производительность на типичных веб-приложениях. PostgreSQL лучше справляется со сложными запросами и расширяемостью. Выбор зависит от задачи: если нужно простое, надёжное и быстрое решение для веб-приложения — MySQL. Если нужна сложная аналитика, кастомные типы данных или расширения — PostgreSQL.
Вопрос: что такое MariaDB и почему она совместима с MySQL?
Короткий ответ: MariaDB — это форк MySQL, созданный после того, как Oracle купила Sun Microsystems (а вместе с ней и MySQL). Основатель MySQL создал MariaDB как альтернативу. Она исторически совместима с MySQL на уровне многих запросов и клиентских протоколов, но со временем проекты заметно разошлись. Перед миграцией нужно проверять используемые функции, драйверы, типы данных и настройки
Разбор: Интервьюер проверяет знание истории и экосистемы. MariaDB используется как самостоятельная СУБД и в некоторых проектах может заменить MySQL, но считать её полностью взаимозаменяемой с современными версиями MySQL нельзя.
Чек-лист подготовки за неделю
Если до собеседования осталась неделя — держите план подготовки:
- День 1. JOIN и базовые запросы. Повторите все типы JOIN на примерах. Напишите на бумаге запросы для поиска записей без пары. Проговаривайте вслух, что вернёт каждый JOIN.
- День 2. Индексы и EXPLAIN. Разверните тестовую базу MySQL 8.4, создайте таблицу с 100 000 записей, поэкспериментируйте с индексами. Смотрите, как меняется EXPLAIN до и после добавления индекса. Проверьте правило левого префикса на составных индексах.
- День 3. Транзакции и уровни изоляции. Запустите две сессии MySQL, поэкспериментируйте с разными уровнями изоляции. Посмотрите, как проявляются грязные чтения и неповторяющиеся чтения. Запомните: REPEATABLE READ — дефолтный для InnoDB.
- День 4–5. Решение задач на тренажёрах. Используйте LeetCode, SQLZoo или любой другой тренажёр. Решайте задачи с JOIN, GROUP BY, подзапросами. Не смотрите ответы — пишите сами.
- День 6. Проговаривание вслух. Возьмите список вопросов из этой статьи и отвечайте на них вслух, без подглядывания. Записывайте себя на диктофон — так вы услышите, где запинаетесь или говорите неуверенно.
- День 7. Отдых и лёгкое повторение. Не зубрите. Пройдитесь по заголовкам, вспомните основные моменты. Хороший сон важнее, чем ещё один час зубрёжки.
И главный совет: если не знаете точного ответа — не выдумывайте. Скажите: «Я не уверен, но рассуждал бы так…» и опишите ход мыслей. Интервьюеры ценят честность и умение рассуждать гораздо выше, чем заученные правильные ответы. Молчание или выдумка — худший вариант.
Удачи на собеседовании. MySQL — это база, в хорошем смысле слова.
Советуем дополнительно почитать
Реляционная база данных: что это такое, принципы работы и основные понятия — таблицы, связи, ключи, нормализация и устройство реляционной модели.
5 видов баз данных, которые подходят для разных задач — реляционные, документные, графовые, колоночные и другие хранилища с примерами применения.
SQL-инъекции: механика атак, типы и методы защиты с примерами — как пользовательский ввод превращается в опасный запрос и почему нужны параметры, ограничения прав и безопасная работа через ORM.
Оконные функции SQL: что это такое и как работают— вычисления по группам строк без сворачивания результата, функции OVER, PARTITION BY и практические запросы.
Shopify перевела миллионы заказов с Redis на MySQL — производственный кейс оптимизации соединений, SQL-запросов и нагрузки на основную базу.
Бонус для читателей
Если вам интересно погрузиться в мир ИТ и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, безлимит на маркетплейсах и поможет с льготной ипотекой. Ладно, окей, это просто скидка, без остального, но хорошая.
