Насколько сложные запросы писал в базах данных

Отличный и очень практичный вопрос. Он позволяет оценить не только знание SQL, но и умение проектировать данные, оптимизировать и понимать, как работа с БД вписывается в архитектуру Go-приложения. Отвечу, структурируя опыт по аспектам сложности.

Уровни сложности запросов и практический опыт

Мой опыт охватывает весь спектр — от простых CRUD-операций до запросов, которые можно назвать сложными (complex) и даже высокооптимизированными (highly-optimized). Сложность определяется не только длиной SQL, но и:

1. Логической запутанностью (множественные условия, подзапросы, оконные функции).
2. Влиянием на производительность (работа с большими объемами данных, блокировки).
3. Архитектурной необходимостью (запрос как часть распределенной транзакции или сложной бизнес-логики).

1. Сложные аналитические запросы и агрегация данных

Часто необходимо готовить данные для отчетов или сложных дашбордов. Здесь на помощь приходят оконные функции (Window Functions), общие табличные выражения (CTE – Common Table Expressions) и продвинутая агрегация.

-- Пример: Расчет скользящего среднего и ранжирование заказов для каждого клиента за последний квартал
WITH customer_quarterly_stats AS (
    SELECT
        customer_id,
        order_date,
        amount,
        SUM(amount) OVER (
            PARTITION BY customer_id
            ORDER BY order_date
            ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
        ) as moving_avg_3_orders,
        ROW_NUMBER() OVER (
            PARTITION BY customer_id, DATE_TRUNC('month', order_date)
            ORDER BY amount DESC
        ) as rank_in_month
    FROM orders
    WHERE order_date >= NOW() - INTERVAL '3 months'
    AND status = 'completed'
)
SELECT
    customer_id,
    order_date,
    amount,
    moving_avg_3_orders,
    rank_in_month
FROM customer_quarterly_stats
WHERE rank_in_month <= 5 -- Топ-5 заказов по сумме в каждом месяце для клиента
ORDER BY customer_id, order_date;

Такой запрос уже требует глубокого понимания модели данных и возможностей SQL.

2. Оптимизация «тяжелых» JOIN и работа с индексами

Написать JOIN на 5-7 таблиц — это полдела. Главное — сделать его быстрым на растущей базе.

• Использование составных индексов (composite indexes) под паттерны запросов (WHERE category_id = ? AND created_at > ?).
• Преобразование подзапросов в JOIN, где это убирает необходимость повторного выполнения (correlated subqueries).
• Применение стратегий like EXPLAIN ANALYZE (в PostgreSQL) для анализа плана запроса и поиска «узких мест»: последовательных сканирований (Seq Scan) вместо сканирований по индексу (Index Scan), недостатка work_mem для операций сортировки и хеширования.
• Денормализация на уровне запроса — сознательное дублирование ключевых полей в связанные таблицы для исключения лишних JOIN.

3. Запросы в контексте транзакций и конкурентного доступа в Go

В высоконагруженных Go-сервисах критически важно писать запросы, корректно работающие в условиях конкурентности. Это отдельный пласт сложности.

// Пример: Безопасное списание баланса с использованием транзакции и SELECT FOR UPDATE
func (r *Repo) ReserveBalance(ctx context.Context, userID int64, amount decimal.Decimal) error {
    tx, err := r.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    // 1. Явная блокировка строки для изменения.
    var currentBalance decimal.Decimal
    row := tx.QueryRowContext(ctx,
        `SELECT balance FROM accounts WHERE user_id = $1 FOR UPDATE`,
        userID,
    )
    if err := row.Scan(&currentBalance); err != nil {
        return err
    }

    // 2. Проверка бизнес-логики на уже заблокированных данных.
    if currentBalance.LessThan(amount) {
        return errors.New("insufficient funds")
    }

    // 3. Выполнение изменений.
    _, err = tx.ExecContext(ctx,
        `UPDATE accounts SET balance = balance - $1 WHERE user_id = $2`,
        amount, userID,
    )
    if err != nil {
        return err
    }

    return tx.Commit()
}

Здесь сложность в понимании уровней изоляции транзакций (Isolation Levels) и правильном выборе механизма блокировок (FOR UPDATE, FOR SHARE, оптимистичные блокировки через версию).

4. Работа с полнотекстовым поиском и JSON/JSONB

В PostgreSQL часто приходилось писать запросы с использованием GIN-индексов по JSONB-полям для гибкого поиска по структурированным атрибутам или запросы с to_tsvector для релевантного полнотекстового поиска.

-- Поиск товаров по атрибутам в JSONB и названию с ранжированием
SELECT
    product_id,
    name,
    attributes->>'brand' as brand,
    ts_rank_cd(
        to_tsvector('english', name || ' ' || coalesce(description, '')),
        plainto_tsquery('wireless mouse')
    ) as relevance
FROM products
WHERE attributes @> '{"wireless": true, "color": "black"}'::jsonb
AND to_tsvector('english', name || ' ' || coalesce(description, '')) @@ plainto_tsquery('wireless mouse')
ORDER BY relevance DESC;

Интеграция с Go: паттерны и проблемы

Сложность запросов влечет за собой сложность их интеграции в код:

• Использование sqlx или squirrel для построения динамических запросов со множеством опциональных фильтров, избегая ручной конкатенации строк и SQL-инъекций.
• Маппинг сложных результатов в структуры Go, возможно, с использованием сканеров (sql.Scanner) для кастомных типов.
• Кэширование результатов тяжелых агрегирующих запросов в Redis, чтобы не нагружать БД.
• Решение проблемы N+1 запроса на уровне репозитория, предзагружая все необходимые связи одним или несколькими эффективными JOIN, а не десятками отдельных запросов.

Итог: Писать «сложные» запросы — это не самоцель, а инструмент решения бизнес-задач. Ключевой навык — это умение не только написать такой запрос, но и спроектировать его, проанализировать на производительность, корректно интегрировать в транзакционную модель Go-приложения и покрыть тестами. Часто действительно сложная логика может быть вынесена в материализованные представления или обрабатываться пачками (batch operations), чтобы упростить основной код приложения.