> Расскажите про опыт работы с базами данных и используемые СУБД (Go)

Короткий ответ

Основной опыт - PostgreSQL и MySQL для OLTP-нагрузок, плюс Redis для кэширования и очередей. Работал с миграциями (golang-migrate), писал сложные запросы с JOIN и оконными функциями, настраивал индексы под нагрузку. В Go использовал database/sql, pgx и GORM. Понимаю транзакции, уровни изоляции и важность explain analyze для оптимизации.

Подробное объяснение

За последние несколько лет работал преимущественно с реляционными СУБД, так как большинство проектов требовали строгой консистентности и сложных связей между сущностями. PostgreSQL - основной выбор для production, MySQL - для легаси-проектов. Redis использовал для кэширования горячих данных и реализации rate limiting.

Ключевые аспекты работы:

• проектирование схемы: нормализация, но без фанатизма - иногда денормализация оправдана для read-heavy сценариев
• миграции: всегда через версионированные SQL-файлы, применяемые автоматически при деплое
• индексы: B-tree для equality и range, GIN для полнотекстового поиска, частичные индексы для фильтрации по статусу
• транзакции: понимаю разницу между READ COMMITTED и REPEATABLE READ, умею обрабатывать deadlock'и и конфликты сериализации
• оптимизация: explain analyze, поиск seq scan, работа с планом запроса

На практике

В недавнем проекте на Go была задача - выгрузка отчётов за период. Изначально запрос с несколькими JOIN выполнялся 8 секунд. После анализа плана выяснилось, что PostgreSQL не использует индекс по дате из-за обёртки в функции. Решение - переписал условие на диапазонный предикат, добавил составной индекс (user_id, created_at), время упало до 120 мс.

Также работал с партиционированием больших таблиц по дате - это позволило эффективно удалять старые данные через DETACH PARTITION вместо DELETE. Для Go-приложений использовал пул соединений pgxpool с настройками под нагрузку: max_conns, min_conns, max_conn_lifetime.

Пример кода

GO
// Пример работы с транзакцией через pgx
func TransferMoney(ctx context.Context, pool *pgxpool.Pool, fromID, toID int64, amount decimal.Decimal) error {
    tx, err := pool.BeginTx(ctx, pgx.TxOptions{
        IsoLevel: pgx.ReadCommitted,
    })
    if err != nil {
        return err
    }
    defer tx.Rollback(ctx)

    // Блокируем строки для избежания гонок
    _, err = tx.Exec(ctx, 
        `SELECT balance FROM accounts WHERE id = $1 FOR UPDATE`, fromID)
    if err != nil {
        return err
    }

    _, err = tx.Exec(ctx,
        `UPDATE accounts SET balance = balance - $1 WHERE id = $2`, amount, fromID)
    if err != nil {
        return err
    }

    _, err = tx.Exec(ctx,
        `UPDATE accounts SET balance = balance + $1 WHERE id = $2`, amount, toID)
    if err != nil {
        return err
    }

    return tx.Commit(ctx)
}

Как отвечать на собеседовании

Структурируйте ответ по трём блокам: какие СУБД использовали и зачем, какие задачи решали (проектирование, оптимизация, миграции), какие инструменты применяли в связке с Go. Обязательно приведите конкретный пример оптимизации или решения проблемы - это показывает глубину опыта. Упомяните, как тестируете запросы: explain analyze, тестовые данные, нагрузочное тестирование. Если спрашивают про NoSQL - честно скажите, что использовали Redis только как кэш, а основная нагрузка на реляционные БД.

Что проверяет интервьюер

Интервьюер оценивает:

• реальный опыт, а не заученные определения - поэтому важны конкретные кейсы
• понимание trade-off между нормализацией и производительностью
• умение работать с транзакциями и конкурентным доступом
• знание инструментов миграций и работы с пулом соединений в Go
• способность диагностировать проблемы производительности через explain analyze

Типичные ошибки

• перечисление СУБД без объяснения, зачем каждая использовалась
• ответ "использовал ORM, запросы не писал" - сразу снижает оценку
• отсутствие примеров оптимизации или проблем, с которыми сталкивались
• путаница между уровнями изоляции или непонимание, что такое lost update
• игнорирование вопросов про индексы - если не упомянули самостоятельно, интервьюер начнёт копать глубже
• утверждение, что "база не тормозит" без данных explain analyze - это красный флаг