annotate(Count()) 比 Python 循环查库快，因数据库原生聚合在服务端完成，仅返回数字；循环则需加载全部数据到内存计数，IO 与内存开销巨大。
为什么 annotate(Count()) 比循环查库快得多
因为数据库原生聚合（如 COUNT()）在服务端完成，只返回最终数字；而 Python 循环查库会把全部记录拉到内存再计数，IO 和内存开销爆炸。100 万行数据做分组统计时，annotate 可能 200ms 完成，Python 循环 + len() 轻松吃光 2GB 内存并卡死。
关键前提是：你要统计的字段必须已建索引（尤其是 GROUP BY 字段），否则数据库自己也会慢——annotate 不解决索引缺失问题。
-
annotate是 QuerySet 方法，不触发查询，直到你遍历或调用list()/first()等才执行 SQL - 它生成的是标准 SQL
SELECT ..., COUNT(*) FROM ... GROUP BY ...，不是 Django 自己算的 - 如果漏写
values()或values_list()，Django 默认按模型主键分组，结果常被误认为“没生效”
怎么写才不出错：values()、annotate()、Count() 的顺序和位置
三者顺序不能乱：先 values()（决定 GROUP BY 字段），再 annotate()（决定 SELECT 中的聚合列）。颠倒或遗漏 values()，Django 就按整行（含所有字段）分组，结果条目远多于预期，甚至和没分组一样。
常见错误写法：MyModel.objects.annotate(c=Count('status')).values('status') → 这里 values() 在后，Django 先按全字段分组再取 status，c 值全是 1。
立即学习“Python免费学习笔记（深入）”；
- 正确写法：
MyModel.objects.values('status').annotate(c=Count('id')) - 想统计空值？用
Count('field', filter=Q(field__isnull=True))，避免Count('field')自动跳过 NULL - 要同时查多个聚合？
annotate(c1=Count('x'), c2=Count('y', distinct=True))，注意distinct=True对性能影响大，慎用
Count 的 distinct 参数到底什么时候该开
Count('category_id') 默认统计非 NULL 的 category_id 出现次数；加 distinct=True 才是统计「有多少个不同的 category_id」——这是两个完全不同的业务含义。
典型踩坑场景：订单表关联用户表，想查「每个用户下了几单」，写成 Order.objects.values('user_id').annotate(c=Count('user_id', distinct=True))，结果全变成 1。因为每组里 user_id 都一样，去重后当然只剩一个。
- 统计「数量」→ 用
Count('id')或Count('*')（推荐Count('id')，语义清晰） - 统计「去重后的取值个数」→ 如「用户覆盖了多少个省份」，才用
Count('province', distinct=True) -
distinct=True会让 SQL 加COUNT(DISTINCT province)，MySQL 8.0+ 支持较好，但旧版可能强制临时表，速度骤降
超大数据量下，annotate 还慢？试试这些硬招
当表行数超 5000 万，即使加了索引，annotate 仍可能秒级延迟——这不是 Django 的锅，是数据库 GROUP BY 本身成本高。这时候得绕开实时聚合。
- 用数据库物化视图（PostgreSQL）或汇总表（MySQL），每天凌晨跑一次
INSERT INTO daily_stats SELECT ... GROUP BY ...，查时直接读小表 - Django 层加缓存：对固定维度（如「按月统计销量」）用
cache.set('sales_by_month_202406', data, 3600)，失效时间设为业务可接受的滞后窗口 - 真要实时且海量？放弃精确值，改用 HyperLogLog（Redis）或采样估算，比如
Count('id') * 100 / sample_ratio，误差可控在 ±5%
别迷信 annotate 能解决一切统计问题。它高效的前提是数据能进内存排序、有合适索引、分组维度不过于发散。维度太多（比如按 10 个字段组合分组）或数据太老（历史冷数据未分区），就得换思路。
