Django 部署上线后，数据库查询性能下降是一个常见反馈。很多问题在开发阶段不容易暴露，因为数据量小、并发低。下面是根据经验整理的排查和处理路径，每一步都建议先在预发布环境验证，确认有效再应用到生产。

先检查 N+1 查询

在Django部署后，最常见的影响数据库查询性能的问题是N+1查询。当使用ORM通过外键访问关联对象时，默认会逐条发送SQL语句。判断方法是在开发环境下启用django-debug-toolbar面板，观察SQL查询次数是否远超预期。例如，如果列表页显示100篇文章并显示每篇的作者名，正常仅需一条JOIN查询，但若未使用select_related，则会执行101次查询。修复时需在View集或QuerySet链式调用中主动添加select_related或prefetch_related，根据关联关系是一对一还是多对多选择不同方法。注意不要对非必需关系也添加预加载，否则可能因笛卡尔积导致数据量暴增，反而拖慢性能。

除了 debug-toolbar，还可以在数据库层开启慢查询日志，观察是否有大量重复的简单 SELECT。如果发现类似 SELECT ... FROM auth_user WHERE id = %s 反复出现，基本可以确认是 N+1。修复后对比前后查询次数和响应时间，确保不再出现模式重复的 SQL。

索引加对了没

数据库索引是提升查询速度的关键，但不当的索引反而会增加写入开销。在Django中，可以通过在模型Meta类中设置indexes或使用db_index参数创建索引。务必对WHERE、JOIN、ORDER BY涉及到的字段加索引，比如filter(user_id=xxx)时确保user_id有索引。判断现有数据库查询是否走索引的方法：在数据库层执行EXPLAIN命令，观察type是否为range、ref或const，rows数是否大幅减少。常见坑点是给布尔或低基数字段加索引：性别字段只有两个值，索引效果极差。另外，Django的ForeignKey默认创建b树索引，但若有大量联合查询需求，可能需要手动添加联合索引（Index(fields=['user','created'])）。部署后切记先在测试环境验证索引生效…

执行 EXPLAIN 时，重点关注 Extra 列是否出现 Using filesort 或 Using temporary，这通常意味着缺少合适索引或查询需要优化。对于联合索引，字段顺序很重要：通常把区分度高的放前面。如果发现某个查询扫描行数远大于返回行数，说明索引过滤性不足，可以尝试调整索引字段或改用覆盖索引。

不必要的字段也拖性能

默认情况下Django ORM会查询全部字段，即使后续只需要少数几个。在部署后的高负载场景下，这会造成不必要的网络和内存开销。可以在查询时使用only()或defer()来指定需要的字段。比如用户列表页仅需姓名和邮箱，则应使用User.objects.only('username','email')。但要注意only()会返回一个不可更新的实例，如果需要修改对象，必须重新从数据库获取完整字段。对于关联模型，可以使用values()或values_list()直接获取字典或元组，配合annotate()完成复杂聚合。性能敏感的场景优先考虑values()，但会丢失模型方法。需要根据实际展示需求在灵活性和性能之间权衡。

结合前面 N+1 和索引的检查，可以把只返回必要字段作为一个常规优化步骤。如果视图只展示几个字段，却拉了整行数据，数据库和 Django 之间的传输量会明显增大。尤其在带宽或内存紧张的环境下，这种开销不可忽视。

缓存用在刀刃上

对于频繁读取但更新不频繁的数据，比如配置表或热门的文章详情，使用Django缓存框架能显著减轻数据库压力。判断哪些数据适合缓存：可以观察慢查询日志或数据库连接数，通常读取次数是写入次数10倍以上的数据值得缓存。操作上，可以在视图或模板标签中使用cache.set()和cache.get()，或者利用@cache_page装饰器缓存整个视图。常见风险是缓存雪崩和缓存穿透：大量缓存同时过期导致请求打穿到数据库；或者查询一个根本不存在的key，每次都会查询DB。解决办法包括给缓存过期时间加入随机抖动避免雪崩，以及使用布隆过滤器或缓存空对象来防止穿透。部署后应监控缓存命中率，理想命中率在80%以上，但具体数值需要根据业务场景确定，不必强求。

如果使用了 Redis 或 Memcached，还可以通过 cache.get_or_set 简化代码。注意缓存的粒度：缓存整个页面还是局部片段？高频接口适合缓存整个响应，但要注意用户个性化内容可能会被缓存错误。对于简单数据，缓存时间可以设长一些，比如配置表缓存 1 小时；对于列表数据，可以用信号或定时任务在数据变更时主动失效缓存，避免脏读。

避免循环查询的老问题

在Django模板渲染或视图处理中，最常见的一个性能反模式是在循环中逐条查询数据库。例如，在模板中通过 {{ object.related_set.all }} 渲染关联数据，默认每次请求都会触发新查询。应当使用 prefetch_related 一次性预加载全部关联对象，Django会生成两条SQL（一条主表，一条关联表），然后在内存中完成关联。判断方法：在开发环境下开启日志打印所有SQL，如果看到模式重复的SELECT语句，就是循环查询。修复时，在视图中使用 prefetch_related 传参，并利用 Prefetch 对象控制过滤排序。特别注意：如果使用了多个层级的一对多关联，可能需要多次 prefetch。极限场景下，也可以考虑使用自定义的SQL子查询直接内联，但会增加维护成本。

修复循环查询后，可以再次检查 SQL 日志，确认只剩下预期的几条查询。如果数据量大，还可以结合 only() 减少关联表返回的字段，进一步提升效率。

以上几个步骤可以按顺序执行：先查 N+1，再确认索引，然后精简字段、引入缓存。每一步改完后，建议用 timeit 或 Django Debug Toolbar 记录前后耗时，对比确认效果。性能优化往往需要多次迭代，切忌一次性改太多导致难以定位问题。