生产环境遇到数据库查询慢，先确认是否真的适合用 select_related，它只适用于外键和一对一关系，用错地方反而会增加数据库负担。

生产环境排查方案

1. 使用 APM 工具监控

在生产环境严禁开启 Django DEBUG 日志。推荐使用 Sentry、Datadog 或 SkyWalking 等 APM 工具，通过 Trace 链路查看数据库查询耗时和次数。

2. 分析数据库慢查询日志

直接查询数据库层面的慢日志，避免应用层日志开销。

# MySQL 开启慢查询日志（需重启或动态设置）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; # 记录超过 1 秒的查询

# 查看慢查询日志文件位置
SHOW VARIABLES LIKE 'slow_query_log_file';

# PostgreSQL 使用 pg_stat_statements 扩展
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT query, calls, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

优化实施步骤

1. 调整 ORM 查询语句

在 QuerySet 上链式调用 select_related，参数可以是字符串或嵌套字典。注意只加真正需要的字段。

# 优化前：循环中触发额外查询
for obj in Model.objects.all():
    print(obj.related_field.name)

# 优化后：一次性 JOIN 取出
for obj in Model.objects.select_related('related_field').all():
    print(obj.related_field.name)

# 只关联必要的外键
qs = Model.objects.select_related('user', 'category')
# 深层关联
qs = Model.objects.select_related('user__profile')

2. 检查数据库索引

JOIN 操作依赖外键字段的索引。确保关联字段在数据库层面建有索引，否则 JOIN 效率会极低。可以通过数据库自带的慢查询日志确认。

3. 限制返回字段

如果表字段很多，配合 only() 或 defer() 减少网络传输数据量。

qs = Model.objects.select_related('user').only('id', 'name', 'user__username')

验证优化效果

1. 对比查询次数

在开发环境使用 Django Debug Toolbar 验证逻辑是否正确。生产环境依赖 APM 工具展示的 SQL 计数，理想情况下，列表页的查询次数应显著下降。

2. 检查单条 SQL 耗时

查看数据库慢查询日志，确认优化后的 JOIN 语句执行时间是否在合理范围内。如果单条 SQL 耗时激增，说明 JOIN 代价过大。

3. 页面响应时间

监控应用层面的接口响应时间，确保整体延迟降低，而不是把压力从应用层转移到了数据库层。

常见坑与风险

1. 误用于多对多关系

select_related 不支持 ManyToManyField。如果在多对多字段上使用，Django 会忽略该调用或报错，此时应改用 prefetch_related。

2. 关联层级过深

连续 select_related('a__b__c__d') 会导致 SQL 极其复杂，数据库优化器可能无法生成高效执行计划。一般建议不超过 2-3 层。

3. 大表 JOIN 大表

如果主表和关联表数据量都很大，JOIN 会产生巨大的中间结果集。这种情况下，有时拆分成两次查询（使用 prefetch_related）反而更快。

4. 生产环境日志风险

切勿在生产环境开启 django.db.backends 的 DEBUG 日志，这会消耗大量 IO 和内存，甚至泄露敏感数据。上线前务必确认日志级别为 WARNING 或 ERROR。