select_related通过LEFT OUTER JOIN一次性获取外键/一对一关联数据，将N+1查询优化为1次，仅适用于正向关系，嵌套写法如"user__company"，需在QuerySet求值前调用。
为什么 select_related 能减少 SQL 查询次数
当模型字段是 ForeignKey 或 OneToOneField，且你在循环中反复访问关联对象（比如 order.user.username），Django 默认会为每个对象单独发一条 SQL 查询——这就是典型的 N+1 问题。而 select_related 通过 JOIN 在一次查询中把关联表数据一并取回，把 N+1 次查询压成 1 次。
它只对「正向外键」和「一对一」有效，不支持反向关系或多对多；底层用的是 LEFT OUTER JOIN，所以要注意 NULL 值处理。
select_related 的正确写法和常见错误
必须在 QuerySet 执行前调用，且参数是字符串形式的字段名（支持嵌套，如 "user__profile"）。不能在 filter() 之后再加 select_related()？可以，只要没触发求值（比如没遍历、没切片、没调 list()）就仍属于 QuerySet 链式操作。
- ✅ 正确：
Order.objects.select_related("user").filter(status="paid") - ✅ 嵌套也行：
Order.objects.select_related("user__company")（前提是User有company外键） - ❌ 错误：
Order.objects.all().select_related("items")（items是反向外键，该用prefetch_related） - ❌ 错误：
list(Order.objects.all()); Order.objects.select_related("user")（已经执行了查询，再链式调用无效）
什么时候不该用 select_related
不是所有外键都适合用它。如果关联表数据量大、字段多，或者你其实只用其中一两个字段，JOIN 可能导致结果集膨胀、内存占用高、甚至拖慢主表排序。另外，MySQL 对 JOIN 数量有限制（默认 61），嵌套过深（比如 "a__b__c__d__e"）可能直接报错 ERROR 1116 (HY000): Too many tables。
立即学习“Python免费学习笔记（深入）”；
- 关联表行数远大于主表时，优先考虑
prefetch_related+ 单独查询 - 需要按关联字段排序或过滤（如
.order_by("user__name")），select_related通常没问题；但若涉及复杂条件（如子查询、聚合），JOIN 可能失效或生成低效 SQL - SQLite 不支持多个 JOIN 的某些优化路径，开发环境快不代表上线也快
怎么确认优化生效了
别靠猜。打开 Django Debug Toolbar，或手动开启查询日志：LOGGING 配置里打开 django.db.backends 的 DEBUG 级别，然后看实际发出的 SQL 条数和内容。重点核对：
- 原来 N+1 场景下是否只剩 1 条含
INNER JOIN或LEFT OUTER JOIN的语句 - 返回字段是否包含预期的关联表字段（如
user_id,user_username） - 有没有意外引入重复行（比如一对多关系误用了
select_related，虽然不会报错，但数据逻辑已错）
嵌套太深、JOIN 表太多时，SQL 可读性会急剧下降，这时候不如拆成两步：先查主表 ID 列表，再用 __in 批量查关联数据——手动控制比让 ORM 硬扛更稳。
