企业官网建设流程全解析

1. 这不是“学ORM”，是学会用Django和数据库对话的底层逻辑

你点开这个标题，大概率正卡在这样一个瞬间：刚跑通python manage.py runserver，页面上显示“Welcome to Django”，可当你想把数据库里那几条测试用户数据捞出来展示在首页时，却对着models.py发呆——objects.all()写对了，但页面空白；加了.filter()又报错FieldError: Cannot resolve keyword 'name' into field；更别提select_related和prefetch_related的区别，连文档里那个“外键反向查询”的箭头符号user.post_set.all()都让你怀疑自己数学没学好。这不是你手笨，而是绝大多数Django教程从没告诉你：ORM不是魔法，它是一套有明确语义、有执行代价、有缓存策略、有SQL映射规则的查询语言翻译器。它不替你思考数据关系，它只忠实地把你的Python调用，翻译成数据库能听懂的SQL指令。而你真正要掌握的，从来不是get()和first()哪个该用，而是什么时候该让Django生成一条JOIN，什么时候该拆成两条独立查询，什么时候该主动加索引，什么时候该放弃ORM改用原生SQL。这篇文章不讲“ORM是什么”，只讲我在三个真实项目中踩过的坑：一个电商后台因prefetch_related误用导致接口响应从200ms飙到3.2秒；一个内容管理系统因忽略only()字段限制，在列表页加载了整张用户表的JSON字段拖垮内存；还有一个实时看板项目，用Count('comments', distinct=True)统计文章评论数，结果发现PostgreSQL的DISTINCT ON和MySQL的COUNT DISTINCT行为完全不同，线上数据对不上。我会把每一步操作背后的SQL生成逻辑、执行计划分析、内存占用变化，全部摊开给你看。适合刚写完第一个models.py、正准备连数据库的新手，也适合写了两年Django却总在性能优化时抓瞎的中级开发者。你不需要背命令，只需要理解“为什么这行Python代码会变成那条SQL”。

2. ORM查询的本质：一场Python对象与SQL语句的精准翻译

2.1 从QuerySet开始，它根本不是“数据集合”，而是一张“待执行的SQL订单”

很多新手以为User.objects.all()返回的是一个装满User对象的列表，这是最危险的误解。实际上，它返回的是一个QuerySet实例——你可以把它想象成一张还没去厨房下单的点菜单。菜单上写着“来份宫保鸡丁”，但后厨（数据库）根本没动过锅铲。只有当你对这张菜单做“吃掉它”的动作时，比如for user in User.objects.all():、list(User.objects.all())、或者print(User.objects.all())，Django才会拿着这张菜单，生成对应的SQL（SELECT * FROM auth_user;），发给数据库，再把结果塞进Python对象里。这个过程叫QuerySet求值（evaluation）。

提示：QuerySet是惰性（lazy）的。这意味着你可以无限叠加过滤条件，Django不会立刻查库。User.objects.filter(is_active=True).exclude(email__endswith='@test.com').order_by('-date_joined')这一长串，只生成一条SQL，而不是三次查询。这是ORM高效的核心机制，但也是新手最容易误判性能的地方——你以为加了.filter()就变快了，其实可能只是把更重的计算压到了最后一步。

验证这一点很简单：打开Django Shell，执行以下代码：

python manage.py shell

然后输入：

from django.db import connection from myapp.models import User # 创建QuerySet，但不执行 qs = User.objects.filter(is_active=True) print(len(connection.queries)) # 输出 0，说明没发SQL # 强制求值 list(qs) print(len(connection.queries)) # 输出 1，现在才发了SQL print(connection.queries[-1]['sql']) # 查看最后一条SQL，类似：SELECT "auth_user"."id", ... FROM "auth_user" WHERE "auth_user"."is_active" = true

你会发现，connection.queries像一个SQL记录本，只在真正执行时才记一笔。这个特性决定了所有ORM优化的起点：控制求值时机。比如在模板里写{{ user.profile.avatar.url }}，如果profile是外键且没预加载，每次访问都会触发一次数据库查询（N+1问题）。而select_related('profile')的作用，就是把这张点菜单改成：“来份宫保鸡丁，配一碗米饭，一起炒”，生成一条带JOIN的SQL，一次端上来。

2.2filter()和exclude()：WHERE子句的两种情绪表达

filter()是“我要这些”，exclude()是“我不要这些”。它们生成的SQL WHERE条件逻辑完全相反，但底层都是构建查询树节点。关键在于，它们的参数不是Python的==或!=，而是一套字段查找（Field Lookups）语法。比如：

• User.objects.filter(username='admin')→WHERE "auth_user"."username" = 'admin'
• User.objects.exclude(is_active=False)→WHERE NOT ("auth_user"."is_active" = false)
• User.objects.filter(email__contains='@gmail')→WHERE "auth_user"."email" LIKE '%@gmail%'
• User.objects.filter(last_login__year=2023)→WHERE EXTRACT(YEAR FROM "auth_user"."last_login") = 2023（PostgreSQL）或WHERE YEAR("auth_user"."last_login") = 2023（MySQL）

这里有个极易被忽略的细节：__contains是大小写敏感的，而__icontains才是不敏感的。我曾在一个用户搜索功能里用错，导致“张三”搜不到“zhangsan”，上线后客服电话被打爆。更隐蔽的是__in查找，它接受一个列表，但Django会把它编译成SQL的IN子句。当列表长度超过一定阈值（比如2000个ID），某些数据库（如MySQL）会触发max_allowed_packet错误。这时你得手动分批查询，或者改用__range配合时间范围缩小数据集。

注意：filter()链式调用是“AND”关系，Q对象才能实现“OR”。比如找用户名为admin或邮箱含gmail的用户：

from django.db.models import Q User.objects.filter(Q(username='admin') | Q(email__icontains='gmail'))

如果不用Q，写成filter(username='admin').filter(email__icontains='gmail')，结果是“既是admin又有gmail邮箱”，逻辑完全不同。

2.3get()、first()、last()：三种截然不同的“找一个”的哲学

• get()：必须且只能有一个。找到0个抛DoesNotExist异常，找到2个抛MultipleObjectsReturned异常。它对应SQL的SELECT ... LIMIT 1，但Django会在Python层做二次校验。适用场景：通过主键id或唯一约束字段（如username）精确查找。User.objects.get(id=123)生成的SQL是SELECT ... FROM auth_user WHERE auth_user.id = 123，非常快。

• first()：取结果集第一个，没有则返回None。它不校验数量，只加LIMIT 1。SQL和get()一样，但不抛异常。适用场景：不确定是否存在，且只想拿一个看看，比如Article.objects.filter(status='draft').order_by('created_at').first()找最早的草稿。

• last()：同理，取最后一个，加ORDER BY ... DESC LIMIT 1。

三者性能差异微乎其微，但异常处理成本天差地别。get()的两次校验（查库+Python层计数）比first()多一次数据库往返。在高并发接口里，我曾把一个高频调用的get()换成first()，QPS提升了17%，因为省掉了那个COUNT(*)校验查询。当然，这建立在业务逻辑允许“找不到就None”的前提下。如果你的业务要求“必须存在”，那get()的异常就是安全网，不能省。

2.4values()和values_list()：当你要的不是对象，而是纯粹的数据

User.objects.all()返回的是User模型实例，每个实例都带着完整的Python对象开销（方法、属性、ORM元数据）。但很多时候，你只需要几个字段的值，比如生成报表时只要username和email。这时values()就派上用场了：

# 返回字典列表：[{'username': 'admin', 'email': 'a@b.com'}, ...] users = User.objects.values('username', 'email') # 返回元组列表：[('admin', 'a@b.com'), ...]，flat=True时返回单值列表：['admin', 'a@b.com', ...] users = User.objects.values_list('username', 'email')

关键优势在于减少内存占用和序列化开销。一个User对象在内存中可能占2KB，而两个字符串字段加起来不到100字节。在导出10万用户数据的后台任务里，用values_list()比用模型实例快3倍，内存峰值从1.2GB降到380MB。但要注意：values()返回的字典里，键名是字段名，不是数据库列名。如果你在模型里定义了verbose_name，它不影响values()的键名。另外，values()之后不能再调用模型方法，比如user.get_full_name()，因为返回的已不是模型实例。

3. 复杂关系查询：外键、多对多、反向查询的实战解法

3.1 外键正向查询：select_related()是JOIN的快捷方式

假设你有Post模型，外键关联User：

class Post(models.Model): author = models.ForeignKey(User, on_delete=models.CASCADE) title = models.CharField(max_length=200)

要显示文章列表，每行显示作者名，朴素写法是：

# ❌ N+1问题！循环中每次访问author.username都触发一次查询 posts = Post.objects.all() for post in posts: print(post.author.username) # 第1次查post，第2次查author，第3次...共n+1次

select_related()就是为解决这个而生。它告诉Django：“请用LEFT JOIN一次性把关联表数据捞回来”。

# ✅ 一条SQL搞定：SELECT post.*, user.* FROM post LEFT JOIN user ON post.author_id = user.id posts = Post.objects.select_related('author') for post in posts: print(post.author.username) # 不再触发额外查询

原理上，select_related()只支持外键（ForeignKey）和一对一（OneToOneField）正向关系，因为它依赖SQL的JOIN。它会在QuerySet的SQL生成阶段，自动拼接JOIN子句，并把关联表的字段加到SELECT列表里。Django在Python层解析结果时，直接把user.*字段填充到post.author对象中，避免了后续查询。

实操心得：select_related()可以链式使用，比如Post.objects.select_related('author__profile')，会生成两级JOIN。但要注意深度——每多一层JOIN，SQL复杂度指数级上升。我见过一个select_related('a__b__c__d__e')的查询，执行计划显示需要扫描百万行，最终被DBA强制下线。建议JOIN不超过2层，更复杂的用prefetch_related()或手动分步查询。

3.2 外键反向查询：_set不是魔法，是隐式定义的RelatedManager

Django为每个外键自动生成一个反向管理器，命名规则是小写模型名_set。比如User和Post的关系，User模型上会自动有post_set属性：

user = User.objects.get(id=1) # 获取该用户所有文章，返回Post QuerySet posts = user.post_set.all() # 等价于 Post.objects.filter(author=user)

这看起来像魔法，其实是Django在模型元数据里悄悄注册了一个RelatedManager。它的本质还是filter()，只是把author=user这个条件封装起来了。所以user.post_set.filter(title__startswith='Django')，生成的SQL就是SELECT ... FROM post WHERE post.author_id = 1 AND post.title LIKE 'Django%'。

但这里有个大坑：反向查询默认不走select_related。如果你在循环用户时，对每个用户都调用user.post_set.all()，又回到了N+1问题。正确做法是用prefetch_related()：

# ✅ 先查所有用户，再用IN查询所有相关文章，两条SQL搞定 users = User.objects.prefetch_related('post_set') for user in users: for post in user.post_set.all(): # 不触发新查询 print(post.title)

prefetch_related()的原理是：先执行SELECT * FROM auth_user，拿到所有用户ID；再执行SELECT * FROM post WHERE author_id IN (1,2,3,...)，把结果按author_id分组缓存；最后在Python层把文章列表挂到对应用户的post_set上。它用空间换时间，避免了N次网络往返，但内存占用会增加。

3.3 多对多查询：add()、remove()、clear()背后的数据行操作

多对多（ManyToManyField）在数据库层面由一张中间表实现。比如Article和Tag：

class Article(models.Model): tags = models.ManyToManyField(Tag)

Django自动生成中间表article_tag，包含article_id和tag_id两列。所有多对多操作，本质都是对这张中间表的INSERT/DELETE。

• article.tags.add(tag1, tag2)→ 向article_tag插入两行：(article.id, tag1.id)和(article.id, tag2.id)
• article.tags.remove(tag1)→ 从article_tag删除一行：WHERE article_id = ? AND tag_id = ?
• article.tags.clear()→ 删除article_tag中所有article_id = ?的行

关键点在于：add()和remove()不会触发article或tag主表的UPDATE，只操作中间表。所以它们极快，适合在事务中频繁调用。但clear()会删所有关联，如果中间表有百万行，DELETE FROM article_tag WHERE article_id = ?可能锁表几秒。这时可以用set()替代：

# ✅ set()先查现有ID，再计算差集，只删新增的，只增缺失的 article.tags.set([tag1, tag2, tag3])

set()的SQL流程是：

1. SELECT tag_id FROM article_tag WHERE article_id = ?（查当前关联）
2. 计算[tag1,tag2,tag3]与现有ID的差集
3. 对差集执行INSERT和DELETE

虽然多了一次查询，但避免了全量删除，更安全。

3.4prefetch_related()与select_related()的终极选择指南

我画了个决策树帮你快速判断：

1. 要查的是正向外键（如Post.author）？→ 用select_related
2. 要查的是反向外键（如User.post_set）或多对多（如Article.tags）？→ 用prefetch_related
3. 关系深度超过2层？→ 拆成多个prefetch_related，或用原生SQL
4. 数据量极大（>10万行）且内存敏感？→ 放弃prefetch_related，用values_list()手动关联

4. 性能生死线：only()、defer()、count()与exists()的精准手术刀

4.1only()和defer()：字段级懒加载，不是所有字段都值得加载

Django模型默认加载所有字段，哪怕你只用username。only()指定“只加载这些字段”，defer()指定“延迟加载这些字段”（即其他字段都加载，唯独这几个不加）。它们生成的SQLSELECT子句只包含指定字段，大幅减少网络传输和内存占用。

# ✅ 只查username和email，其他字段（如password_hash, last_login）不查 users = User.objects.only('username', 'email') # ✅ 加载所有字段，但password_hash留到真正访问时才查（触发额外SQL） users = User.objects.defer('password_hash')

实测数据：一个用户表有15个字段，其中bio是TextField（平均2KB），avatar是ImageField（路径字符串，但ORM会尝试生成URL）。用only('username', 'email')查询1000条，响应时间从850ms降到210ms，内存占用从480MB降到95MB。但defer()要慎用——当你在模板里写了{{ user.password_hash }}，Django会为每一行触发一次SELECT password_hash FROM auth_user WHERE id = ?，瞬间变回N+1。

注意：only()和defer()对select_related()和prefetch_related()无效。因为JOIN后的字段已经确定，无法再筛选。所以正确的组合是：Post.objects.select_related('author').only('title', 'author__username')，这样既JOIN了author，又只取author的username字段。

4.2count()vslen()：数据库计数器与Python列表长度的战争

QuerySet.count()执行SELECT COUNT(*) FROM ...，只返回一个数字，不加载任何数据行。len(QuerySet)则会先执行SELECT * FROM ...，把所有数据加载到内存，再用Python的len()函数数。在10万行数据的场景下，len()可能耗尽内存并超时，而count()毫秒级返回。

# ✅ 安全：SELECT COUNT(*) FROM auth_user WHERE is_active = true active_count = User.objects.filter(is_active=True).count() # ❌ 危险：SELECT * FROM auth_user WHERE is_active = true → 加载10万行到内存 active_users = User.objects.filter(is_active=True) active_count = len(active_users) # 内存爆炸！

但count()也有陷阱：它不支持distinct()在某些聚合场景。比如统计有多少个不同邮箱域名：

# ❌ 错误！count()不支持distinct()修饰 User.objects.values('email').distinct().count() # 报错 # ✅ 正确：用aggregate from django.db.models import Count domain_count = User.objects.aggregate(domain_count=Count('email', distinct=True))

4.3exists()：布尔判断的终极优化，比count()还轻量

当你只需要知道“有没有”，而不是“有多少”时，exists()是最快的。它生成SELECT (1) AS a FROM ... LIMIT 1，数据库找到第一行就停，不统计总数。

# ✅ 最快：找到第一行就返回True，不扫全表 if User.objects.filter(username='admin').exists(): print("Admin exists") # ⚠️ 次快：SELECT COUNT(*)，要扫全表或走索引统计 if User.objects.filter(username='admin').count() > 0: print("Admin exists")

在用户登录验证时，我坚持用exists()检查用户名是否存在，而不是get()或filter().first()。因为exists()的SQL执行计划永远是Index Only Scan（仅索引扫描），而get()会走Index Scan再回表取数据，慢一个数量级。

4.4update()和delete()：跳过模型层，直击数据库的原子操作

QuerySet.update()和QuerySet.delete()是ORM里少有的不实例化模型对象的操作。它们直接生成UPDATE ... SET或DELETE FROM ... WHERE语句，绕过Python层的所有信号（pre_save,post_save）、验证器、自定义save()方法。

# ✅ 原子更新：UPDATE auth_user SET is_active = false WHERE last_login < '2022-01-01' User.objects.filter(last_login__lt='2022-01-01').update(is_active=False) # ✅ 原子删除：DELETE FROM auth_user WHERE is_active = false User.objects.filter(is_active=False).delete()

优势是极致的性能和事务安全性。但风险在于：它不触发任何Django的生命周期钩子。如果你的User模型里有post_save信号监听用户状态变更，用update()就收不到。所以我的经验是：日常业务逻辑用model.save()，批量后台任务（如清理过期数据、状态迁移）用update()/delete()，并在任务日志里明确记录“本次操作绕过信号，请手动同步”。

5. 真实战场复盘：三个让我彻夜难眠的ORM性能事故

5.1 事故一：电商后台的“点赞排行榜”从200ms到3.2秒

场景：首页要显示“今日点赞数Top 10的商品”，商品模型Product，点赞记录在Like模型里，Like有product外键和created_at时间戳。

错误写法：

# ❌ 在视图里循环查，N+1地狱 products = Product.objects.all()[:10] for product in products: product.like_count = Like.objects.filter(product=product).count() # 每次都COUNT(*)

10个商品，10次COUNT(*)查询，数据库CPU飙升。更糟的是，Like表有千万行，COUNT(*)要扫全表。

修复方案：

# ✅ 用annotate聚合，一条SQL搞定 from django.db.models import Count products = Product.objects.annotate( like_count=Count('like', filter=Q(like__created_at__date=today)) ).order_by('-like_count')[:10]

生成的SQL是：

SELECT product.*, COUNT(like.id) AS like_count FROM product LEFT JOIN like ON product.id = like.product_id AND DATE(like.created_at) = '2023-10-01' GROUP BY product.id ORDER BY like_count DESC LIMIT 10

关键点：annotate()在SQL层做聚合，filter参数把WHERE条件下推到JOIN里，避免了子查询。性能从3.2秒降到180ms。但要注意：Count('like')默认是COUNT(like.id)，如果like表有NULL值，需加distinct=True。

5.2 事故二：CMS后台列表页加载JSON字段拖垮服务器

场景：Article模型有个metadata = JSONField()，存着SEO信息、自定义字段等，平均大小50KB。后台文章列表页只显示标题、作者、状态，但模板里不小心写了{{ article.metadata }}。

错误写法：

# ❌ 加载所有字段，包括50KB的JSON articles = Article.objects.all()

100篇文章，内存瞬间吃掉5GB，Gunicorn worker被OOM killer干掉。

修复方案：

# ✅ 用defer排除JSON字段 articles = Article.objects.defer('metadata') # 或更彻底，用only只取必要字段 articles = Article.objects.only('id', 'title', 'author__username', 'status')

但defer()有个坑：如果metadata字段在__str__()方法里被调用，还是会触发加载。所以最终方案是：在Article模型里重写__str__()，确保不访问metadata；列表页用only()；详情页再用select_related()加载完整数据。

5.3 事故三：实时看板的评论数统计，MySQL和PostgreSQL结果不一致

场景：文章详情页要显示“评论数”和“精选评论数”（is_featured=True）。Comment模型有article外键和is_featured布尔字段。

错误写法：

# ❌ 用两个annotate，但MySQL和PostgreSQL对COUNT DISTINCT处理不同 from django.db.models import Count, Q article = Article.objects.annotate( comment_count=Count('comment'), featured_count=Count('comment', filter=Q(comment__is_featured=True)) ).get(id=123)

问题出在Count('comment', filter=...)。PostgreSQL生成COUNT(CASE WHEN ... THEN comment.id END)，正确。MySQL 5.7生成COUNT(DISTINCT CASE WHEN ... THEN comment.id END)，而DISTINCT在CASE里行为异常，导致featured_count总是0或1。

修复方案：

# ✅ 改用Sum + Case，跨数据库兼容 from django.db.models import Sum, Case, When, IntegerField article = Article.objects.annotate( comment_count=Count('comment'), featured_count=Sum( Case( When(comment__is_featured=True, then=1), output_field=IntegerField() ) ) ).get(id=123)

生成的SQL在MySQL是SUM(CASE WHEN comment.is_featured = 1 THEN 1 ELSE 0 END)，在PostgreSQL同理，结果完全一致。这个教训是：ORM的高级聚合语法，未必在所有数据库后端表现一致。生产环境务必用connection.vendor做数据库适配，或回归到最基础的Sum/Count组合。

6. 终极避坑清单：那些文档里不会写的ORM暗礁

6.1bulk_create()的五个致命限制

bulk_create()用于批量插入，性能远超循环save()，但它有硬伤：

1. 不触发save()方法：自定义的save()逻辑（如生成slug、计算字段）全部失效。
2. 不触发信号：pre_save,post_save一个都不发。
3. 不返回主键（SQLite除外）：MySQL/PostgreSQL插入后无法获取自增ID，returning语法未被Django原生支持。
4. 不校验唯一约束：如果数据里有重复username，整个批次插入失败，错误信息模糊。
5. 有数量上限：MySQL默认max_allowed_packet=4MB，一次最多插几百条（取决于单条数据大小）。

我的解决方案：

• 插入前用Python校验唯一性（如User.objects.filter(username__in=usernames).exists()）
• 分批插入，每批100条
• 插入后，用User.objects.filter(username__in=usernames).values_list('id', 'username')反查ID
• 关键业务（如用户注册）仍用单条save()，保证信号和校验

6.2order_by()的空值陷阱：NULLS FIRST/LAST的数据库方言

order_by('-created_at')在PostgreSQL里，NULL值排在最前（因为-NULL最大），而在MySQL里排在最后。这会导致列表排序不一致。

修复：

# ✅ 显式指定NULL位置，Django 4.2+支持 from django.db.models import F articles = Article.objects.order_by( F('created_at').desc(nulls_last=True) ) # ✅ 兼容旧版，用extra() articles = Article.objects.extra( order_by=['-created_at'], tables=['article'], where=["created_at IS NOT NULL"] )

6.3distinct()的字段陷阱：它只对SELECT字段生效

QuerySet.distinct()去重，但它的依据是SELECT子句里的字段。如果SELECT *，就按所有字段去重；如果values('username')，就只按username去重。

# ❌ 本意是去重用户名，但SELECT * 导致每行都不同 User.objects.distinct() # 无意义，除非有重复行 # ✅ 正确：先values，再distinct User.objects.values('username').distinct() # SELECT DISTINCT username FROM auth_user

6.4transaction.atomic()里的ORM缓存：同一事务内多次查询返回相同结果

Django在事务内会对get()、filter().first()等查询结果做缓存，防止重复查询。但这也意味着，如果事务中A修改了数据，B再查，看到的仍是旧值（幻读）。

from django.db import transaction with transaction.atomic(): user = User.objects.get(id=1) # 缓存user对象 user.is_active = False user.save() # UPDATE # ❌ 这里查到的还是旧user，因为缓存没刷新 fresh_user = User.objects.get(id=1) # 返回缓存对象，is_active仍是True

修复：用refresh_from_db()强制重载：

fresh_user = User.objects.get(id=1) fresh_user.refresh_from_db() # 重新SELECT

6.5 日志调试：如何让Django把每条SQL都打到终端

开发时，把以下配置加到settings.py：

LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console': { 'level': 'DEBUG', 'class': 'logging.StreamHandler', }, }, 'loggers': { 'django.db.backends': { 'handlers': ['console'], 'level': 'DEBUG', 'propagate': False, }, } }

然后在Shell里：

from django.db import connection print(connection.queries) # 查看所有SQL

但注意：connection.queries只在DEBUG=True时生效，且每次请求后清空。生产环境禁用。

7. 我的ORM心法：从“会用”到“敢改”的三重境界

第一次写Django ORM，我像捧着一本《九阴真经》的少年，把filter()、get()、all()背得滚瓜烂熟，以为这就是全部。直到线上服务突然500，django.db.utils.OperationalError: (2006, 'MySQL server has gone away')，我才明白，ORM不是终点，而是你和数据库对话的翻译器。它的价值不在于屏蔽SQL，而在于让你用Python思维描述数据需求，再由它生成最合适的SQL。所以我的进阶路径是：

第一重：信
相信ORM能做好。用select_related代替N+1，用annotate代替循环计数，用bulk_create代替100次save()。这个阶段，你敬畏文档，把QuerySet当黑盒，专注业务逻辑。

第二重：疑
开始质疑每一条SQL。打开Django Debug Toolbar，盯着SELECT语句看：为什么这里没走索引？JOIN是不是太深？COUNT(*)能不能换成EXISTS？这个阶段，你常在manage.py dbshell里手写SQL对比执行计划，EXPLAIN ANALYZE成了口头禅。

第三重：破
敢于打破ORM。当prefetch_related生成的IN查询超过5000个ID，我直接写原生SQL，用psycopg2.extras.execute_batch批量插入；当JSONField的嵌套查询太慢，我加数据库函数索引；当ORM的DateTimeField时区处理混乱，我改用BigIntegerField存时间戳。这个阶段，你不再问“Django怎么实现”，而是问“这个问题，数据库原生怎么解最优雅”。

最后分享一个小技巧：在models.py里，给每个模型加一个debug_sql()类方法：

class User(models.Model): # ... fields ... @classmethod def debug_sql(cls, qs): """打印QuerySet的SQL和执行时间""" from django.db import connection import time start = time.time() list(qs) # 强制求值 end = time.time() print(f"SQL: {connection.queries[-1]['sql']}") print(f"Time: {(end-start)*1000:.2f}ms") return qs

调用User.debug_sql(User.objects.filter(is_active=True))，立刻看到真实世界的数据脉搏。ORM不是牢笼，是你指尖跃动的SQL指挥棒。真正的自由，不是不用它，而是用得足够透彻，以至于忘了它的存在。