django-db-performance

Django 数据库性能

将其用作 Django 数据库性能工作的编排技能。从测量证据入手，复现慢路径，并选择能改变已测量瓶颈的最小优化方案。

核心工作流

1. 记录问题表现。

   • 找出确切的端点、命令、任务、报告或查询集。
   • 记录当前耗时、查询数量、慢 SQL、数据库后端、数据量和 Django 版本。
   • 保留能复现问题的原始请求参数或 fixture。

2. 先分析性能，再修改代码。

   • 使用 APM 跟踪、数据库慢查询日志、Django Debug Toolbar、connection.queries 或针对性日志记录。
   • 如果已知开销最大的查询，请使用 QuerySet.explain() 或数据库的 EXPLAIN。
   • 对于 API 端点，还要分析序列化器和权限检查，而不仅是查询集。

3. 判断主要问题类型。

   • 大量重复的相似查询：使用 django-orm-query-optimization。
   • 一两条开销很大的 SQL 语句：使用 django-query-plan-reading 和 django-index-design。
   • 内存占用过大，或遍历查询集的循环耗时过长：使用 django-queryset-batch-processing。
   • Python 循环在计算计数、总计、标记或最新的关联行：使用 django-db-side-computation。
   • 缓存旧数据也可接受的慢速聚合或报告查询：使用 django-materialized-views。
   • 缓慢或结果不一致的列表页：使用 django-pagination-performance。
   • 证据不明确：使用 django-query-profiling。

4. 每次只应用一项更改。

   • 优先选择范围最小且预期效果明确的更改。
   • 避免凭猜测添加索引、预取或物化视图。
   • 确认优化在接近生产环境的数据上有效，而不只是对极小的 fixture 有效。

5. 验证并记录结果。

   • 使用相同参数重新运行相同的请求或命令。
   • 比较查询数量、数据库总耗时、总耗时、内存和查询计划。
   • 在 PR 或最终报告中保留优化前后的证据。

请参阅 diagnostic-flow.md，了解路由检查清单、常见问题表现以及优化前后证据模板。

现代 Django 注意事项

• 在使用原生 EXPLAIN 前，优先使用 QuerySet.explain() 查看 ORM 查询计划。
• 适用时，优先使用 AddIndexConcurrently 等 Django/PostgreSQL 原生迁移操作，而不是手写并发索引 SQL。
• 使用 ORM 表达式、Subquery、Exists、Window、GeneratedField 和 db_default，在让数据库操作更明确且足够可移植时，优先采用这些功能。
• 任何特定于后端的优化都要视项目使用的数据库而定。PostgreSQL 模式不会自动适用于 MySQL、MariaDB、SQLite 或 Oracle。

验证

• 证明慢路径在功能上仍然正确。
• 证明测得的瓶颈有所改善。
• 证明优化没有导致查询变差、数据过时错误、写入路径回归或内存激增。