В каких ситуациях не стоит делать оптимизацию запроса в БД

# Когда НЕ нужно оптимизировать запросы БД

Оптимизация — это важно, но далеко не всегда она нужна. Есть много ситуаций, когда оптимизацией БД стоит пренебречь. Вот классические случаи:

1. Запрос не является bottleneck'ом (не узким местом)

Проблема: Преждевременная оптимизация

# Код без оптимизации
def get_user_stats(user_id):
    user = User.objects.get(id=user_id)  # 1 query
    comments = Comment.objects.filter(user=user)  # N queries
    return {"user": user, "comments": comments}

# Timing: 150ms

Если это API endpoint, который вызывается раз в минуту и работает за 150ms, оптимизация не нужна.

Когда это важно

# Тот же код в hot path (высоконагруженное место)
def get_user_stats(user_id):  # вызывается 10000x в секунду
    user = User.objects.get(id=user_id)
    comments = Comment.objects.filter(user=user)
    return {"user": user, "comments": comments}

# 10000 * 150ms = 1500 секунд CPU в секунду — потребуется 300 инстансов!
# Здесь оптимизация критична

Правило: Измеряй first, оптимизируй second.

import time

start = time.time()
result = get_user_stats(user_id)
end = time.time()

if (end - start) > 0.5:  # Если > 500ms
    print("Нужна оптимизация")
else:
    print("Живём с этим")

2. Запрос выполняется редко

Пример: Периодический отчёт

# Запускается раз в день (schedule task)
@shared_task
def daily_report():
    # Собираем данные за день
    orders = Order.objects.filter(
        created_at__date=today()
    ).select_related('customer')  # 1000 заказов
    
    # Получаем все комментарии к заказам
    comments = Comment.objects.filter(
        order_id__in=[o.id for o in orders]
    )  # N+1 problem!
    
    total = sum(c.rating for c in comments)
    return {"total": total}

Хотя здесь есть N+1, это задача запускается раз в день и работает 5-10 минут. Оптимизация не критична.

Но если это запрос в веб API — оптимизировать обязательно!

# API endpoint - вызывается часто
def api_get_daily_report(request):
    # Здесь нужна оптимизация
    orders = Order.objects.filter(
        created_at__date=today()
    ).select_related('customer').prefetch_related('comments')
    # ...

3. Оптимизация требует компромиссов

Case 1: Усложнение кода

# Неоптимизированно (просто и понятно)
def get_products_with_reviews():
    products = Product.objects.all()
    result = []
    for product in products:
        reviews = Review.objects.filter(product=product)
        avg_rating = reviews.aggregate(Avg('rating'))['rating__avg']
        result.append({
            "product": product,
            "rating": avg_rating
        })
    return result
# 1001 queries, но код понятный

# Оптимизированно (сложный запрос)
from django.db.models import Avg, F, Case, When, DecimalField
from django.db.models.functions import Coalesce

def get_products_with_reviews():
    return Product.objects.annotate(
        avg_rating=Coalesce(
            Case(
                When(review__isnull=False, 
                     then=Avg('review__rating')),
                output_field=DecimalField(),
            ),
            0.0
        )
    ).values('id', 'name', 'avg_rating').distinct()
# 1 query, но сложный код

Если код читает один junior разработчик, первый вариант лучше. Если это критичный запрос — второй.

Принцип KISS: Keep It Simple, Stupid. Часто простота ценнее производительности.

Case 2: Добавление индексов

# Нужен индекс для оптимизации
class Article(models.Model):
    title = models.CharField(max_length=200)
    author = models.CharField(max_length=100)
    published = models.BooleanField(default=False)

# Медленный запрос
Article.objects.filter(author='John', published=True).count()

# Нужен индекс
class Article(models.Model):
    title = models.CharField(max_length=200)
    author = models.CharField(max_length=100, db_index=True)  # <- Индекс
    published = models.BooleanField(default=False, db_index=True)  # <- Индекс

ПРОБЛЕМА: Индексы замедляют INSERT и UPDATE!

# Таблица со 100M строк, 50K новых INSERT/день, 1 SELECT в день
class User(models.Model):
    email = models.CharField(max_length=200, db_index=True)  # Спорно
    ip_address = models.CharField(max_length=20, db_index=True)  # Спорно
    created = models.DateTimeField(auto_now_add=True)
    # ...

Индексы на email/ip замедляют inserting в 20-30%. Но query SELECT работает быстрее. Компромисс!

❌ Не индексируй всё подряд ✅ Индексируй только часто используемые WHERE условия

4. Проблема не в БД

Пример: Проблема в кеше

# Оптимизация БД не поможет
def get_user(user_id):
    # Каждый раз запрос в БД
    user = User.objects.get(id=user_id)  # 50ms
    return user

# Эта функция вызывается 1000x в запросе
for i in range(1000):
    user = get_user(user_id)  # 50 * 1000 = 50 сек!

# Оптимизация БД не поможет, нужен кеш!

def get_user(user_id):
    # Проверяем кеш
    cached = cache.get(f"user_{user_id}")
    if cached:
        return cached  # 1ms
    
    # Первый раз
    user = User.objects.get(id=user_id)  # 50ms
    cache.set(f"user_{user_id}", user, 3600)
    return user

# 50ms + 999ms = 1 сек, не 50 сек!

Проблема не в БД, а в отсутствии кеширования.

Пример: Проблема в N+1

# N+1 problem
users = User.objects.all()  # 1 query
for user in users:  # 1000 users
    print(user.profile.bio)  # 1000 queries!

# Решение: select_related, НЕ оптимизация самого запроса
users = User.objects.select_related('profile')  # 1 query с JOIN
for user in users:
    print(user.profile.bio)  # Уже в памяти, 0 queries

Это не оптимизация — это базовое практика, которую забыли применить.

5. Есть более серьёзные проблемы

Приоритизация

1. Security bugs (критичные)
2. Business logic bugs (важные)
3. Performance (когда исправлено 1 и 2)
   3a. Hot paths (API endpoints, UI)
   3b. Background jobs
   3c. Редкие query'ры

Пример: Есть SQL injection в админ-панели.

# ❌ Неправильно: оптимизируем query
query = f"SELECT * FROM users WHERE id = {user_id}"  # SQL Injection!

# ✅ Правильно: сначала фиксим security
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, [user_id])

6. Оптимизация вводит баги

Case: Кеш-инвалидация

# Оптимизированно с кешем
def get_product(product_id):
    key = f"product_{product_id}"
    cached = cache.get(key)
    if cached:
        return cached
    
    product = Product.objects.get(id=product_id)
    cache.set(key, product, 3600)
    return product

# Но что если товар обновили?
def update_product(product_id, name):
    product = Product.objects.get(id=product_id)
    product.name = name
    product.save()
    # ЗАБЫЛИ инвалидировать кеш!
    # cache.delete(f"product_{product_id}")

Теперь get_product() возвращает старые данные. Это баг!

Если это критичный путь — оптимизируй. Если нет — работай с БД напрямую.

7. Скорость разработки важнее скорости выполнения

Startup phase

# MVP - скорость разработки критична
class Product(models.Model):
    name = models.CharField(max_length=200)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    created = models.DateTimeField(auto_now_add=True)

# Первая версия - нет индексов, нет кеша, N+1 everywhere
# Но функциональность работает!
# Пользователи видят MVP за 2 недели, а не за 4

Оптимизация может придёт позже, после валидации гипотезы.

Практические правила

✅ Оптимизируй, если:

1. Есть измеренная проблема (> 500ms для веб, > 10% CPU)
2. Это hot path (вызывается часто)
3. Оптимизация не усложняет код слишком сильно
4. Нет более серьёзных проблем
5. Инвестиция затрат времени окупается

❌ Не оптимизируй, если:

1. Нет доказанной проблемы
2. Редко выполняется (< раза в минуту)
3. Оптимизация требует компромиссов
4. Проблема не в БД
5. Срок важнее скорости

Заключение

"Premature optimization is the root of all evil" — Donald Knuth

История разработки показывает:

• Преждевременная оптимизация усложняет код
• Отложенная оптимизация ведёт к техническому долгу
• Своевременная оптимизация (based on metrics) — золотая середина

От разработчика требуется баланс: понимать, что можно оптимизировать, но делать это только когда это имеет смысл.