用ILIKE或正则操作符（如~）配合GROUP BY和聚合函数可实现日志分类统计，关键在匹配逻辑覆盖真实变体并提前过滤无效行。
直接说结论：用 ILIKE 或正则操作符（如 ~）做模式匹配，配合 GROUP BY 和聚合函数（如 COUNT()、STRING_AGG()）就能完成日志的分类统计；但关键在于匹配逻辑是否覆盖真实日志变体，以及是否提前过滤掉无效行。
用 ILIKE 快速提取错误类型并计数
日志字段常含大小写混杂的关键词（如 "error"、"ERROR"、"Error"），ILIKE 是最轻量级的选择。它不依赖正则引擎，执行快，适合简单关键词扫描。
- 常见错误现象：用
LIKE 'ERROR%'漏掉小写记录，或用LOWER(log_text) LIKE '%error%'无法走索引（除非建了函数索引） - 正确写法示例：
SELECT COUNT(*) AS cnt, SPLIT_PART(log_text, ' ', 2) AS level FROM logs WHERE log_text ILIKE '%error%' GROUP BY level;—— 提取日志第二字段作为日志等级，并统计频次 - 注意：如果日志结构高度不一致（比如有的以
[ERROR]开头，有的是ERR:），ILIKE就会漏匹配，此时必须升级到正则
用 ~ 操作符匹配多格式错误前缀
当错误标识有多种写法（ERR、Error、[WARN]、⚠️ 等），~ 比 ILIKE 更可靠，且语法简洁，可直接用于 WHERE 过滤。
- 使用场景：清洗原始日志表，只保留含明确错误/警告信号的行，再聚合
- 参数差异：
~区分大小写，~*不区分；例如log_text ~* '\b(error|warn|fail)\b'能匹配单词边界内的任意变体 - 性能影响：正则比
ILIKE慢，尤其在无索引字段上全表扫描时；建议先用WHERE log_text ~ '^[A-Z]{3}'这类前缀正则快速缩小范围，再嵌套更细粒度匹配 - 容易踩的坑：忘记加单词边界
\b，导致'errors'匹配到'noerrors'；或误用.未转义，把'[ERROR]'写成'[ERROR]'（方括号在正则中是元字符）
用 regexp_matches() 提取结构化字段后聚合
如果日志是半结构化的（如 "[2024-05-12 10:23:45] WARN user_123 timeout after 5s"），靠 SUBSTRING 或 SPLIT_PART 很难稳定提取时间、级别、用户ID等，这时必须用 regexp_matches()。
- 返回类型是
TEXT[]，需用(...)[1]取捕获组，例如：(regexp_matches(log_text, '\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\] (\w+) (\w+_\d+)'))[1]提取时间 - 聚合前必须展开数组：对每行日志调用
regexp_matches后，用UNNEST()或子查询展开，否则GROUP BY会按整个数组分组 - 典型组合：
SELECT (m)[2] AS level, COUNT(*) FROM logs, LATERAL (SELECT regexp_matches(log_text, '\[(.*?)\] (\w+) (.+)') AS m) t WHERE m IS NOT NULL GROUP BY (m)[2]; - 容易被忽略的点：正则默认贪婪匹配，
.*可能吞掉本该属于下一个捕获组的内容；建议用.*?非贪婪，或限定字符集如[^]]*
聚合时避免重复计算与空值干扰
日志字段常含空值、空白行、JSON 嵌套失败内容，直接 GROUP BY 会导致分组错乱或 COUNT() 失真。
- 常见错误现象：
COUNT(*)统计了所有行，包括log_text IS NULL的脏数据；或STRING_AGG()因某字段为NULL导致整条聚合结果为NULL - 实操建议：在
WHERE中加log_text !~ '^\s*$' AND log_text IS NOT NULL排除空白；聚合函数内用COUNT(log_text)替代COUNT(*)，自动跳过NULL - 性能提示：如果日志表极大，先用
CREATE INDEX CONCURRENTLY ON logs ((log_text ~* '\berror\b'));创建部分索引，加速带正则条件的聚合查询 - 复杂点在于：正则提取 + 聚合 + 分页三者叠加时，PostgreSQL 可能无法下推
LIMIT到子查询，导致内存暴涨；务必用EXPLAIN ANALYZE看实际扫描行数
