应优先用结构化异常字段（如exception_type）分组计数，避免对原始message全文group by；需加where过滤error_level、trim空格、用having筛高频、建联合索引加速，并根据数据库特性选用近似计数或物化视图优化性能。
用 COUNT() 和 GROUP BY 统计每种异常类型的出现次数
直接统计异常日志频率，核心就是把日志表中代表异常类型的字段（比如 error_code、exception_type 或 message 的关键词）分组，再计数。别先想着模糊匹配或清洗，先确认你表里有没有结构化字段能直接用。
常见错误是直接对原始 message 全文 GROUP BY，结果得到成百上千个几乎重复但末尾带时间戳或线程ID的“不同”条目。应该优先用已提取好的分类字段；若没有，得先用 SUBSTRING_INDEX()（MySQL）、REGEXP_SUBSTR()（Oracle/PostgreSQL 15+）或 LEFT()/CHARINDEX()（SQL Server）做初步归一化。
- 如果日志表有
error_level字段且值为'ERROR'或'FATAL'，务必加WHERE error_level IN ('ERROR', 'FATAL')过滤，避免把WARN日志混进来 - MySQL 中
GROUP BY默认不区分大小写，但若字段是utf8mb4_0900_as_cs校对集，'NullPointerException'和'nullpointerexception'会被当两个类型——查前先SHOW CREATE TABLE logs;看校对集 - PostgreSQL 对空格和不可见字符敏感，
TRIM()掉exception_type前后空白再分组，否则'NPE '和'NPE'会拆成两行
用 HAVING 筛出高频异常，而不是在应用层过滤
高频异常往往只占全部异常类型的 10%–20%，但贡献了 80% 的数量。如果先 SELECT * 拉全量再用 Python 或 Java 过滤，既浪费网络带宽又拖慢响应。直接让数据库承担筛选责任。
典型场景：运维要看“单日出现超 50 次的异常”，不是“所有异常按次数倒序”。这时候 HAVING COUNT(*) > 50 是必须的，且要放在 GROUP BY 之后。注意 HAVING 不能引用别名（如 cnt），必须写完整表达式 COUNT(*)。
- MySQL 5.7+ 默认开启
sql_mode=ONLY_FULL_GROUP_BY，若SELECT列中有未出现在GROUP BY中的非聚合字段（比如log_time），会报错Expression #1 of SELECT list is not in GROUP BY clause - 想看“高频异常最近一次发生时间”，得用
MAX(log_time)而不是log_time—— 后者语法非法，前者才符合语义 - 如果表没在
log_time和exception_type上建联合索引，WHERE log_time >= '2024-06-01' GROUP BY exception_type HAVING COUNT(*) > 50可能全表扫描，查一天数据就卡住
处理多级异常分类：用 CASE WHEN 合并相似错误
真实日志里，java.lang.NullPointerException、org.springframework.web.bind.MethodArgumentNotValidException、com.example.api.ValidationException 可能都属于“参数校验失败”，但原生聚合会把它们拆成三条。需要用逻辑归类，而不是依赖字符串完全相等。
别写三层嵌套 IF() 或拼接超长 LIKE 条件。用 CASE WHEN 显式定义业务语义，既可读又方便后续扩展。
- 优先用
WHEN exception_type LIKE 'java.lang.NullPointerException%' THEN 'NPE'，而不是WHEN message LIKE '%NullPointer%'—— 前者查索引快，后者必走全文扫描 - PostgreSQL 中
~正则操作符比LIKE更灵活，但无索引支持；若正则模式固定（如'^java\.lang\..*Exception$'），可建函数索引：CREATE INDEX idx_exc_type_pattern ON logs ((exception_type ~ '^java\.lang\..*Exception$')); - SQL Server 的
IIF()不支持嵌套过深，超过 10 层易报Internal error: An expression services limit has been reached，此时必须改用CASE
避免 COUNT(*) 在大表上的性能陷阱
COUNT(*) 看似简单，但在亿级日志表上可能秒变慢查询。它不一定走索引——尤其当表有大量 NULL 值或使用了覆盖索引但未包含所有 GROUP BY 字段时。
关键不是“怎么写更快”，而是“是否真需要精确值”。监控报警场景下，误差 ±5% 完全可接受，这时该换思路。
- MySQL 8.0+ 可用近似计数：
SELECT exception_type, APPROX_COUNT_DISTINCT(log_id) FROM logs WHERE ... GROUP BY exception_type;，速度提升 3–10 倍 - PostgreSQL 可建物化视图定期刷新：
CREATE MATERIALIZED VIEW mv_daily_exception_freq AS SELECT date_trunc('day', log_time) d, exception_type, COUNT(*) c FROM logs GROUP BY 1, 2;，查时直接SELECT * FROM mv_daily_exception_freq WHERE d = '2024-06-01'; - ClickHouse 用户别碰
COUNT(*)—— 改用countMerge(state)配合AggregatingMergeTree引擎，否则单次聚合可能吃光内存
最常被忽略的是日志时间范围。没加 WHERE log_time >= ... 的聚合，很容易误算历史归档数据，结果看起来“某异常每天出现 10 万次”，其实全是三年前的老日志。先框定时间窗口，再谈统计。
