percent_rank()返回0–1区间相对排名，ntile()实现等频分桶；二者均为窗口函数，比手写子查询更高效可靠，但percent_rank()非真实分位数值，需配合过滤获取；ntile(100)仅近似百分位序号。
用 PERCENT_RANK() 或 NTILE() 替代手写子查询算分位数
直接写子查询求中位数或 95 分位数，不仅慢还难维护。现代 SQL 引擎（PostgreSQL、SQL Server、Oracle、Spark SQL）都内置了窗口函数，PERCENT_RANK() 返回 [0,1) 区间内的相对排名，NTILE(100) 则把结果集等分为 100 桶——这两者比嵌套 SELECT + COUNT + 自连接靠谱得多。
常见错误是误以为 PERCENT_RANK() 的结果可以直接当“第 p 百分位数值”用；它只是排序位置的归一化，要取值还得配合 ORDER BY 和外层过滤：
SELECT value FROM ( SELECT value, PERCENT_RANK() OVER (ORDER BY value) AS pr FROM metrics ) t WHERE pr >= 0.95 ORDER BY pr LIMIT 1;
-
PERCENT_RANK()对重复值返回相同排名，但会跳过后续序号（比如两个并列第 2 名，下一个就是第 4 名），而CUME_DIST()不跳号，更适合严格分位定义 -
NTILE(4)保证分成 4 组，但每组行数可能差 1；若需严格按比例切分（如 top 5%），必须用PERCENT_RANK()或CUME_DIST() - MySQL 8.0+ 支持这些窗口函数；5.7 及更早版本不支持，强行用子查询模拟会触发全表扫描 + 多次聚合，性能断崖式下跌
数据倾斜时子查询容易被优化器误判执行计划
当主表某 key（如 user_id = 'unknown'）占 60% 行数，而你在子查询里对这个 key 做 COUNT(*) 或 AVG()，优化器可能基于统计信息误估为“均匀分布”，导致分配给该 task 的内存不足，出现 Query exceeded memory limit（Trino/Spark）或 temp file size exceeded（PostgreSQL）。
解决思路不是压低子查询复杂度，而是提前打散倾斜 key：
SELECT
CASE WHEN user_id = 'unknown' THEN CONCAT('unknown_', FLOOR(RAND() * 100))
ELSE user_id END AS stable_user_id,
AVG(duration)
FROM logs
GROUP BY stable_user_id;
- 子查询本身不解决倾斜；真正起作用的是在 JOIN 或 GROUP BY 前对倾斜 key 加盐（salting）
- 若子查询用于
WHERE x IN (SELECT y FROM ...)，且子查询结果很大，数据库可能转为 hash semi-join；此时若子查询结果倾斜（比如 90% 是同一个y），hash 表构建阶段就会卡住 - 替代方案：用
EXISTS代替IN，或把子查询物化为临时表并手动加索引
用相关子查询做逐行分位判断时小心 N² 复杂度
有人写这种逻辑来标出“是否高于中位数”：
SELECT id, value, (SELECT COUNT(*) FROM t t2 WHERE t2.value <p>这看着像分位数，实际是 O(N²)：对每一行都扫一遍全表。10 万行就接近 100 亿次比较，生产环境基本不可行。</p>
- 正确做法是先用窗口函数算好所有
CUME_DIST()，再 JOIN 回原表——一次排序，两次线性扫描 - 如果必须用子查询（比如老版本 MySQL），至少把分母
(SELECT COUNT(*) FROM t)提到外层变量或 WITH 子句，避免重复执行 - 某些引擎（如 Hive）会对这种相关子查询自动重写为 map-side join，但前提是子查询结果能塞进内存；超限时降级为 reduce-side join，反而更慢
分位数 + 倾斜处理组合场景：监控告警中的 P99 延迟与异常用户隔离
真实需求常是：计算整体 P99 延迟，并单独列出延迟超过 P99 的用户中，那些请求量又占前 10% 的“坏用户”。这里既要分位数，又要防倾斜（坏用户可能只有几个，但每个发几万请求）。
关键不是堆子查询，而是分步物化 + 控制中间集大小：
WITH p99_global AS ( SELECT APPROX_PERCENTILE(duration, 0.99) AS p99_val FROM logs ), bad_users AS ( SELECT user_id, COUNT(*) AS cnt FROM logs WHERE duration > (SELECT p99_val FROM p99_global) GROUP BY user_id HAVING COUNT(*) > 100 -- 先粗筛，防倾斜 ), top_bad AS ( SELECT user_id FROM bad_users ORDER BY cnt DESC LIMIT 100 -- 再限数量，确保后续 JOIN 不爆炸 ) SELECT l.* FROM logs l JOIN top_bad t ON l.user_id = t.user_id WHERE l.duration > (SELECT p99_val FROM p99_global);
-
APPROX_PERCENTILE()（Trino/Spark）或PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY duration)（PostgreSQL）比精确算法快一个数量级，误差可接受 - 中间结果加
HAVING和LIMIT不是可选优化，是防止bad_users输出几千行后，跟原表 JOIN 直接拖垮 shuffle 阶段 - 子查询只在
WHERE中出现一次时，多数引擎会自动缓存其结果；但如果在多个地方引用（如 SELECT + WHERE），显式用 CTE 更可控
分位数本身不难，难的是在倾斜数据上让整个链路不崩——窗口函数优先，子查询仅作兜底；任何中间结果都要有数量预期，没限制的 GROUP BY 就是定时炸弹。
