MySQL 8.0.13+ 应优先使用 PERCENTILE_CONT(0.5) OVER (PARTITION BY group_id ORDER BY value)，需配合 (group_id, value) 联合索引以避免全表排序，禁用 PostgreSQL 风格的聚合写法。
MySQL 8.0+ 直接用 PERCENTILE_CONT 最省事
如果你用的是 MySQL 8.0.13 及以上版本，PERCENTILE_CONT(0.5) 是官方支持的中位数计算函数，它基于窗口排序但不强制全表扫描——只要分组字段有索引，优化器会为每个分组单独做局部排序，避免全局 ORDER BY。注意它必须配合 OVER (PARTITION BY ... ORDER BY ...) 使用，且 ORDER BY 的列最好也是索引前缀列。
常见错误是写成 SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) FROM t GROUP BY group_id —— 这是 PostgreSQL/SQL Server 写法，在 MySQL 里会报错 FUNCTION xxx.PERCENTILE_CONT does not exist。
- 正确写法：
SELECT DISTINCT group_id, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) OVER (PARTITION BY group_id) AS median FROM t - 性能关键：确保
(group_id, value)有联合索引，否则仍可能触发临时文件排序 - 返回值类型和
value列一致，但如果是整数列而中位数落在两个数之间（偶数个），结果会是精确小数，不会自动取整
PostgreSQL 用 PERCENTILE_CONT 或 percentile_disc 区分连续/离散中位数
PostgreSQL 同时提供两个函数：PERCENTILE_CONT(0.5) 返回插值结果（如 [1,3] → 2.0），PERCENTILE_DISC(0.5) 返回实际存在的值（如 [1,3] → 1，取下中位数）。两者都走窗口路径，只要 PARTITION BY 字段有索引，就不会全表排序。
容易踩的坑是误用聚合形式：直接写 SELECT group_id, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) FROM t GROUP BY group_id 看似简洁，但它会先对全表按 value 排序再分组，数据量大时 I/O 和内存压力陡增。
- 推荐写法：
SELECT group_id, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) FILTER (WHERE group_id = 'x') OVER ()—— 不，这也不对；正确姿势是用窗口函数 + 去重：SELECT DISTINCT group_id, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) OVER (PARTITION BY group_id) FROM t - 若只查某几个
group_id，务必加WHERE group_id IN (...)提前过滤，否则窗口仍会加载所有分组数据 -
PERCENTILE_DISC在偶数长度时返回排序后第FLOOR((n+1)/2)个值，行为更稳定，适合需要返回真实样本的场景
通用方案：用变量模拟行号避开全表排序（MySQL 5.7 / 旧版）
在不支持窗口函数的老版本中，靠子查询加 JOIN 或 ORDER BY ... LIMIT 都难逃全表排序。真正能规避的是用用户变量逐组计数，前提是数据已按 group_id, value 排好序——所以必须建联合索引 INDEX(group_id, value)，让 MySQL 能用索引顺序扫描，跳过 Using filesort。
典型错误是变量初始化位置不对：在 SELECT 里同时赋值和引用，导致不同 MySQL 版本行为不一致（5.7 允许，8.0 默认禁用）。安全做法是用派生表先排序，再在外层用变量标序号。
- 关键步骤：先
SELECT group_id, value FROM t FORCE INDEX (idx_group_value) ORDER BY group_id, value，再套一层用@rn := IF(@prev = group_id, @rn + 1, 1)计数 - 中位数逻辑：对每组，取
rn = FLOOR((cnt+1)/2)和rn = CEILING((cnt+1)/2)两行，再平均（偶数）或取其一（奇数） - 隐患：变量执行顺序无严格保证，高并发下可能错乱；生产环境建议加
SELECT ... FOR UPDATE或改用临时表分步处理
为什么不能用 LIMIT OFFSET 分页取中间值？
很多人想“每组先算总数，再用 LIMIT 1 OFFSET n 取中间那个”，但问题在于：OFFSET 必须在排序后生效，而排序若没索引支撑，就是全表 ORDER BY。即使加了 WHERE group_id = ?，如果 value 没索引，MySQL 仍要扫描该组所有行再排序，无法利用索引定位第 k 小值。
更隐蔽的问题是：当某组数据量极大（比如百万级），LIMIT 1 OFFSET 500000 会让 MySQL 内部仍遍历前 500000 行，只是不返回——CPU 和磁盘 I/O 并未节省。
- 替代思路：用
WHERE value >= (SELECT value FROM t WHERE group_id = ? ORDER BY value LIMIT 1 OFFSET n)依然无效，子查询还是得排序 - 真正可行的是结合索引范围扫描 + 二分逼近，但实现复杂，且仅适用于单组中位数；分组场景下不如老老实实建
(group_id, value)索引 + 窗口函数 - 记住：中位数本质是排序后的位置统计，任何绕过排序的近似方法（如采样、t-digest）都不满足“精确中位数”需求
中位数不是聚合函数，它强依赖有序性。所谓“避免全表排序”，核心就一条：让数据库能在分组内用索引顺序扫描，而不是把所有数据捞出来再排。索引设计比函数选型更重要，而变量方案看着巧，实则脆弱——线上环境优先升级到支持窗口函数的版本，再配好联合索引。
