select_related 能减少查询次数，因为它用 JOIN 在主查询中预先拉取外键/一对一关联数据，避免懒加载导致的 N+1 查询，但仅适用于 ForeignKey 和 OneToOneField，且默认 INNER JOIN 可能过滤空关联记录。
为什么 select_related 能减少查询次数？
因为 Django 默认使用懒加载（lazy loading），访问外键字段时才发起新查询。比如 author = book.author.name 会触发一次额外的 SELECT 查询。而 select_related 在主查询中用 JOIN 预先拉取关联表数据，把多次查询合并成一次。
它只适用于外键（ForeignKey）和一对一（OneToOneField）关系，且默认走 INNER JOIN —— 如果关联记录不存在，整行会被过滤掉。这点容易被忽略，尤其在可选外键场景下。
- 必须在
QuerySet执行前调用，比如Book.objects.select_related('author').all() - 不能跨多对多或反向外键（如
author.book_set.all()），这类要用prefetch_related - 链式调用支持多层，例如
.select_related('author__profile')，但每多一层JOIN，结果集可能膨胀，注意数据量
select_related 的参数写法和常见错误
参数是字符串形式的字段名，支持双下划线表示嵌套关系。但写错字段名、拼写错误或指向非外键字段，Django 不报错，只是静默忽略该 select_related —— 这是最常踩的坑。
- 正确：
Book.objects.select_related('author')（author是ForeignKey） - 错误：
Book.objects.select_related('author_name')（字段不存在） - 错误：
Book.objects.select_related('tags')（tags是多对多，应改用prefetch_related） - 错误：
Book.objects.select_related('author').filter(author__isnull=True)可能返回空结果，因为INNER JOIN排除了无作者的书
什么时候不该用 select_related？
不是所有关联都适合。如果关联表数据量大、字段多，或者你只用其中一两个字段，JOIN 可能导致主表重复行增多、网络传输变大、数据库压力上升。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
- 关联表有上万行，且你只读
author.name：考虑用values_list('author__name')或手动annotate提取字段，避免载入整张Author表 - 需要过滤关联字段（如
author__status='active'）又不想丢掉主表空关联记录：改用LEFT OUTER JOIN，Django 不直接支持，得用extra(tables=..., where=...)或原生 SQL - 涉及反向关系（如从
Author查所有Book）：必须用prefetch_related，否则会报FieldError
验证是否生效：看 SQL 和查询次数
最可靠的方式是打开 Django Debug Toolbar，或直接打印 str(queryset.query) 看生成的 SQL 是否含 JOIN。别只凭“没报错”就认为生效了。
- 检查日志里的
connection.queries，对比加/不加select_related前后的查询数 - 注意：模板中重复访问同一外键字段（如循环里多次写
{{ book.author.name }}）不会新增查询，但前提是select_related已启用；否则每次都是新查询 - 测试时禁用缓存，避免误判：临时设
CACHES = {'default': {'BACKEND': 'django.core.cache.backends.dummy.DummyCache'}}
真正难的是权衡 JOIN 的开销和 N+1 查询的延迟——没有银弹，得看实际数据分布和查询模式。
