Django框架网站数据库交互优化实操教程

Django的ORM层是开发者最常用的部分，但也是性能问题的高发区。绝大多数数据库交互瓶颈并非PostgreSQL或MySQL本身的能力问题，而是ORM使用不当导致的。最常见的场景是：视图里循环查询数据库，一个列表页触发上百次SQL查询；用all()取出全表数据后在Python内存里切片分页；明明只需要两个字段却用select_related加载了关联表的全部列。这些问题在数据量小时毫无感知，一旦单表超过十万行、关联表超过百万行，页面响应时间会从几十毫秒直接飙升到几秒甚至超时。

解决这些问题的核心思路只有一条：减少查询次数、减少传输数据量、让数据库做它擅长的事。下面直接进入具体优化手段，每一个方法都附带可落地的代码示例。

善用select_related处理外键一对一和多对一关系

当你查询一个模型，后续又访问它的外键字段时，Django默认会为每次外键访问发起一次额外查询。比如文章列表页，每篇文章都要显示作者名，如果你在模板里写了article.author.name，就会产生N+1次查询。

错误做法：

articles = Article.objects.all()
for article in articles:
    print(article.author.name)  # 每次循环都查一次author表

正确做法是用select_related把外键表提前JOIN进来，一条SQL完成所有查询：

articles = Article.objects.select_related('author').all()
for article in articles:
    print(article.author.name)  # 不再产生额外查询

select_related的原理是生成SQL的INNER JOIN或LEFT JOIN，把关联表的数据一次性拉到结果集中。它只适用于外键和一对一字段，也就是关系定义在当前模型这一侧的情况。对于多层关联，可以用双下划线穿透：select_related('author__profile')，这样author和profile两张表都会被JOIN进来。但要注意JOIN的表不要超过三四张，否则数据库的JOIN开销会超过减少查询带来的收益。遇到深层关联时，可以拆成两次select_related查询，在Python层面手动拼接数据。

用prefetch_related解决多对多和反向查询

多对多字段和反向查询不能用SQL的JOIN直接解决，因为会产生笛卡尔积导致结果集膨胀。Django提供了prefetch_related，它会额外发起一条查询，然后在Python层面把数据拼接好。

典型场景：查询一批文章，同时获取每篇文章的标签列表。

articles = Article.objects.prefetch_related('tags').all()
for article in articles:
    print(list(article.tags.all()))  # 不会触发额外查询

prefetch_related的执行逻辑是：先查文章表，拿到所有文章的ID列表，再发一条SELECT FROM tag WHERE article_id IN (...)的查询，把标签全部取出来，在Python内存里按文章ID分组匹配。这种两条查询加内存拼接的方式，比N+1查询快几十倍。

更进阶的用法是结合Prefetch对象做过滤和自定义查询。比如只预取活跃标签：

from django.db.models import Prefetch
active_tags = Tag.objects.filter(is_active=True)
articles = Article.objects.prefetch_related(
    Prefetch('tags', queryset=active_tags)
)

你还可以在Prefetch里嵌套select_related，处理标签表本身的外键，比如标签的创建者。这种链式优化在实际项目中非常实用。

only和defer精确控制查询字段

很多开发者习惯用all()取出全部字段，但一个文章表可能有content这种TEXT大字段，列表页根本不需要显示正文。传输大量无用数据会拖慢查询速度，增加网络开销和内存占用。

用only指定只取需要的字段：

articles = Article.objects.only('title', 'author', 'created_at').select_related('author')

这会让Django只SELECT title, author_id, created_at这几个列。注意外键字段在数据库里存的是_id，only里写外键名author时，实际取的是author_id，足够用来做关联。

反过来，如果你确定某个大字段在特定场景下不需要，用defer排除它：

articles = Article.objects.defer('content', 'summary')

only和defer的一个坑是：如果你后续又访问了未加载的字段，Django会发起延迟加载查询，每条记录一次。这等于制造了新的N+1问题。所以使用only和defer时必须明确知道后续代码会用到哪些字段，不确定就宁可多取几个小字段，也不要漏掉导致延迟查询。

批量操作替代循环保存

需要批量创建或更新数据时，循环调用save()是性能杀手。每次save()都是一次独立的数据库事务和网络往返。Django提供了bulk_create和bulk_update来把多次操作合并成一条SQL。

批量创建：

articles = [
    Article(title=f'文章{i}', author=author)
    for i in range(1000)
]
Article.objects.bulk_create(articles, batch_size=100)

batch_size参数控制每批次插入的记录数，避免单条SQL语句过长。对于上万条数据，设置合理的batch_size（通常100到500）能平衡内存和数据库压力。

批量更新：

articles = Article.objects.filter(status='draft')
for article in articles:
    article.status = 'published'
Article.objects.bulk_update(articles, ['status'])

bulk_update的第一个参数是模型实例列表，第二个参数是要更新的字段名列表。它会生成一条带CASE WHEN的UPDATE语句，把所有修改合并执行。需要注意bulk_update不会触发save()信号和auto_now字段更新，如果你的业务依赖这些机制，需要额外处理。

对于数据量极大的场景，还可以考虑用数据库层面的UPSERT语法。PostgreSQL 9.5以上支持ON CONFLICT，MySQL支持ON DUPLICATE KEY UPDATE。Django 4.2开始bulk_create支持update_conflicts参数，可以在插入冲突时自动更新指定字段，省去先查后改的步骤。

用values和values_list取字典和元组

当你只需要数据不需要模型实例时，values和values_list能大幅减少ORM实例化的开销。模型实例的创建涉及字段描述符绑定、信号注册等元操作，查询一万条记录时，实例化一万个对象的耗时不可忽略。

values返回QuerySet of dict：

titles = Article.objects.values('id', 'title')
for item in titles:
    print(item['title'])

values_list返回元组，更轻量：

titles = Article.objects.values_list('id', 'title', named=True)
for item in titles:
    print(item.title)  # named=True时可以用点号访问

values_list配合flat=True可以直接获取单个字段的列表，适合做ID收集：

author_ids = list(Article.objects.values_list('author_id', flat=True).distinct())

这种写法在需要把查询结果传给下一步过滤条件时非常高效，比取模型实例再提取ID快三到五倍。

数据库索引的策略性使用

ORM优化做到极致后，瓶颈会转移到数据库本身的查询执行计划上。索引是最直接的数据库优化手段，但加索引不是越多越好，每个索引都会拖慢写入速度并占用磁盘空间。

Django里定义索引：

class Article(models.Model):
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    status = models.CharField(max_length=20)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        indexes = [
            models.Index(fields=['status', 'created_at']),
            models.Index(fields=['author', 'status']),
        ]

联合索引的字段顺序至关重要。以上面的status和created_at联合索引为例，它能加速WHERE status = 'published' ORDER BY created_at的查询，但无法加速WHERE created_at > '2024-01-01'的单条件查询，因为索引最左前缀是status。设计索引前，务必梳理清楚你的查询模式，按最常用的过滤和排序组合来建索引。

对于大表，创建索引本身可能锁表，生产环境要用CONCURRENTLY方式创建（Django迁移默认不支持，需要手动执行RunSQL）。另外，定期用数据库的EXPLAIN命令分析慢查询的执行计划，看看索引是否被真正使用，有时候统计信息过时会导致优化器选择全表扫描。

连接池解决连接开销

Django默认的数据库连接管理是每次请求开启一个连接，请求结束关闭。在高并发场景下，频繁建立和销毁TCP连接的开销很大，SSL握手更是加重负担。引入连接池可以让连接复用，显著降低延迟。

对于PostgreSQL，推荐使用django-db-connection-pool或直接配置pgbouncer。django-db-connection-pool的配置很简单：

DATABASES = {
    'default': {
        'ENGINE': 'django_db_connection_pool.backends.postgresql',
        'POOL_OPTIONS': {
            'POOL_SIZE': 20,
            'MAX_OVERFLOW': 10,
            'RECYCLE': 3600,
        },
        'NAME': 'mydb',
        'USER': 'myuser',
        'PASSWORD': 'mypassword',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

POOL_SIZE是常驻连接数，MAX_OVERFLOW是额外可创建的临时连接数，RECYCLE是连接最大存活时间，防止数据库端主动断开导致连接失效。对于MySQL，可以用django-mysql的连接池或ProxySQL中间件。

需要注意的是，连接池模式下事务隔离和连接状态管理要格外小心。确保每个请求结束时事务被正确提交或回滚，否则脏连接被放回池中会影响后续请求。Django的ATOMIC_REQUESTS设置可以自动为每个请求包裹事务，配合连接池使用效果很好。

用原生SQL和数据库函数处理复杂计算

ORM的表达能力有限，遇到复杂的聚合统计、窗口函数、递归查询时，强行用ORM拼接不仅代码丑陋，生成的SQL也可能效率低下。这时候直接写原生SQL是更明智的选择。

Django提供了多种执行原生SQL的方式。raw()方法返回模型实例：

sql = """
    SELECT id, title, 
           ROW_NUMBER() OVER (PARTITION BY author_id ORDER BY created_at DESC) as rn
    FROM article
    WHERE status = 'published'
"""
articles = Article.objects.raw(sql)

更灵活的是用connection.cursor直接执行：

from django.db import connection
with connection.cursor() as cursor:
    cursor.execute("""
        SELECT author_id, COUNT(*) as cnt
        FROM article
        WHERE created_at >= %s
        GROUP BY author_id
        HAVING COUNT(*) > %s
    """, ['2024-01-01', 10])
    rows = cursor.fetchall()

使用原生SQL时务必用参数化查询防止注入，不要用字符串拼接用户输入。另外，原生SQL绕过了ORM的模型层，返回的数据需要手动处理字段映射，适合用在性能敏感的报表统计、数据迁移、复杂ETL场景。

Django也提供了丰富的数据库函数封装，如Cast、Coalesce、Length、Lower等，可以在不写原生SQL的情况下把计算下推到数据库层。比如按文章标题长度排序：

from django.db.models.functions import Length
articles = Article.objects.annotate(title_len=Length('title')).order_by('-title_len')

这种写法既保持了ORM的可读性，又避免了把数据拉到Python层再排序的浪费。

缓存策略减少数据库命中

即使查询优化到极致，有些高频读取的数据仍然没必要每次都查数据库。Django的缓存框架支持多种后端，对数据库查询结果做缓存能进一步降低负载。

视图层缓存是最简单的形式：

from django.views.decorators.cache import cache_page

@cache_page(60 * 15)  # 缓存15分钟
def article_list(request):
    articles = Article.objects.select_related('author').all()
    return render(request, 'list.html', {'articles': articles})

更细粒度的缓存需要手动操作cache对象：

from django.core.cache import cache

def get_top_authors():
    cache_key = 'top_authors_v1'
    result = cache.get(cache_key)
    if result is None:
        result = list(Author.objects.annotate(
            article_count=Count('article')
        ).order_by('-article_count')[:20])
        cache.set(cache_key, result, 600)
    return result

缓存键加版本号是良好的实践，数据模型变更时可以升级版本号让旧缓存自然失效。另外要注意缓存一致性问题，当底层数据更新时，必须主动清除或更新对应缓存，否则用户会看到过期数据。可以在模型的save()和delete()方法中发送信号来触发缓存失效逻辑。

对于实时性要求不高的统计类数据，还可以考虑用数据库物化视图或定时任务把计算结果预先算好存入单独的表，查询时直接读取预计算结果，把复杂聚合的开销从请求路径中彻底移除。

数据库交互优化是一个持续的过程，没有一劳永逸的方案。建议在项目中集成django-debug-toolbar，它会在页面侧边栏展示当前请求的所有SQL查询、执行时间和重复查询警告。每次开发新功能时扫一眼SQL面板，发现异常查询立刻修正。养成这个习惯后，大部分性能问题会在上线前就被扼杀在开发阶段。

Django框架网站数据库交互优化实操教程

服务指南

帮助中心