COUNT(*) OVER(PARTITION BY user_id) 可为每行保留原始行数并统计用户关联记录总数，区别于GROUP BY；需避免漏写PARTITION BY、误用COUNT(col)跳过NULL，且开窗函数执行早于外层ORDER BY。
COUNT(*) OVER(PARTITION BY) 怎么写才不丢行
直接用 COUNT(*) OVER(PARTITION BY user_id) 就能为每行主表数据附上「该用户关联的从表记录总数」，且完全保留原始行数——这是它和 GROUP BY 最本质的区别。你不需要把所有字段塞进 GROUP BY，也不用担心 SELECT * 报错。
常见错误是漏掉 PARTITION BY 或写成 COUNT(col) 却没意识到它会跳过 NULL 值：
-
COUNT(*)统计分区内的所有行（含 NULL） -
COUNT(order_id)只统计order_id非 NULL 的行——如果关联用的是 LEFT JOIN，且某用户无订单，order_id为 NULL，那这行会被忽略，结果变成 0（这反而是你想要的，但得明确意图） - 别写
COUNT() OVER(PARTITION BY ...)—— 缺参数会报错
LEFT JOIN + COUNT OVER 和子查询哪个更快
在百万级订单表里查每个用户的订单数，COUNT(*) OVER(PARTITION BY customer_id) 通常比 (SELECT COUNT(*) FROM orders o2 WHERE o2.customer_id = u.id) 快 3–5 倍。执行计划里前者是一次全扫描 + 分区哈希聚合，后者是 N 次独立子查询，I/O 和 CPU 开销都高得多。
但要注意前提：从表必须提前过滤好。比如只统计「已支付订单」，不能靠主表 WHERE 带动，而要先用 CTE 或子查询筛出 paid_orders，再做 OVER：
WITH paid_orders AS ( SELECT customer_id FROM orders WHERE status = 'paid' ) SELECT u.id, u.name, COUNT(po.customer_id) OVER(PARTITION BY u.id) AS paid_cnt FROM users u LEFT JOIN paid_orders po ON u.id = po.customer_id;
这里用 COUNT(po.customer_id) 而非 COUNT(*)，是因为 LEFT JOIN 后没订单的用户对应 po.customer_id 是 NULL，COUNT() 自动跳过，结果为 0，语义准确。
统计占比时分母怎么取才不翻车
想算「每个订单状态占总订单数的百分比」，不能写 COUNT(*) / (SELECT COUNT(*) FROM orders)——子查询多扫一遍表，还容易在嵌套复杂时失效。正确姿势是用 COUNT(*) OVER() 作为分母：
SELECT status, COUNT(*) AS cnt,
ROUND(COUNT(*) * 100.0 / COUNT(*) OVER(), 2) AS pct
FROM orders
GROUP BY status;关键点：
-
COUNT(*) OVER()不带PARTITION BY，就是整张表总行数，稳定可靠 -
* 100.0强制转浮点，避免 MySQL/PostgreSQL 整除截断（5/10得0而不是0.5） - 如果要排除 NULL 状态再算占比，得改用
SUM(CASE WHEN status IS NOT NULL THEN 1 ELSE 0 END) OVER()，因为COUNT(*)本身无法跳过 NULL 行
ORDER BY 放在 OVER 里会发生什么
COUNT(*) OVER(PARTITION BY user_id ORDER BY create_time) 不是「按时间分组后计数」，而是「按时间排序后，从分区第一行累加到当前行」——也就是累积计数。你要的是每个用户的总订单数，就别加 ORDER BY；加了反而变慢，还容易误解结果。
只有当你真需要「截至当前时间的累计订单数」时才加 ORDER BY，比如看用户成长路径。但注意：ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是默认框架，显式写出更稳妥，避免不同数据库默认行为差异。
真正容易被忽略的是：开窗函数在 SQL 执行顺序中晚于 WHERE 和 JOIN，早于 ORDER BY。这意味着你不能靠外层 ORDER BY 控制 OVER 内部的计算顺序——必须在 OVER 子句里明确写。
