MyBatis拦截器实现SQL监控与分析

本文深入解析了如何通过MyBatis拦截器精准监控SQL执行耗时与性能瓶颈，重点围绕拦截Executor这一最直接、最稳定的切入点，系统梳理了声明拦截器的三大关键陷阱（类型、方法名、参数顺序）、安全获取真实SQL耗时的实践技巧（如基于nanoTime、过滤缓存/非查询/批量操作），并直击上线后监控失效的典型场景——多数据源配置遗漏、MyBatis-Plus代理包装干扰、分库分表中间件替换Executor、以及CachingExecutor导致的缓存路径漏监等问题，为构建高可靠SQL可观测性体系提供了一套即学即用、避坑高效的落地指南。

MyBatis拦截Executor执行耗时SQL的原理

MyBatis的Executor是SQL实际执行的入口，所有query、update最终都走它。Interceptor能插在Executor的query和update方法前后，拿到MappedStatement、绑定参数、执行耗时——这是监控SQL最直接的位置，比拦截StatementHandler更早、比拦截RoutingStatementHandler更稳定。

注意：不能拦截SimpleExecutor内部的doQuery等私有方法，必须通过MyBatis提供的Interceptor接口标准链路介入。

写一个Executor拦截器要填的三个坑

自定义Interceptor类必须正确声明@Intercepts，否则不会生效。常见失效原因就这三点：

• @Intercepts里@Signature的type必须是Executor.class，不是StatementHandler或ParameterHandler
• method名必须小写拼写准确："query"和"update"（不是"execute"或"doQuery"）
• args类型顺序不能错：比如query方法前两个参数是MappedStatement.class和Object.class，漏掉RowBounds.class或ResultHandler.class会导致匹配失败

示例关键片段：

@Intercepts({
  @Signature(type = Executor.class, method = "query",
      args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
  @Signature(type = Executor.class, method = "update",
      args = {MappedStatement.class, Object.class})
})

怎么安全地测出SQL真实耗时

别在intercept()里直接用System.currentTimeMillis()包整个invocation.proceed()——Executor可能被复用、事务嵌套、缓存命中，导致时间不准或重复统计。

推荐做法是只对未命中二级缓存的查询计时，并跳过批量操作：

• 从invocation.getArgs()[0]拿到MappedStatement，用ms.getSqlCommandType() != SqlCommandType.SELECT过滤非查询
• 检查ms.isUseCache()和executor.getTransaction().getConnection()是否为null（避免事务未开启时误判）
• 用System.nanoTime()而非currentTimeMillis()，减少系统时钟调整干扰
• 日志或上报时带上ms.getId()和参数摘要（如JSON.toJSONString(param, SerializerFeature.WriteClassName)截断前100字符）

上线后发现慢SQL没打出来？检查这几个点

Interceptor不生效往往不是代码问题，而是配置或环境干扰：

• Spring Boot中SqlSessionFactoryBean是否显式设置了setPlugins(...)？自动扫描@Intercepts注解无效
• 多数据源场景下，每个SqlSessionFactory都要单独注册拦截器，共用一个实例会导致部分数据源漏监控
• MyBatis-Plus 3.4+ 默认启用了MybatisConfiguration包装，需确认拦截器注册到的是原始Configuration而非代理对象
• 某些分库分表中间件（如ShardingSphere）会替换Executor实现，此时拦截点可能失效，得改拦它的ShardingExecutor

最隐蔽的问题：Executor被CachingExecutor包装后，query调用链变成CachingExecutor#query → BaseExecutor#query，但你的拦截器只配了BaseExecutor，就会漏掉缓存命中的情况——要么加一层对CachingExecutor的拦截，要么统一在BaseExecutor上拦截并判断ms.getCache() != null来区分缓存路径。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。