Что делать, если долго отвечает база?

Работа с медленными запросами к базе данных (для Go-разработчика)

Когда база данных начинает отвечать долго, это критическая проблема, затрагивающая всю цепочку обработки запроса. Вот стратегии диагностики и оптимизации, которые я применяю на практике.

1. Немедленная диагностика и мониторинг

Первым делом необходимо понять что именно и почему тормозит. В Go-экосистеме есть отличные инструменты для этого:

// Пример логирования медленных запросов в Go
package main

import (
    "context"
    "database/sql"
    "log"
    "time"
    
    _ "github.com/lib/pq"
)

// Обёртка для логирования времени выполнения запросов
func QueryWithTimeout(ctx context.Context, db *sql.DB, query string, args ...interface{}) (*sql.Rows, error) {
    start := time.Now()
    
    // Устанавливаем timeout на уровне приложения
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()
    
    rows, err := db.QueryContext(ctx, query, args...)
    elapsed := time.Since(start)
    
    if elapsed > 100*time.Millisecond { // Порог для "медленных" запросов
        log.Printf("SLOW QUERY: %s took %v", query, elapsed)
    }
    
    return rows, err
}

Метрики, которые нужно отслеживать:

• Время выполнения запросов (p50, p95, p99 перцентили)
• Количество активных соединений к БД
• Процент использования CPU и памяти на сервере БД
• Количество блокировок (locks) и дедлоков (deadlocks)

2. Анализ и оптимизация конкретных запросов

Медленные запросы чаще всего вызваны проблемами в самом SQL:

-- Плохой запрос (отсутствие индекса, полное сканирование таблицы)
SELECT * FROM users WHERE email LIKE '%@example.com';

-- Оптимизированный запрос
-- 1. Создаём индекс для поиска по email
CREATE INDEX idx_users_email ON users(email);

-- 2. Переписываем запрос для использования индекса
SELECT id, name, email FROM users 
WHERE email LIKE '%@example.com' 
AND created_at > NOW() - INTERVAL '30 days';

Техники оптимизации SQL:

• EXPLAIN ANALYZE для анализа плана выполнения
• Добавление недостающих индексов (но не переусердствовать!)
• Устранение N+1 проблемы через JOIN или подзапросы
• Нормализация и денормализация данных где это уместно

3. Архитектурные решения на уровне приложения

Кеширование

// Использование кеша для частых запросов
package cache

import (
    "time"
    "github.com/go-redis/redis/v8"
)

type UserCache struct {
    redisClient *redis.Client
    ttl         time.Duration
}

func (c *UserCache) GetUser(userID string) (*User, error) {
    // Сначала пробуем получить из кеша
    user, err := c.getFromCache(userID)
    if err == nil && user != nil {
        return user, nil
    }
    
    // Если нет в кеше — идём в БД
    user, err = c.fetchFromDB(userID)
    if err != nil {
        return nil, err
    }
    
    // Сохраняем в кеш на будущее
    c.saveToCache(userID, user)
    return user, nil
}

Распределение нагрузки

• Read Replicas для операций чтения
• Шардирование (горизонтальное разделение данных)
• Асинхронная обработка через очереди (RabbitMQ, Kafka)

4. Оптимизация работы с базой в Go-коде

// Правильное использование пула соединений
func initDB() *sql.DB {
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        log.Fatal(err)
    }
    
    // Настройка пула соединений КРИТИЧНО важна
    db.SetMaxOpenConns(25)      // Ограничиваем максимальное число соединений
    db.SetMaxIdleConns(5)       // Соединения в режиме ожидания
    db.SetConnMaxLifetime(5*time.Minute) // Максимальное время жизни соединения
    db.SetConnMaxIdleTime(2*time.Minute) // Время простоя соединения
    
    return db
}

// Использование prepared statements
func getUsersByStatus(db *sql.DB, status string) ([]User, error) {
    // Prepared statement создаётся один раз, выполняется много раз
    stmt, err := db.Prepare("SELECT id, name FROM users WHERE status = $1")
    if err != nil {
        return nil, err
    }
    defer stmt.Close()
    
    rows, err := stmt.Query(status)
    // ... обработка результатов
}

5. Экстренные меры при деградации

Если проблема уже в production:

1. Включить режим read-only для некритичных частей приложения
2. Масштабировать ресурсы БД (увеличить CPU/RAM, перейти на более мощный инстанс)
3. Ограничить частые запросы через rate limiting
4. Перенаправить трафик на резервную реплику если доступна
5. Отложить фоновые задачи (отчёты, аналитика, нотификации)

Проактивные практики для предотвращения проблем

• Регулярный ревизия медленных запросов в логах
• Лимитирование времени выполнения запросов на уровне приложения
• Нагрузочное тестирование перед релизами
• Мониторинг ключевых метрик в реальном времени (Prometheus + Grafana)
• Использование connection pooler типа PgBouncer для PostgreSQL

Важное замечание: нет серебряной пули. Каждая ситуация уникальна и требует анализа конкретного контекста. Часто достаточно одной плохо написанной SQL-функции или отсутствующего индекса, чтобы деградировала вся система. Системный подход к мониторингу, анализу и оптимизации — заказ устойчивой работы базы данных в Go-приложениях.