一、为什么Django ORM查询会变慢？
相信很多使用Django开发的小伙伴都遇到过这样的情况：明明项目刚开始运行得飞快，但随着数据量增加，页面加载速度越来越慢，有时候一个简单的列表查询都要好几秒才能返回结果。这其实就是典型的ORM查询性能下降问题。
造成这种情况的原因主要有三个：首先是N+1查询问题，这是ORM最常见的性能陷阱；其次是缺乏适当的索引，导致数据库全表扫描；最后是查询语句不够优化，加载了过多不必要的数据。
举个例子，我们有个电商系统，要查询订单列表：
# 反面教材：典型的N+1查询问题
orders = Order.objects.all() # 第一次查询获取所有订单
for order in orders:
print(order.customer.name) # 每次循环都执行一次查询获取客户信息
这个简单的循环会导致1次查询订单列表，然后对每个订单再查询一次客户信息。如果有100个订单，就会产生101次查询！
二、解决N+1查询的利器：select_related和prefetch_related
Django提供了两个神器来解决N+1问题：select_related和prefetch_related。
select_related适用于外键和一对一关系，它通过SQL的JOIN操作一次性获取关联数据：
# 使用select_related优化
orders = Order.objects.select_related('customer').all() # 单次查询通过JOIN获取订单和客户信息
for order in orders:
print(order.customer.name) # 不再产生额外查询
prefetch_related则适用于多对多和反向外键关系，它通过两条查询语句然后在Python层面进行关联：
# 商品和分类是多对多关系
products = Product.objects.prefetch_related('categories').all()
for product in products:
print(product.categories.all()) # 不会产生N+1查询
实际项目中，我们经常会遇到多层关联的情况：
# 多层关联查询优化
orders = Order.objects.select_related(
'customer', # 订单关联的客户
'payment' # 订单关联的支付信息
).prefetch_related(
'items__product', # 订单项关联的商品
'items__product__categories' # 商品关联的分类
).filter(status='completed')
三、数据库索引的艺术
没有合适的索引，再好的ORM查询也会慢如蜗牛。Django中可以通过模型的Meta类来定义索引：
class Order(models.Model):
customer = models.ForeignKey(Customer, on_delete=models.CASCADE)
created_at = models.DateTimeField(auto_now_add=True)
status = models.CharField(max_length=20)
class Meta:
indexes = [
# 单个字段索引
models.Index(fields=['status']),
# 复合索引
models.Index(fields=['customer', 'created_at']),
# 条件索引
models.Index(fields=['created_at'], condition=Q(status='completed')),
]
创建索引时要注意：
- 为经常用于查询条件和排序的字段创建索引
- 复合索引要注意字段顺序，最常用的字段放前面
- 不要过度索引，因为索引会降低写入性能
四、高级查询优化技巧
除了基本的优化方法，Django ORM还提供了一些高级技巧：
- 使用only()和defer()控制字段加载：
# 只加载需要的字段
users = User.objects.only('username', 'email') # 只查询这两个字段
# 延迟加载大字段
products = Product.objects.defer('description') # 不立即加载描述字段
- 使用values()和values_list()获取字典或元组结果：
# 获取字典结果，比模型实例更轻量
orders = Order.objects.values('id', 'total_amount')
# 获取元组结果，内存占用更小
order_ids = Order.objects.values_list('id', flat=True)
- 批量操作替代循环：
# 反面教材：循环更新
for user in User.objects.filter(is_active=False):
user.send_activation_email()
user.save()
# 正面教材：批量更新
User.objects.filter(is_active=False).update(
last_notified=timezone.now()
)
五、实战：一个完整的优化案例
假设我们有一个博客系统，需要优化文章列表页的查询：
优化前的代码：
# 原始查询：性能很差
articles = Article.objects.filter(status='published')
for article in articles:
print(article.title, article.author.username, article.comment_count())
优化步骤：
- 解决N+1问题：
articles = Article.objects.select_related('author').filter(status='published')
- 预计算评论数：
from django.db.models import Count
articles = Article.objects.select_related('author').filter(
status='published'
).annotate(
comment_count=Count('comments')
)
- 添加必要的索引：
class Article(models.Model):
title = models.CharField(max_length=200)
content = models.TextField()
author = models.ForeignKey(User, 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']),
]
- 最终优化后的查询：
articles = Article.objects.select_related('author').filter(
status='published'
).annotate(
comment_count=Count('comments')
).only(
'title', 'created_at', 'author__username'
).order_by('-created_at')
六、监控和诊断查询性能
优化之后，我们还需要监控查询性能：
使用Django Debug Toolbar查看执行的查询
使用explain()分析查询计划：
# 查看查询执行计划
query = Article.objects.filter(status='published').explain()
print(query)
- 记录慢查询：
# settings.py
LOGGING = {
'handlers': {
'console': {
'level': 'DEBUG',
'filters': ['require_debug_true'],
'class': 'logging.StreamHandler',
}
},
'loggers': {
'django.db.backends': {
'level': 'DEBUG',
'handlers': ['console'],
}
}
}
七、总结与最佳实践
经过上面的探讨，我们可以总结出Django ORM查询优化的最佳实践：
- 始终使用select_related和prefetch_related解决N+1问题
- 为常用查询条件添加适当的数据库索引
- 只查询需要的字段，避免加载不必要的数据
- 使用annotate和aggregate进行聚合计算
- 批量操作优于循环操作
- 定期监控和诊断查询性能
记住，ORM是为了提高开发效率，但不是性能的免死金牌。好的ORM使用应该是在开发效率和查询性能之间找到平衡点。
最后要提醒的是，当数据量真的非常大时，可能需要考虑其他解决方案，比如：
- 使用缓存减轻数据库压力
- 考虑读写分离
- 对数据进行分片
- 使用专门的搜索引擎如Elasticsearch
评论