COUNT() OVER(PARTITION BY customer_id)可替代LEFT JOIN汇总表，一次扫描即为每行附带分组统计数，不改行数、不增连接路径；需确保PARTITION BY字段有索引，且注意COUNT()与COUNT(非空字段)在LEFT JOIN中对NULL的不同处理。
COUNT(*) OVER(PARTITION BY) 替代 LEFT JOIN 汇总表
当你需要给明细行附带“所属分组的统计总数”时，比如每个订单行显示“该客户总共下了多少单”，传统写法是 LEFT JOIN 一张按 customer_id 聚合的子查询表。这会导致优化器可能执行多次扫描或生成临时表。改用 COUNT(*) OVER (PARTITION BY customer_id) 后，数据库只需一次扫描、一次分组计数，每行直接拿到结果。
关键点在于：窗口函数不改变行数，也不引入新连接路径；而 LEFT JOIN 汇总表会强制构造中间结果集，尤其当汇总逻辑复杂（含 WHERE 过滤或去重）时，性能差距更明显。
- 必须确保
PARTITION BY字段有索引，否则排序开销大——例如(customer_id)单列索引就足够支撑计数类窗口 - 如果汇总逻辑含条件（如“只统计近30天订单数”），别在
OVER里硬加WHERE，而是先用 CTE 或子查询过滤数据，再套窗口 -
COUNT(col)和COUNT(*)行为不同：COUNT(customer_id)会跳过NULL值，COUNT(*)统计所有行；LEFT JOIN 场景下常需后者语义
避免 COUNT(*) OVER() 全局计数引发隐式排序
想在每行加一个“全表总行数”字段？别直接写 COUNT(*) OVER()。PostgreSQL 和 SQL Server 会为此触发全局排序（即使你没写 ORDER BY），尤其在无索引大表上极慢。MySQL 8.0 虽不排序，但语义上仍需遍历全表。
更稳的做法是拆成两步：先 SELECT COUNT(*) FROM t 得到总数，再用 CROSS JOIN 或变量注入。虽然多一次 round-trip，但可控、可缓存、不拖慢主查询排序路径。
- 如果必须单条 SQL 完成，可用 CTE 预算总数：
WITH total AS (SELECT COUNT(*) AS cnt FROM t) SELECT *, total.cnt FROM t, total -
COUNT(*) OVER()在执行计划里常表现为WindowAgg+Sort，而CROSS JOIN是Nested Loop或Hash Join，后者对小结果集更轻量 - BI 工具或 ORM 自动拼 SQL 时容易误用空
OVER()，建议在代码审查中把OVER()列为敏感模式
LEFT JOIN 后 COUNT(*) OVER 的 NULL 处理陷阱
用 LEFT JOIN 关联后接 COUNT(*) OVER (PARTITION BY u.id)，看似能统计每个用户订单数，但若关联失败（即右表为 NULL），COUNT(*) 仍会计入左表行——这是正确行为。但如果你写的是 COUNT(order_id) OVER (PARTITION BY u.id)，那 NULL 就被跳过了，结果为 0，符合业务预期。
这个细节决定了你是否真需要“存在性统计”还是“实际值统计”。很多报表卡在这里：前端看到用户行数对，但订单计数全为 0，其实是用了 COUNT(*) 却期望它忽略 NULL。
- LEFT JOIN 场景下，优先用
COUNT(非空字段)，比如COUNT(o.id)或COUNT(o.order_no) - 别依赖
COUNT(*)在 LEFT JOIN 中自动适配语义；它的行为始终是“统计当前窗口内所有行”，不管这些行来自哪张表 - 测试时务必用含 0 订单的用户数据验证，不能只看有订单的 case
多个 COUNT OVER 混用时的排序复用问题
一个查询里同时用 COUNT(*) OVER (PARTITION BY a) 和 COUNT(*) OVER (PARTITION BY b)，PostgreSQL 会分别排序两次——即使 a 和 b 都有索引。SQL Server 也类似。这不是 bug，是窗口函数实现机制决定的：每个 OVER 子句独立定义计算上下文。
当 a 和 b 高度相关（比如 b 是 a 的子集），可以考虑降维：先按 a 分组聚合出中间结果，再对中间结果按 b 窗口计算。虽然多一层 CTE，但避免了重复排序。
- 检查执行计划里
Sort节点数量，一个COUNT OVER对应一个Sort是常态，但两个不同PARTITION BY出现三次Sort就说明优化器没复用 - MySQL 8.0 对相同
ORDER BY的多个窗口会尝试复用排序，但PARTITION BY不同基本不复用 - 真正难优化的是
PARTITION BY a ORDER BY ts和PARTITION BY b ORDER BY ts并存——ts 索引无法同时服务两组分区，此时必须权衡是否拆查询
COUNT(*) OVER 当作“无副作用的语法糖”。它不产生连接，但会悄悄绑定排序资源；不增加行数，但可能让原本能走索引扫描的查询被迫落盘排序。 
