COUNT() OVER() 在海量数据下会引发全表扫描和内存溢出，因其隐式要求全局排序或维护完整窗口状态，远慢于普通 COUNT()。
COUNT(*) OVER() 在海量数据下不是慢，是直接拒绝服务——它强制全表扫描+全局排序，内存打满就OOM。
为什么 COUNT(*) OVER() 会触发全局排序
SQL Server 和 PostgreSQL 都把空 OVER() 当作隐式 OVER (ORDER BY (SELECT NULL)) 处理，即要求对整个结果集赋予确定顺序。哪怕你只 SELECT 两列，数据库也必须先把所有行读出来、排一遍序、再编号。MySQL 8.0 虽不强制排序，但 COUNT(*) OVER() 仍需维护完整窗口状态，无法流式计算。
- 执行计划里看到
Sort或WindowAgg节点在最外层，且没有 Index Scan 支撑 → 已中招 - PostgreSQL 中
EXPLAIN (ANALYZE)显示Sort Method: external merge Disk→ 内存已溢出到磁盘 - SQL Server 的
STATISTICS IO显示大量worktable读写 → 正在用 tempdb 抗压
COUNT(*) OVER() 和 COUNT(*) 的语义差异必须分清
很多人以为加个 OVER() 只是“顺便算个总数”，其实它改变了整个执行模型：COUNT(*) 是聚合，走索引或元数据（如 MyISAM）可 O(1) 返回；COUNT(*) OVER() 是窗口函数，必须和每一行绑定，产生 N 行输出，每行都带同一个总数——这等于把整张表复制 N 次再计数。
-
COUNT(*)：统计结果集总行数，可被优化器提前剪枝 -
COUNT(*) OVER()：为每一行附加一个“当前窗口总行数”，窗口默认是UNBOUNDED PRECEDING TO UNBOUNDED FOLLOWING，即全集 - 真正需要的往往不是“每行都带总数”，而是“查完后额外返回总数”，这时该用
UNION ALL或应用层两次查询
替代方案：不硬扛，就快十倍
别让数据库一边查数据一边算总数。把“查数据”和“算总数”拆开，既准又快。
- 如果前端需要分页 + 总数：先
SELECT COUNT(*) FROM t WHERE ...拿总数，再SELECT * FROM t WHERE ... ORDER BY id LIMIT 100 OFFSET 0查数据——两个独立查询，都能走索引 - 如果必须单次返回（如 ORM 封装）：用
UNION ALL合并，避免窗口开销SELECT id, name, 'data' AS type FROM t WHERE status = 1<br>UNION ALL<br>SELECT COUNT(*), NULL, 'count' FROM t WHERE status = 1
- 如果业务允许近似值：PostgreSQL 可用
pg_class.reltuples查估算行数，SQL Server 可查sys.dm_db_partition_stats的row_count字段，毫秒级返回
真要保留 OVER 写法？那就严格约束窗口范围
空 OVER() 是自毁行为。哪怕只是加个 PARTITION BY，也能让优化器放弃全局排序。
- 错误写法：
COUNT(*) OVER()→ 全局窗口，必扫全表 - 可用写法：
COUNT(*) OVER (PARTITION BY status)→ 按 status 分组计数，只要status有索引，就能分段处理 - 更优写法：
COUNT(*) OVER (PARTITION BY DATE(created_at) ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)→ 加ROWS限定帧，避免累积状态爆炸 - 索引必须匹配：
CREATE INDEX idx_status_date ON t(status, created_at)，否则PARTITION BY + ORDER BY仍会触发排序
真正卡住的从来不是语法，而是没想清楚“这个总数到底给谁用、什么时候用、准不准”。硬塞 COUNT(*) OVER() 到千万级查询里，相当于要求快递员送一份文件的同时，把全国所有快递单号背下来——他不是不想送，是根本背不完。
