应使用cte或子查询先计算每组均值和标准差，再筛选amount > avg + 3×std的记录，并添加count(*)>=5、amount is not null、std>0等保护条件，避免误判。
GROUP BY 后怎么拿到每组里最大的那个值，但又不是真的最大？
真最大值用 MAX() 就行，但“异常最大值”往往指：明显偏离本组分布、疑似脏数据或业务异常的极大值——比如订单表里某用户单次下单 9999 件，而该用户历史均值是 2.3 件。这时候不能只靠 MAX()，得先定义“异常”，再筛选。
常见错误是直接写 SELECT user_id, MAX(amount) FROM orders GROUP BY user_id，结果把所有“看起来大”的值都捞出来，根本分不清是促销爆单还是录入错误。
- 先用窗口函数算出每组的统计基准，比如
AVG(amount)和STDDEV(amount) - 再用
HAVING或子查询过滤：只保留amount > AVG + 3 * STDDEV的记录 - 注意
STDDEV()在 MySQL 8.0+ 才默认可用；低版本得用STDDEV_SAMP()或手动算方差 - 如果组内数据少于 5 条，标准差容易失真，建议加
COUNT(*) >= 5保护条件
用 HAVING 还是子查询？性能差别很大
HAVING 只能作用于 GROUP BY 后的聚合结果，没法访问原始行；而“异常最大值”往往要返回整行（比如订单 ID、时间、用户邮箱），所以必须用子查询或 CTE。
典型错误是硬套 HAVING amount > MAX(amount) * 0.9 ——这语法根本报错，amount 不在 GROUP BY 里，也没被聚合，SQL 引擎不认。
- 推荐用 CTE 先算每组基准：
WITH group_stats AS ( SELECT user_id, AVG(amount) AS avg_amt, STDDEV(amount) AS std_amt FROM orders 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.avg_amt + 3 * g.std_amt
- MySQL 5.7 不支持 CTE？那就用内联视图（FROM 子查询），别用
HAVING硬扛 - WHERE 条件里的
o.amount > ...无法走索引，如果数据量大，记得在(user_id, amount)上建联合索引
NULL 和边界值会让异常判断完全失效
只要字段有 NULL，AVG()、STDDEV() 就自动忽略它们——看起来没问题，但如果你的“异常”恰恰藏在 amount IS NULL 被当成 0 处理的逻辑里，结果就全偏了。
另一个坑是 STDDEV() 对全相同值返回 0，导致 avg + 3 * 0 变成纯均值，所有大于均值的都命中，误报爆炸。
- 显式过滤掉
amount IS NULL或补默认值：WHERE amount IS NOT NULL AND amount > 0 - 加判断：当
std_amt = 0时，改用四分位距（IQR）逻辑，或直接跳过该组 - 业务上明确“异常”的下限，比如
amount >= 1000才进异常流程，避免把 500 件的正常大单也抓进来
PostgreSQL 和 SQLite 的聚合函数行为差异
同一个 SQL，在 PostgreSQL 里跑通，到 SQLite 就报错，大概率栽在窗口函数或统计函数上。
比如 STDDEV_POP() 在 PostgreSQL 是内置函数，SQLite 默认没有，得自己编译扩展或用近似公式；又比如 PostgreSQL 支持 FILTER (WHERE ...) 子句做条件聚合，SQLite 不认。
- 跨数据库时，优先用可移植写法：
AVG(CASE WHEN amount > 0 THEN amount END)替代AVG(amount) FILTER (WHERE amount > 0) - SQLite 想算标准差？老实用子查询先算均值，再 JOIN 算平方差平均，虽然慢但稳
- PostgreSQL 的
PERCENTILE_CONT(0.75)很好用，但别指望它在其他引擎里存在
实际写的时候，最麻烦的从来不是语法，而是得反复确认：你定义的“异常”，到底是技术离群点，还是业务不可接受值——前者靠统计，后者得翻需求文档。
