H2 下 LIKE 查询大小写不一致怎么处理

背景

我们使用 H2 数据库管理一个日志审计系统，核心表 t_audit_log 规模达到 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业务方反馈该表的某高频查询 P99 超过 4.6s，严重影响系统性能。

现象

该查询 SQL 的关键问题是索引选择不当和 SQL 写法。通过 EXPLAIN 分析发现，查询实际走的是全表扫描，而 EXPLAIN ANALYZE 进一步确认了其真实耗时与扫描行数。

已尝试的排查与结果

1. 定位慢 SQL：使用 EXPLAIN 和慢日志分析，确认 SQL 的执行计划和实际扫描行数。
2. 判断问题根源：发现该查询中存在对索引列的函数运算和隐式类型转换，导致索引失效。
3. 分析索引选择性：评估索引列的选择性，发现 status 字段的基数很低（只有 0/1），加索引意义不大。

期望答案形态

1. 索引优化：如何设计联合索引，避免覆盖索引的副作用。
2. SQL 改写：如何避免函数运算和隐式类型转换。
3. 统计信息维护：如何定期更新统计信息，确保 EXPLAIN 的估算值与实际值一致。

参考内容

• JOIN 两侧 collation 不一致让索引隐身：utf8mb4_general_ci 与 0900_ai_ci 混用的慢查询复盘
• 慢查询治理的五个步骤与陷阱：从 EXPLAIN 到索引与改写