PostgreSQL 9.4+ 支持单次扫描多列百分位数，前提是所有 percentile_cont 共享相同 ORDER BY 和窗口定义；MySQL 需多次排序；ClickHouse 的 quantiles 函数可真单扫，但精度和插值有限制。
PostgreSQL 的 percentile_cont 支持单次扫描多列百分位数
PostgreSQL 9.4+ 允许在同一个 SELECT 中对不同列调用多次 percentile_cont，只要它们共享相同的 GROUP BY 或窗口定义，查询引擎会复用排序结果，避免重复扫描。这是目前最接近“单次扫描”的标准方案。
关键点是：所有 percentile_cont 调用必须作用于同一 ORDER BY 子句（即使列不同），且不能混用不同排序方向或不同窗口帧；否则优化器可能退化为多次排序。
-
percentile_cont(0.5) WITHIN GROUP (ORDER BY sales_amount)和percentile_cont(0.9) WITHIN GROUP (ORDER BY profit_margin)无法共用扫描——列不同、排序依据不同，会触发两次独立排序 - 正确写法是统一排序依据：比如都按
sales_amount排，再分别求profit_margin在该顺序下的中位数（即percentile_cont(0.5) WITHIN GROUP (ORDER BY sales_amount)返回的是对应位置的profit_margin值，不是其自身分布的中位数） - 若真要各自列的独立百分位数（如
sales_amount的 P50 和profit_margin的 P90），PostgreSQL 仍需两次排序，但可通过 CTE 预先排序一次再引用，减少 I/O 开销
MySQL 8.0+ 必须用窗口函数模拟，无法真正单扫
MySQL 没有 percentile_cont，只能靠 ROW_NUMBER() + COUNT() 手动插值，而每个目标列都需要独立编号和计数，本质上仍是逻辑上多次遍历。
常见错误是试图在一个子查询里同时算两列的序号：
SELECT
AVG(CASE WHEN rn_sales = mid THEN sales_amount END) AS p50_sales,
AVG(CASE WHEN rn_margin = mid THEN profit_margin END) AS p50_margin
FROM (
SELECT
sales_amount,
profit_margin,
ROW_NUMBER() OVER (ORDER BY sales_amount) AS rn_sales,
ROW_NUMBER() OVER (ORDER BY profit_margin) AS rn_margin,
(COUNT(*) OVER () + 1) / 2 AS mid
FROM orders
) t;这段 SQL 看似“一次查”，但 MySQL 会为每个 OVER 子句执行一次全表排序，实际执行计划里出现多个 filesort。性能比显式两个子查询还差，因为无法并行利用索引。
- 若已有
(sales_amount)和(profit_margin)单列索引，分开查反而更快 - 想压测真实开销？用
EXPLAIN FORMAT=TREE看是否出现多个Sort节点
ClickHouse 的 quantiles 函数家族是少数真单扫方案
ClickHouse 的 quantiles(0.5, 0.9)(sales_amount) 和 quantiles(0.5, 0.9)(profit_margin) 可以合并在一个聚合中，底层使用 T-Digest 或 QDigest 合并流式摘要，仅扫描数据一次。
注意它返回的是数组，需展开：
SELECT quantiles(0.5, 0.9)(sales_amount) AS sales_q, quantiles(0.5, 0.9)(profit_margin) AS margin_q FROM orders; <p>-- 结果：[1200.0, 5600.0], [0.12, 0.38]
- 精度可控：默认误差约 0.1%，加参数如
quantilesTiming(0.01)(x)可缩窄到 1% 误差 - 不支持插值，只返回观测值（
quantile）或近似值（quantiles），对严格要求线性插值的场景不适用 - 内存占用随分位点数量线性增长，100 个分位点可能吃掉几 MB 内存，别在高基维分组里滥用
通用规避策略：预计算 + 物化视图
当业务允许一定延迟（比如 T+1），比硬拼单次扫描更可靠的做法是把多列百分位数拆成异步任务预计算，再用物化视图或定时表合并。
- PostgreSQL：用
REFRESH MATERIALIZED VIEW CONCURRENTLY更新含各列percentile_cont的视图 - MySQL：用事件调度器每天跑存储过程，写入汇总表，查询走覆盖索引
- 关键是把“扫描成本”从在线查询转移到后台，避免用户等待时长波动
真正难的不是语法怎么写，而是想清楚：你要的是“物理单次读盘”，还是“用户感知一次响应”——后者往往用缓存或预计算更稳。磁盘 IO 真省不下来的时候，就别强求一条 SQL 解决所有问题。
