你如何在数据库级别扩展 Django？

Question

你如何在数据库级别扩展 Django？

Accepted Answer

随着 Django 应用程序的增长，**数据库**通常是首先也是最显著的瓶颈。扩展它涉及查询优化、索引、连接管理、读副本、缓存以及最终的架构更改——处理数据库是大多数 Django 应用程序的最高杠杆扩展工作。

## 1. 首先优化查询（最大的、最便宜的收益）

```python
# ✅ eliminate N+1 queries (the #1 issue) with select_related/prefetch_related
Book.objects.select_related("author").prefetch_related("tags")

# ✅ fetch only needed columns
Article.objects.only("title", "created_at")        # SELECT just these
Article.objects.values("title")                     # dicts, even lighter

# ✅ use database aggregation instead of Python loops
from django.db.models import Count, Sum
Author.objects.annotate(book_count=Count("books"))  # let the DB do the work
```

查询优化（修复 N+1 问题、仅选择需要的数据、将聚合推送到数据库）通常以最少的努力提供最大的性能收益——在添加基础设施之前执行此操作。

## 2. 添加索引

```python
class Article(models.Model):
    slug = models.SlugField(db_index=True)              # index a frequently-queried field
    class Meta:
        indexes = [
            models.Index(fields=["author", "-created_at"]),  # composite index for common queries
        ]
```

索引可以大幅加快按这些列进行过滤/排序的查询——对任何经常查询的字段都是必不可少的（缺少索引是导致查询缓慢的常见原因）。

## 3. 连接池

```text
Reuse database connections instead of opening one per request (expensive at scale).
Use a pooler (PgBouncer for PostgreSQL) or Django's CONN_MAX_AGE for persistent connections.
```

## 4. 读副本（数据库路由）

```python
# route READ queries to replicas, WRITES to the primary
class PrimaryReplicaRouter:
    def db_for_read(self, model, **hints): return "replica"   # reads → replica
    def db_for_write(self, model, **hints): return "primary"  # writes → primary
# DATABASES = { "primary": {...}, "replica": {...} }
```

读副本将读负载分布在多个数据库副本中（大多数应用程序都是读密集的），写入转到主数据库——Django 的数据库路由器适当地指导查询。

## 5. 缓存以减少数据库负载

```python
# cache expensive query results (Redis) so they don't hit the DB every time
result = cache.get_or_set("expensive", lambda: expensive_query(), 3600)
```

## 6. 进一步扩展（当上述方法不够时）

```text
✓ Caching layers (Redis) — biggest load reduction for read-heavy workloads
✓ Database tuning (query plans, vacuuming, configuration)
✓ Denormalization / materialized views for expensive aggregations
✓ Partitioning large tables; archiving old data
✓ Sharding (splitting data across databases) — last resort, complex
✓ Move heavy/async work to background tasks (Celery) off the request path
```

## 首先测量

```text
Use Django Debug Toolbar, django-silk, slow-query logs, and EXPLAIN to find the
ACTUAL bottleneck. Optimize what's slow, not what you guess is slow.
```

## 为什么这很重要

在数据库级别扩展 Django 是关键的高级知识，因为随着应用程序的增长，数据库几乎总是主要瓶颈——了解如何解决它是使 Django 应用程序能够处理不断增长的负载和数据量的原因。

关键洞察是数据库扩展遵循明确的优先级顺序，最高杠杆、最便宜的干预措施优先：**查询优化**（特别是使用 `select_related`/`prefetch_related` 消除 N+1 问题、仅获取所需列、以及将聚合推送到数据库）通常以最少的努力提供最大的收益，应该始终在添加基础设施之前进行，**正确的索引**是必不可少的，因为缺少索引是导致查询缓慢的常见原因。

超越这些基础知识，理解扩展技术的进展——**连接池**（在规模扩大时重用昂贵的数据库连接）、**带有数据库路由的读副本**（将读负载分布在数据库副本中，有价值因为大多数应用程序是读密集的）、**缓存**（使用 Redis 完全减少读密集数据的数据库命中）、最终更复杂的措施（反范式化、分区、分片作为最后手段）——给你一个工具包来在增长的每个阶段解决性能问题。

同样重要的是**首先测量的纪律**（使用 Django Debug Toolbar、慢查询日志和 EXPLAIN 查找实际瓶颈而不是猜测），因为优化错误的东西会浪费努力。

了解这个数据库扩展进程——首先进行查询优化和索引，然后是池/副本/缓存，然后是架构变更，所有都由测量驱动——这是区分能够在 Django 应用程序增长时保持其快速和可扩展的开发人员与那些应用程序在实际负载下退化的开发人员的区别。

因为数据库是最常见的扩展约束，且技术范围从简单的查询修复到复杂的基础设施，系统地理解如何在数据库级别扩展 Django 是构建和运行必须处理增长的生产应用程序的重要、高价值的知识，使其成为负责应用程序性能和可扩展性的高级工程师的常见相关主题。