偶发Mysql/JDBI/PreparedStatement/execute插入更新缓慢问题排查求助

问题背景 #

通过SkyWalking监控发现，Mysql/JDBI/PreparedStatement/execute端点存在偶发的插入、更新执行缓慢情况。
环境配置：

• MySQL版本：8.0.23
• 事务隔离级别：read committed
• 连接池：先后切换Druid、HikariCP，问题未解决

已完成排查：

• 无数据库主机访问权限，无法查看IO统计
• DBA提供的慢SQL日志中无对应记录
• 已排除大事务问题
• 仅部分表存在该现象

排查方向与实操建议 #

1. 代码与JDBI使用规范排查

• 检查目标表的PreparedStatement复用情况：避免每次执行都重新编译SQL，确保JDBI正确复用预编译语句（比如使用@SqlQuery/@SqlUpdate注解时配置合理）
• 排查操作前的冗余逻辑：确认插入/更新前是否存在重复查询、不必要的数据校验，这类额外IO可能引发偶发延迟
• 记录锁竞争相关日志：在代码中添加线程ID、操作数据ID的日志，排查是否存在多线程更新同一条数据导致的行锁等待
• 验证资源释放：确认连接、Statement等资源是否在执行后正确关闭，避免连接泄漏导致连接池耗尽后出现等待

2. 数据库层面间接排查（协调DBA）

• 确认目标表索引状态：询问DBA是否存在索引过多、索引字段更新频繁（比如高基数字段作为索引），或统计信息过时导致优化器选择低效执行计划
• 检查表碎片情况：InnoDB表碎片过多会影响写入性能，可建议DBA对目标表执行OPTIMIZE TABLE（需评估锁表影响）
• 排查数据库周期性任务：确认是否存在备份、主从同步、统计信息更新等任务，这些任务可能抢占资源引发偶发延迟
• 查看事务等待状态：要求DBA查询INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS表，排查是否存在长事务阻塞写入操作

3. 应用层监控补充

• 添加业务级慢执行日志：对目标表的插入/更新操作记录开始/结束时间、完整SQL、参数、线程ID，出现慢执行时快速定位场景
• 用Arthas排查线程状态：当问题出现时，通过Arthas查看线程栈，确认是否处于WAITING/BLOCKED状态，排查线程锁或资源等待
• 监控连接池指标：记录活跃连接数、等待队列长度，确认是否因连接池配置不合理（如最小连接数不足、超时设置过长）导致连接等待

4. 其他潜在原因

• 检查触发器/存储过程：目标表是否存在触发器或关联存储过程，这些附加逻辑可能偶发执行缓慢
• 排查网络波动：若允许，测试应用与数据库服务器之间的网络延迟，或在代码中添加网络耗时日志，确认是否存在网络层面的偶发延迟

内容的提问来源于stack exchange，提问作者CozAni