select_related只对单值关系有效且须在查询上游调用；错用于多对多、在已求值queryset上调用、字段名错误均导致静默失效；嵌套过深引发笛卡尔积和性能下降；须置于prefetch_related之前；验证需查sql和查询次数。
直接上结论：select_related 只对单值关系（ForeignKey、OneToOneField）有效，且必须在查询链路的“上游”调用；用错位置或误用于多对多关系，不仅无效，还会让 SQL 更复杂、更慢。
为什么 select_related 查询没生效？
常见现象是加了 select_related 但 Django Debug Toolbar 仍显示 N+1 查询，或者 query 属性打印出的 SQL 没有 JOIN。根本原因通常是：
- 在已经执行过的 QuerySet（比如调用了
list()、len()或遍历后）再链式调用select_related—— 这个调用被忽略，因为 QuerySet 已“求值” - 试图对
ManyToManyField或反向ForeignKey（如author.book_set.all()）使用select_related—— 它不支持，会静默失效 - 字段名写错，比如写成
select_related('author__profile')，但Author模型里没有profile字段，Django 不报错，但 JOIN 不生成
select_related 的嵌套深度怎么控制？
可以多层嵌套，比如 select_related('author__company__address')，Django 会生成对应层级的 LEFT OUTER JOIN。但要注意：
- 每多一层，SQL 的
JOIN就多一张表，结果集行数可能因笛卡尔积暴增（尤其当某层有多条记录时） - 数据库连接数和内存占用上升，PostgreSQL 对 JOIN 数量有默认限制（
from_collapse_limit），超限会退化为子查询 - 不是越深越好：如果只用到
author.name，却select_related('author__company__address')，浪费 I/O 和内存
建议原则：只 select_related 真正会在模板或视图中访问的外键字段，且优先从最常访问的那层开始写，避免跨模型过度穿透。
和 prefetch_related 混用时谁先谁后？
顺序很重要：select_related 必须放在 prefetch_related 前面。因为：
-
select_related修改的是主查询的 SQL（加 JOIN），而prefetch_related是额外发 SELECT 查询 + 内存拼接 - 如果先
prefetch_related再select_related，Django 会把select_related当作新 QuerySet 处理，导致前面 prefetch 的数据被丢弃，重新触发 N+1 - 典型正确写法：
Book.objects.select_related('author').prefetch_related('tags')—— 单值走 JOIN，多值走额外查询
如何验证 select_related 是否真正起作用？
不能只看代码写了没，得看实际生成的 SQL 和查询次数：
- 用
str(queryset.query)打印 SQL，确认有INNER JOIN或LEFT OUTER JOIN，且ON条件符合预期 - 在视图中用
connection.queries（DEBUG=True 时）数查询条数，对比加/不加select_related的差异 - 注意：Django Shell 中反复执行同一 QuerySet 会缓存结果，要每次新建 QuerySet 或加
.all()强制重查
最容易被忽略的是：即使 SQL 里出现了 JOIN，如果后续代码又触发了未预取字段的访问（比如 book.author.profile.avatar.url 而 profile 没被 select_related），依然会补查——预取不是“全局生效”，而是精确到你声明的路径。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
