クエリセットの遅延評価とキャッシュ機構

Djangoのクエリセットは「遅延評価（lazy evaluation）」されるため、実際に結果を取得する操作（例：ループ処理、list()呼び出し）が行われるまで、SQLは発行されません。この特性により、不要なDBアクセスを防ぎつつ、複数回のフィルタリングや条件追加を効率的に行えます。

また、一度評価されたクエリセットは内部で結果をキャッシュします。つまり、同じクエリセットを再利用する場合、2回目以降はデータベースに再アクセスせず、Pythonプロセス内で保持された結果を返します。ただし、新しいクエリ操作を行うとキャッシュは無効になる点に注意が必要です。

インデックス設計による検索性能向上

頻繁にフィルタリングや並べ替えに使用されるフィールドには、データベースレベルでのインデックスを設定することで検索速度を大幅に改善できます。

from django.db import models

class Order(models.Model):
    created_at = models.DateTimeField(auto_now_add=True, db_index=True)
    total_price = models.DecimalField(max_digits=10, decimal_places=2)
    customer = models.ForeignKey('Customer', on_delete=models.CASCADE, db_index=True)

上記モデルにおいて、created_at や customer フィールドに対するクエリは、インデックスのおかげで高速化されます。しかし、大規模な本番環境では、インデックス作成時のロック時間が長くなる可能性があるため、オンラインマイグレーション戦略（例：CREATE INDEX CONCURRENTLY）の採用を検討すべきです。

外部キャッシュシステムの活用

繰り返し実行される重いクエリに対しては、RedisやMemcachedなどの外部キャッシュを導入することで、データベース負荷を劇的に低減できます。

Redisを使用する場合、まずパッケージをインストールします：

pip install redis

次に、settings.py に以下のようにキャッシュバックエンドを定義します：

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
        'TIMEOUT': 300,
        'OPTIONS': {
            'CLIENT_CLASS': 'redis.sentinel.SentinelSupport',
        }
    }
}

ビュー内でキャッシュを利用する例：

from django.core.cache import cache

def get_top_products():
    key = 'top_products_list'
    products = cache.get(key)
    if not products:
        products = Product.objects.filter(rating__gte=4.5)[:10]
        cache.set(key, products, 60 * 15)  # 15分間キャッシュ
    return products

大量データ処理におけるイテレータの使用

数万件以上のデータを一括処理する際、通常のクエリセットはすべてのオブジェクトをメモリ上に保持しようとするため、OOM（Out of Memory）のリスクがあります。このようなケースでは、iterator() を使用してストリーム処理を行います。

for log_entry in AccessLog.objects.iterator(chunk_size=2000):
    process_log(log_entry)

iterator() は内部でチャンク単位でフェッチを行い、メモリ使用量を抑制しつつ、データベースから逐次読み込みます。処理後にオブジェクトを再利用しない場合に特に有効です。

永続的なデータベース接続の設定

HTTPリクエストごとにデータベース接続・切断を行うと、コネクション確立のオーバーヘッドが大きくなります。これを回避するために、CONN_MAX_AGE を設定して接続を再利用できます。

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'myapp_db',
        'USER': 'dbuser',
        'PASSWORD': 'secret',
        'HOST': 'localhost',
        'PORT': '5432',
        'OPTIONS': {
            'CONN_MAX_AGE': 60,  # 接続を最大60秒間維持
            'MAX_CONNS': 20,
        },
    }
}

高トラフィック環境では、プーリングミドルウェア（例：PgBouncer）との組み合わせも検討すべきです。

F式によるデータベース内演算

モデルのフィールド同士の比較や計算をPython側ではなく、データベース側で処理するには、django.db.models.F を使用します。これにより、不要なフェッチを避け、アトミックな更新も可能になります。

from django.db.models import F

# 在庫数を減らしつつ販売回数を増加
Product.objects.filter(id=product_id).update(
    stock=F('stock') - 1,
    sales_count=F('sales_count') + 1
)

この方法では、データがPythonプロセスにロードされることなく、データベース内で直接演算が行われます。

関連データの効率的取得：select_related vs prefetch_related

リレーションシップを持つモデルを扱う際、N+1クエリ問題を回避するための2つの主要な手段があります。

select_related（JOINによる取得）

一対一または一対多の前方参照に使用され、内部でSQLのJOINを利用して関連データを同時に取得します。

# 単一のSQLでUserとProfileを結合
profile = UserProfile.objects.select_related('user').get(user__username='alice')

prefetch_related（別途クエリ＋Pythonでの結合）

多対多や逆方向の多対一リレーションに有効です。関連データを別クエリで取得し、Python側でマッピングします。

# 複数のBookとその著者リストを効率的に取得
books = Book.objects.prefetch_related('authors').all()

大きな違いは、select_related がJOINを生成するのに対し、prefetch_related はIN句を含む追加クエリを発行することです。大量データの場合、JOINが重くなる可能性があるため、用途に応じて使い分ける必要があります。

バルク操作による一括処理の高速化

多数のオブジェクトを一括で登録・更新する場合は、bulk_create() および bulk_update() を使用すると、パフォーマンスが飛躍的に向上します。

# 一括登録
new_entries = [LogEntry(message=f"Log {i}") for i in range(1000)]
LogEntry.objects.bulk_create(new_entries, batch_size=100)

# 一括更新
entries_to_update = list(LogEntry.objects.filter(active=True)[:500])
for entry in entries_to_update:
    entry.status = 'processed'
LogEntry.objects.bulk_update(entries_to_update, ['status'], batch_size=100)

これらの操作は個別のINSERT/UPDATE文よりも遥かに効率的ですが、モデルのsave()メソッドやシグナルは実行されない点に注意してください。