PERCENTILE_CONT 是计算动态 IQR 阈值的首选：按 PARTITION BY 分组分别求 q1/q3，插值结果稳定，需用 CTE 先聚合再关联过滤，务必排除 NULL、零值及无效重复数据，并限制最小样本量（如 HAVING COUNT(*) >= 5）。
用 PERCENTILE_CONT 算每组动态 IQR 阈值
硬编码 3σ 或固定上下限（比如 amount > 10000）在分组场景下基本失效——不同用户、类目、时段的业务量级差异太大。必须让阈值随组变化，PERCENTILE_CONT 是最直接的选择：它能按 PARTITION BY group_col 分别计算 25% 和 75% 分位点，再推导出 IQR（四分位距）和异常边界。
关键点：
-
PERCENTILE_CONT(0.25) OVER (PARTITION BY user_id ORDER BY amount)必须带ORDER BY，否则语法报错；MySQL 8.0+ 支持，但旧版需用窗口模拟或子查询加变量 - 返回的是插值结果（比如第 25% 位落在 42 和 45 之间，可能得 43.6），比
PERCENTILE_DISC更稳定，避免因数据稀疏导致阈值跳变 - 别直接用
WHERE amount > q3 + 1.5 * iqr—— 这种写法无法在单层查询中完成，必须先用 CTE 或子查询把分位数算出来，再 JOIN 或 WHERE 关联原表
CTE 先算分位基准，再关联原表过滤
想保留原始行（如订单 ID、时间戳、用户邮箱），就不能只靠 HAVING；而 PERCENTILE_CONT 是窗口函数，不能直接进 GROUP BY 聚合逻辑。所以标准解法是 CTE 先产出每组的 q1、q3、iqr，再和原表 JOIN 或用 EXISTS 标记异常行。
示例结构：
WITH group_stats AS (
SELECT
user_id,
PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY amount) AS q1,
PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY amount) AS q3,
PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY amount)
- PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY amount) AS iqr
FROM orders
WHERE amount IS NOT NULL AND amount > 0
GROUP BY user_id
HAVING COUNT(*) >= 5
)
SELECT o.*
FROM orders o
JOIN group_stats g ON o.user_id = g.user_id
WHERE o.amount > g.q3 + 1.5 * g.iqr;
注意：GROUP BY 后的 HAVING COUNT(*) >= 5 是硬性保护，组内样本太少时 IQR 容易失真；WHERE amount IS NOT NULL AND amount > 0 必须放在 CTE 内部，否则污染分位计算。
避免 NULL 和重复值干扰分位结果
PERCENTILE_CONT 对 NULL 值静默忽略，但若字段存在大量重复值（如电商订单里大量 amount = 0 的测试单），会导致分位点被“压扁”——比如 90% 的数据都是 0，那 q3 可能还是 0，异常边界就崩了。
实操建议：
- 在 CTE 的
WHERE子句里提前排除已知无效值：amount NOT IN (0, -1)、status = 'success' - 检查重复率：
COUNT(*) / COUNT(DISTINCT amount)> 5 就要警惕，考虑改用PERCENT_RANK()辅助验证偏离度 - 不要依赖
COALESCE(amount, 0)填充 NULL——这会把缺失真实业务值的记录强行拉进分位计算，扭曲结果
MySQL 5.7 或不支持窗口函数时的降级方案
如果数据库是 MySQL 5.7 或更老版本，PERCENTILE_CONT 和窗口函数全不可用，就得用自连接或变量模拟。但要注意：变量方式在高并发或非确定排序下不稳定，生产环境优先考虑临时表 + 自增序号。
可行路径：
- 建临时表，插入每组数据并加
ROW_NUMBER() OVER (ORDER BY amount)逻辑（用变量或两次查询模拟） - 对每组取
FLOOR(0.25 * total_cnt)和FLOOR(0.75 * total_cnt)行对应的amount值作为q1、q3 - 性能代价明显：单次查询可能触发多次全表扫描，务必加
WHERE group_col = ?限定范围，别跑全量
真正难的不是怎么算，而是确认哪组数据该进这个流程——比如风控场景中，只对近 7 天新注册用户做异常检测，这个时间窗口必须在最外层就切好，否则分位基准就会混入历史平稳数据，漏掉真正的突变信号。
