你是否曾经遇到过这样的情况：在大促活动期间，用户访问量骤增，数据库的压力陡然加大，导致响应变慢甚至服务中断？更让人头疼的是，当你试图快速定位问题所在时，却发现难以确定究竟是哪个业务逻辑中的 SQL 语句成为了性能瓶颈。面对这样的困境，本篇文章提出了对 SQL 进行 “染色” 的方法来帮助大家 一眼定位问题 SQL，而无需再在多处逻辑中辗转腾挪。本文的思路主要受之前郭忠强老师发布的 如何一眼定位SQL的代码来源：一款SQL染色标记的简易MyBatis插件 文章启发，我在这个基础上对逻辑进行了简化，去除了一些无关的逻辑和工具类，并只对查询 SQL 进行染色，使这个插件“更轻”。此外，本文除了提供 Mybatis 拦截器的实现以外，还提供了针对 ibatis 框架实现拦截的方法，用于切入相对比较老的应用，希望对大家有所启发~
在文章开展之前，我们先来了解一下什么是 SQL 染色：染色的含义是 在 SQL 执行前，在 SQL 上进行注释打标，标记内容为这条 SQL 对应的是 Mapper 文件中的哪条 SQL 以及相关的方法执行堆栈，如下为在 SGM 的 SQL 执行监控端能直接看到 SQL 染色信息：
这样便能够非常轻松地看到到底是什么逻辑执行了哪段 SQL，并且经过实际生产性能验证，染色操作耗时在 0 ~ 1ms 左右：
[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：0ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：0ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：1ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：1ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：1ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：0ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：1ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：0ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：0ms[JSF-BZ-22000-366-T-20] INFO c.j.b.t.s.SqlExecutorInterceptor [67] - SQL 染色耗时：1ms
现在我们已经对 SQL 染色有了基本的了解，下面将介绍两种实现染色的方式：Mybatis 拦截器实现和基于 AspectJ 织入实现。在接下来的内容中我会展示染色实现的源码信息，但是并不复杂，代码量只有百行，所以大家可以直接将文章中的代码逻辑复制到项目中实现即可。快速接入 SQL 染色
Mybatis 框架应用接入：跳转 “全量源码” 小节，复制拦截器源码到应用中，并在 Mybatis 拦截器配置中添加该拦截器便可以生效，注意修改源码中
com.your.package包路径为当前应用的有效包路径非 Mybatis 框架应用接入：参考 “基于 AspectJ 织入实现” 小节，通过对 SQL 执行相关 Jar 包进行拦截实现
Mybatis 拦截器实现
在展示具体实现前，我还是想通过给大家介绍原理的形式一步步将其实现，这样也能加深大家对 Mybatis 框架的理解，也欢迎大家阅读、订阅专栏 由 Mybatis 源码畅谈软件设计。如果不想看实现原理，直接看实现的话请跳转 全量源码 小节。
拦截器的作用范围
Mybatis 的拦截器不像 Spring 的 AOP 机制，它并不能在任意逻辑处进行切入。在 Mybatis 源码的 Configuration 类中，定义了它的拦截器的作用范围，即创建“四大处理器”时调用的 pluginAll 方法：
public class Configuration {// ...protected final InterceptorChain interceptorChain = new InterceptorChain();public ParameterHandler newParameterHandler(MappedStatement mappedStatement, Object parameterObject,BoundSql boundSql) {ParameterHandler parameterHandler = mappedStatement.getLang().createParameterHandler(mappedStatement,parameterObject, boundSql);// 拦截器相关逻辑return (ParameterHandler) interceptorChain.pluginAll(parameterHandler);}public ResultSetHandler newResultSetHandler(Executor executor, MappedStatement mappedStatement, RowBounds rowBounds,ParameterHandler parameterHandler, ResultHandler resultHandler, BoundSql boundSql) {ResultSetHandler resultSetHandler = new DefaultResultSetHandler(executor, mappedStatement, parameterHandler,resultHandler, boundSql, rowBounds);// 拦截器相关逻辑return (ResultSetHandler) interceptorChain.pluginAll(resultSetHandler);}public StatementHandler newStatementHandler(Executor executor, MappedStatement mappedStatement,Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {StatementHandler statementHandler = new RoutingStatementHandler(executor, mappedStatement, parameterObject,rowBounds, resultHandler, boundSql);// 拦截器相关逻辑return (StatementHandler) interceptorChain.pluginAll(statementHandler);}public Executor newExecutor(Transaction transaction, ExecutorType executorType) {executorType = executorType == null ? defaultExecutorType : executorType;// 创建具体的 Executor 实现类Executor executor;if (ExecutorType.BATCH == executorType) {executor = new BatchExecutor(this, transaction);} else if (ExecutorType.REUSE == executorType) {executor = new ReuseExecutor(this, transaction);} else {executor = new SimpleExecutor(this, transaction);}if (cacheEnabled) {executor = new CachingExecutor(executor);}// 拦截器相关逻辑return (Executor) interceptorChain.pluginAll(executor);}}
pluginAll 是让拦截器生效的逻辑，它具体是如何做的呢：
public class InterceptorChain {// 所有配置的拦截器private final List<Interceptor> interceptors = new ArrayList<>();public Object pluginAll(Object target) {for (Interceptor interceptor : interceptors) {// 注意 target 引用不断变化，会不断引用已经添加拦截器的对象target = interceptor.plugin(target);}return target;}// ...}
InterceptorChain实现非常简单，内部定义了集合来保存所有配置的拦截器，执行pluginAll方法时会遍历该集合，逐个调用Interceptor#plugin方法来 “不断地叠加拦截器”（interceptor.plugin方法执行时，target引用不断变更）。
注意这里使用到了 责任链模式，由
InterceptorChain的命名中包含Chain也能联想到该模式，之后我们在使用责任链时也可以考虑在命名中增加Chain以增加可读性。InterceptorChain将多个拦截器串联在一起，每个拦截器负责其特定的逻辑处理，并在执行完自己的逻辑后，调用下一个拦截器或目标方法，这样设计允许不同的拦截器之间的逻辑 解耦，同时提供了 可扩展性。
由此可知，拦截器的作用范围是 ParameterHandler, ResultSetHandler, StatementHandler 和 Executor 处理器（Handler），但是拦截它们又能实现什么效果呢？
要弄清楚这个问题，首先我们需要了解拦截器能够切入的粒度。在 Mybatis 框架中，定义拦截器时需要使用 @Intercepts 和 @Signature 注解来 配置切入的方法，如下所示：
@Intercepts({@Signature(method = "prepare", type = StatementHandler.class, args = {Connection.class, Integer.class})})@Servicepublic class SQLMarkingInterceptor implements Interceptor {// ...}
每个拦截器切入的粒度是方法级别的 的，比如在我们定义的这个拦截器中，切入的是StatementHandler#prepare方法，那么如果我们了解了四个处理器方法的作用是不是就能知道 Mybatis 拦截器所能实现的功能了？所以接下来我们简单了解一下它们的各个方法的作用：
ParameterHandler: 核心方法setParameters，它的作用主要是将 Java 对象转换为 SQL 语句中的参数，并处理参数的设置和映射，所以拦截器切入它能 对 SQL 执行的入参进行修改
public interface ParameterHandler {Object getParameterObject();void setParameters(PreparedStatement ps) throws SQLException;}
ResultSetHandler: 负责将 SQL 查询返回的ResultSet结果集转换为 Java 对象，拦截器切入它的方法能 对结果集进行处理
public interface ResultSetHandler {/*** 处理 Statement 对象并返回结果对象** @param stmt SQL 语句执行后返回的 Statement 对象* @return 映射后的结果对象列表*/<E> List<E> handleResultSets(Statement stmt) throws SQLException;/*** 处理 Statement 对象并返回一个 Cursor 对象* 它用于处理从数据库中获取的大量结果集，与传统的 List 或 Collection 不同，Cursor 提供了一种流式处理结果集的方式，* 这在处理大数据量时非常有用，因为它可以避免将所有数据加载到内存中** @param stmt SQL 语句执行后返回的 Statement 对象* @return 游标对象，用于迭代结果集*/<E> Cursor<E> handleCursorResultSets(Statement stmt) throws SQLException;/*** 处理存储过程的输出参数** @param cs 存储过程调用的 CallableStatement 对象*/void handleOutputParameters(CallableStatement cs) throws SQLException;}
Executor: 它的方法很多，概括来说它负责数据库操作，包括增删改查等基本的 SQL 操作、管理缓存和事务的提交与回滚，所以拦截器切入它主要是 管理执行过程或事务
public interface Executor {ResultHandler NO_RESULT_HANDLER = null;// 该方法用于执行更新操作（包括插入、更新和删除），它接受一个 `MappedStatement` 对象和更新参数，并返回受影响的行数int update(MappedStatement ms, Object parameter) throws SQLException;// 该方法用于执行查询操作，接受 `MappedStatement` 对象（包含 SQL 语句的映射信息）、查询参数、分页信息、结果处理器等，并返回查询结果的列表<E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler,CacheKey cacheKey, BoundSql boundSql) throws SQLException;<E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler)throws SQLException;<E> Cursor<E> queryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds) throws SQLException;// 该方法用于刷新批处理语句并返回批处理结果List<BatchResult> flushStatements() throws SQLException;// 该方法用于提交事务，参数 `required` 表示是否必须提交事务void commit(boolean required) throws SQLException;// 该方法用于回滚事务。参数 `required` 表示是否必须回滚事务void rollback(boolean required) throws SQLException;// 该方法用于创建缓存键，缓存键用于标识缓存中的唯一查询结果CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql);// 该方法用于检查某个查询结果是否已经缓存在本地boolean isCached(MappedStatement ms, CacheKey key);// 该方法用于清空一级缓存void clearLocalCache();// 该方法用于延迟加载属性void deferLoad(MappedStatement ms, MetaObject resultObject, String property, CacheKey key, Class<?> targetType);// 该方法用于获取当前的事务对象Transaction getTransaction();// 该方法用于关闭执行器。参数 `forceRollback` 表示是否在关闭时强制回滚事务void close(boolean forceRollback);boolean isClosed();// 该方法用于设置执行器的包装器void setExecutorWrapper(Executor executor);}
StatementHandler: 它的主要职责是准备（prepare）、“承接”封装 SQL 执行参数的逻辑，执行SQL（update/query）和“承接”处理结果集的逻辑，这里描述成“承接”的意思是这两部分职责并不是由它处理，而是分别由ParameterHandler和ResultSetHandler完成，所以拦截器切入它主要是 在准备和执行阶段对 SQL 进行加工等
public interface StatementHandler {Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException;void parameterize(Statement statement) throws SQLException;void batch(Statement statement) throws SQLException;int update(Statement statement) throws SQLException;<E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException;<E> Cursor<E> queryCursor(Statement statement) throws SQLException;BoundSql getBoundSql();ParameterHandler getParameterHandler();}
为了加深大家对这四个处理器的理解，了解它在查询 SQL 执行时作用的时机，我们来看一下查询 SQL 执行时的流程图：
每个声明 SQL 查询语句的 Mapper 接口都会被 MapperProxy 代理，接口中每个方法都会被定义为 MapperMethod 对象，借助 PlainMethodInvoker 执行（动态代理模式和策略模式），MapperMethod 中组合了 SqlCommand 和 MethodSignature，SqlCommand 对象很重要，它的 SqlCommand#name 字段记录的是 MappedStatement 对象的 ID 值（eg: org.apache.ibatis.domain.blog.mappers.AuthorMapper.selectAuthor），根据它来获取唯一的 MappedStatement（每个 MappedStatement 对象对应 XML 映射文件中一个 <select>, <insert>, <update>, 或 <delete> 标签定义），SqlCommand#type 字段用来标记 SQL 的类型。当方法被执行时，会先调用 SqlSession 中的查询方法 DefaultSqlSession#selectOne，接着由 执行器Executor 去承接，默认类型是 CachingExecutor，注意在这里它会调用 MappedStatement#getBoundSql 方法获取 BoundSql 对象，这个对象实际上最终都是在 StaticSqlSource#getBoundSql 方法中获取的，也就是说 此时我们定义在 Mapper 文件中的 SQL 此时已经被解析、处理好了（动态标签等内容均已被处理），保存在了 BoundSql 对象中。此时，要执行的 SQL 已经准备好了，它会接着调用 SQL 处理器 的 StatementHandler#prepare 方法创建与数据库交互的 Statement 对象，其中记录了要执行的 SQL 信息 ，而封装 SQL 的执行参数则由 参数处理器DefaultParameterHandler 和 TypeHandler 完成，ResultSet 结果的处理：将数据库中数据转换成所需要的 Java 对象由 结果处理器DefaultResultSetHandler 完成。
现在我们对拦截器的原理和查询 SQL 的执行流程已经有了基本的了解，回过头来再想一下我们的需求：“使用 Mybatis 的拦截器在 SQL 执行前进行打标”，那么我们该选择哪个方法作为切入点更合适呢？
理论上来说在 Executor, StatementHandler 和 ParameterHandler 相关的方法中切入都可以，但实际上我们还要多考虑一步：ParameterHandler 是用来处理参数相关的，在这里切入一般我们是要对入参 SQL 的入参进行处理，所以不选择这里避免为后续同学维护时增加理解成本；Executor “有时不是很合适”，它其中有两个 query 方法，先被执行的方法，对应图中 CacheExecutor 左侧的直线 query 方法：Executor#query(MappedStatement, Object, RowBounds, ResultHandler)，在方法中它会去调用 MappedStatement#getBoundSql 方法获取 BoundSql 对象 完成 SQL 的处理和解析，处理和解析后的 BoundSql 对象是我们需要进行拦截处理的，随后 在该方法内部 调用另一个 query 方法：Executor#query(MappedStatement, Object, RowBounds, ResultHandler, CacheKey, BoundSql)，对应图中 CacheExecutor 右侧的曲线 query 方法，它会将 BoundSql 作为入参去执行查询逻辑，结合本次需求，选择后者切入是合适的，因为它有 BoundSql 入参，对这个入参进行打标即可，我们来看一下 CachingExecutor 的源码：
public class CachingExecutor implements Executor {private final Executor delegate;// 先调用public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler)throws SQLException {BoundSql boundSql = ms.getBoundSql(parameterObject);CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);// 在方法内部调用return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);}public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler,CacheKey key, BoundSql boundSql) throws SQLException {// 二级缓存相关逻辑Cache cache = ms.getCache();if (cache != null) {flushCacheIfRequired(ms);if (ms.isUseCache() && resultHandler == null) {ensureNoOutParams(ms, boundSql);List<E> list = (List<E>) tcm.getObject(cache, key);if (list == null) {// 执行查询逻辑（被拦截）list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);tcm.putObject(cache, key, list);}return list;}}// 执行查询逻辑（被拦截）return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);}}
它使用了静态代理模式，其中封装的Executor实现类型为SimpleExecutor，在注释中标记了“被拦截”处的方法会让拦截器生效。那么前文中为什么要说它“有时不是很合适”呢？我们来看一种情况，将 Mybatis 配置中的cacheEnable置为 false，那么在创建执行器时实际类型不是CachingExecutor而是SimpleExecutor，如下源码所示：
public class Configuration {public Executor newExecutor(Transaction transaction, ExecutorType executorType) {executorType = executorType == null ? defaultExecutorType : executorType;// 创建具体的 Executor 实现类Executor executor;if (ExecutorType.BATCH == executorType) {executor = new BatchExecutor(this, transaction);} else if (ExecutorType.REUSE == executorType) {executor = new ReuseExecutor(this, transaction);} else {executor = new SimpleExecutor(this, transaction);}// false 不走这段逻辑if (cacheEnabled) {executor = new CachingExecutor(executor);}// 拦截器相关逻辑return (Executor) interceptorChain.pluginAll(executor);}}
当有 SELECT 查询语句被执行时，它会直接调用到BaseExecutor#query方法，在方法内部调用另一个需要被拦截的query方法，如下所示：
public abstract class BaseExecutor implements Executor {public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler)throws SQLException {BoundSql boundSql = ms.getBoundSql(parameter);// cache key 缓存操作CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);// 需要拦截的return query(ms, parameter, rowBounds, resultHandler, key, boundSql);}public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler,CacheKey key, BoundSql boundSql) throws SQLException {// ...}}
由于该方法是在方法内部被调用的，所以无法使拦截器生效（动态代理），这也是说它“有时不是很合适”的原因所在。因为存在这种情况，我们现在也只能选择StatementHandler作为切入点了，那么是选择切入StatementHandler#prepare方法还是StatementHandler#query方法呢？
public class SimpleExecutor extends BaseExecutor {public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler,BoundSql boundSql) throws SQLException {Statement stmt = null;try {Configuration configuration = ms.getConfiguration();// 创建 StatementHandlerStatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler,boundSql);// 准备 Statement，其中会调用 StatementHandler#prepare 方法stmt = prepareStatement(handler, ms.getStatementLog());// 由 StatementHandler 执行 query 方法return handler.query(stmt, resultHandler);} finally {closeStatement(stmt);}}}
根据源码，要被执行打标的BoundSql对象会在调用StatementHandler#prepare方法前会将BoundSql对象封装在StatementHandler中，如果选择切入StatementHandler#prepare方法，那么在该方法执行前在StatementHandler中拿到BoundSql对象进行修改便能实现我们的需求；如果选择切入StatementHandler#query方法，同样是需要在该方法执行前想办法获取到BoundSql对象，但是由于此时 SQL 信息已经被保存在了即将与数据库交互的Statement对象中，它的实现类有很多，比如常见的PreparedStatement，在其中获取 SQL 字符串相对复杂，所有还是选择StatementHandler#prepare方法作为切点相对容易。
拦截器的定义和源码解析
接下来我们来对拦截器进行实现，首先我们先对拦截器的切入点进行定义：
@Intercepts({@Signature(method = "prepare", type = StatementHandler.class, args = {Connection.class, Integer.class})})public class SQLMarkingInterceptor implements Interceptor {@Overridepublic Object intercept(Invocation invocation) throws Throwable {// ...}}
接着来实现其中的逻辑：@Signature(method = "prepare", type = StatementHandler.class, args = {Connection.class, Integer.class})})public class SQLMarkingInterceptor implements Interceptor {private static final Log log = LogFactory.getLog(SQLMarkingInterceptor.class);public Object intercept(Invocation invocation) throws Throwable {try {// 1. 找到 StatementHandler（SQL 执行时，StatementHandler 的实际类型为 RoutingStatementHandler）RoutingStatementHandler routingStatementHandler = getRoutingStatementHandler(invocation.getTarget());if (routingStatementHandler != null) {// 其中 delegate 是实际类型的 StatementHandler （静态代理模式），获取到实际的 StatementHandlerStatementHandler delegate = getFieldValue(RoutingStatementHandler.class, routingStatementHandler, "delegate", StatementHandler.class);// 2. 找到 StatementHandler 之后便能拿到 SQL 相关信息，现在对 SQL 信息打标即可marking(delegate);}} catch (Exception e) {log.error(e.getMessage(), e);}return invocation.proceed();}}
将自定义的逻辑添加上了try-catch，避免异常影响正常业务的执行。在主要逻辑中，需要先在Invocation中找到StatementHandler的实际被代理的对象，它被封装在了RoutingStatementHandler中，随后在StatementHandler中获取到BoundSql对象，对 SQL 进行打标即可（marking方法）。
获取 StatementHandler
拦截 StatementHandler 为什么要获取的是 RoutingStatementHandler 类型呢？我们回到拦截器拦截 StatementHandler 生效的源码：
public class Configuration {// ...protected final InterceptorChain interceptorChain = new InterceptorChain();public StatementHandler newStatementHandler(Executor executor, MappedStatement mappedStatement,Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {// 可以发现拦截器实际针对的是类型便是 RoutingStatementHandlerStatementHandler statementHandler = new RoutingStatementHandler(executor, mappedStatement, parameterObject,rowBounds, resultHandler, boundSql);// 拦截器相关逻辑return (StatementHandler) interceptorChain.pluginAll(statementHandler);}}
我们可以发现拦截器在生效时，针对的是RoutingStatementHandler类型，所以我们要获取该类型，如下源码：
public class SQLMarkingInterceptor implements Interceptor {private RoutingStatementHandler getRoutingStatementHandler(Object target)throws NoSuchFieldException, IllegalAccessException {// 如果被代理，那么一直找到具体被代理的对象while (Proxy.isProxyClass(target.getClass())) {target = Proxy.getInvocationHandler(target);}while (target instanceof Plugin) {Plugin plugin = (Plugin) target;target = getFieldValue(Plugin.class, plugin, "target", Object.class);}// 找到了 RoutingStatementHandlerif (target instanceof RoutingStatementHandler) {return (RoutingStatementHandler) target;}return null;}}
源码中前两步为处理代理关系的逻辑，因为RoutingStatementHandler可能被代理，需要获取到实际的被代理对象，找到之后返回即可。那么后续为什么还要获取到RoutingStatementHandler中的被代理对象呢？我们还需要再回到 Mybatis 的源码中：
public class RoutingStatementHandler implements StatementHandler {// 代理对象private final StatementHandler delegate;public RoutingStatementHandler(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds,ResultHandler resultHandler, BoundSql boundSql) {// 在调用构造方法时，根据 statementType 字段为代理对象 delegate 赋值，那么这样便实现了复杂度隐藏，只由代理对象去帮忙路由具体的实现即可switch (ms.getStatementType()) {case STATEMENT:delegate = new SimpleStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);break;case PREPARED:delegate = new PreparedStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);break;case CALLABLE:delegate = new CallableStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);break;default:throw new ExecutorException("Unknown statement type: " + ms.getStatementType());}}}
RoutingStatementHandler使用了静态代理模式，实际的类型被赋值到了delegate字段中，我们需要在这个对象中获取到BoundSql对象，获取delegate对象则通过反射来完成。
染色打标 marking
现在我们已经获取到了 StatementHandler delegate 对象，我们可以 SQL 进行打标了，但在打标之前我们需要先思考下要打标的内容是什么：
要清楚的知道被执行的 SQL 是定义在 Mapper 中的哪条：声明在 Mapper 中各个方法的唯一ID，也就是 StatementId
要清楚的知道这条 SQL 被执行时，有哪些相关方法被执行了：方法的调用栈
根据我们所需去找相关的内容就好了，以下是源码，需要注意的是由于所有类型的 SQL 都会执行到 prepare 方法，但我们只对 SELECT 语句进行打标，所以需要添加逻辑判断：
public class SQLMarkingInterceptor implements Interceptor {private void marking(StatementHandler delegate) throws NoSuchFieldException, IllegalAccessException {BoundSql boundSql = delegate.getBoundSql();// 实际的 SQLString sql = boundSql.getSql().trim();// 只对 select 打标if (StringUtils.containsIgnoreCase(sql, "select")) {// 获取其基类中的 MappedStatement 即定义的 SQL 声明对象，获取它的 ID 值表示它是哪条 SQLMappedStatement mappedStatement = getFieldValue(BaseStatementHandler.class, delegate, "mappedStatement", MappedStatement.class);String mappedStatementId = mappedStatement.getId();// 方法调用栈String trace = trace();// 按顺序创建打标的内容LinkedHashMap<String, Object> markingMap = new LinkedHashMap<>();markingMap.put("STATEMENT_ID", mappedStatementId);markingMap.put("STACK_TRACE", trace);String marking = "[SQLMarking] ".concat(markingMap.toString());// 打标sql = String.format(" /* %s */ %s", marking, sql);// 反射更新Field field = getField(BoundSql.class, "sql");field.set(boundSql, sql);}}}
执行打标的逻辑是修改BoundSql对象，将其中的sql字段用打标后的 SQL 替换掉。获取方法调用栈的逻辑我们具体来看一下，其实并不复杂，在全量堆栈信息中将不需要关注的堆栈排除掉，需要注意将!className.startsWith("com.your.package")修改成有效的路径判断：
public class SQLMarkingInterceptor implements Interceptor {private String trace() {// 全量调用栈StackTraceElement[] stackTraceArray = Thread.currentThread().getStackTrace();if (stackTraceArray.length <= 2) {return EMPTY;}LinkedList<String> methodInfoList = new LinkedList<>();for (int i = stackTraceArray.length - 1 - DEFAULT_INDEX; i >= DEFAULT_INDEX; i--) {StackTraceElement stackTraceElement = stackTraceArray[i];// 排除掉不想看到的内容String className = stackTraceElement.getClassName();if (!className.startsWith("com.your.package") || className.contains("FastClassBySpringCGLIB")|| className.contains("EnhancerBySpringCGLIB") || stackTraceElement.getMethodName().contains("lambda$")) {continue;}// 过滤拦截器相关if (className.contains("Interceptor") || className.contains("Aspect")) {continue;}// 只拼接类和方法，不拼接文件名和行号String methodInfo = String.format("%s#%s",className.substring(className.lastIndexOf('.') + 1),stackTraceElement.getMethodName());methodInfoList.add(methodInfo);}if (methodInfoList.isEmpty()) {return EMPTY;}// 格式化结果StringJoiner stringJoiner = new StringJoiner(" ==> ");for (String method : methodInfoList) {stringJoiner.add(method);}return stringJoiner.toString();}}
以上便完成了 SQL “染色” 拦截器的实现，将其添加到 mybatis 相关的拦截器配置中就可以生效了。全量源码
import com.jd.laf.config.spring.annotation.LafValue;import lombok.extern.slf4j.Slf4j;import org.apache.commons.lang3.StringUtils;import org.apache.ibatis.executor.statement.BaseStatementHandler;import org.apache.ibatis.executor.statement.RoutingStatementHandler;import org.apache.ibatis.executor.statement.StatementHandler;import org.apache.ibatis.mapping.BoundSql;import org.apache.ibatis.mapping.MappedStatement;import org.apache.ibatis.plugin.*;import org.springframework.stereotype.Service;import java.lang.reflect.Field;import java.lang.reflect.Proxy;import java.sql.Connection;import java.util.*;import java.util.concurrent.ConcurrentHashMap;import static org.apache.commons.lang3.StringUtils.EMPTY;@Signature(method = "prepare", type = StatementHandler.class, args = {Connection.class, Integer.class})})public class SQLMarkingInterceptor implements Interceptor {/*** 默认线程栈数组下标*/private static final int DEFAULT_INDEX = 2;/*** 是否开启SQL染色标记*/private boolean enabled;private static final Map<String, Field> FIELD_CACHE = new ConcurrentHashMap<>();public Object intercept(Invocation invocation) throws Throwable {if (!enabled) {return invocation.proceed();}try {// 1. 找到 StatementHandler（SQL 执行时，StatementHandler 的实际类型为 RoutingStatementHandler）RoutingStatementHandler routingStatementHandler = getRoutingStatementHandler(invocation.getTarget());if (routingStatementHandler != null) {// 其中 delegate 是实际类型的 StatementHandler （静态代理模式），获取到实际的 StatementHandlerStatementHandler delegate = getFieldValue(RoutingStatementHandler.class, routingStatementHandler, "delegate", StatementHandler.class);// 2. 找到 StatementHandler 之后便能拿到 SQL 相关信息，现在对 SQL 信息打标即可marking(delegate);}} catch (Exception e) {log.error(e.getMessage(), e);}return invocation.proceed();}private RoutingStatementHandler getRoutingStatementHandler(Object target)throws NoSuchFieldException, IllegalAccessException {// 如果被代理，那么一直找到具体被代理的对象while (Proxy.isProxyClass(target.getClass())) {target = Proxy.getInvocationHandler(target);}while (target instanceof Plugin) {Plugin plugin = (Plugin) target;target = getFieldValue(Plugin.class, plugin, "target", Object.class);}// 找到了 RoutingStatementHandlerif (target instanceof RoutingStatementHandler) {return (RoutingStatementHandler) target;}return null;}/*** 打标* 1. 要清楚的知道被执行的 SQL 是定义在 Mapper 中的哪条* 2. 要清楚的知道这条 SQL 被执行时方法的调用栈*/private void marking(StatementHandler delegate) throws NoSuchFieldException, IllegalAccessException {BoundSql boundSql = delegate.getBoundSql();// 实际的 SQLString sql = boundSql.getSql().trim();// 只对 select 打标if (StringUtils.containsIgnoreCase(sql, "select")) {// 获取其基类中的 MappedStatement 即定义的 SQL 声明对象，获取它的 ID 值表示它是哪条 SQLMappedStatement mappedStatement = getFieldValue(BaseStatementHandler.class, delegate, "mappedStatement", MappedStatement.class);String mappedStatementId = mappedStatement.getId();// 方法调用栈String trace = trace();// 按顺序创建打标的内容LinkedHashMap<String, Object> markingMap = new LinkedHashMap<>();markingMap.put("STATEMENT_ID", mappedStatementId);markingMap.put("STACK_TRACE", trace);String marking = "[SQLMarking] ".concat(markingMap.toString());// 打标sql = String.format(" /* %s */ %s", marking, sql);// 反射更新Field field = getField(BoundSql.class, "sql");field.set(boundSql, sql);}}/*** 获取某类型 clazz 某对象 object 下某字段 fieldName 的值 fieldClass*/private <T> T getFieldValue(Class<?> clazz, Object object, String fieldName, Class<T> fieldClass)throws NoSuchFieldException, IllegalAccessException {// 获取到目标类的字段Field field = getField(clazz, fieldName);return fieldClass.cast(field.get(object));}private String trace() {StackTraceElement[] stackTraceArray = Thread.currentThread().getStackTrace();if (stackTraceArray.length <= DEFAULT_INDEX) {return EMPTY;}LinkedList<String> methodInfoList = new LinkedList<>();for (int i = stackTraceArray.length - 1 - DEFAULT_INDEX; i >= DEFAULT_INDEX; i--) {StackTraceElement stackTraceElement = stackTraceArray[i];String className = stackTraceElement.getClassName();if (!className.startsWith("com.your.package") || className.contains("FastClassBySpringCGLIB")|| className.contains("EnhancerBySpringCGLIB") || stackTraceElement.getMethodName().contains("lambda$")) {continue;}// 过滤拦截器相关if (className.contains("Interceptor") || className.contains("Aspect")) {continue;}// 只拼接类和方法，不拼接文件名和行号String methodInfo = String.format("%s#%s",className.substring(className.lastIndexOf('.') + 1),stackTraceElement.getMethodName());methodInfoList.add(methodInfo);}if (methodInfoList.isEmpty()) {return EMPTY;}// 格式化结果StringJoiner stringJoiner = new StringJoiner(" ==> ");for (String method : methodInfoList) {stringJoiner.add(method);}return stringJoiner.toString();}private Field getField(Class<?> clazz, String fieldName) throws NoSuchFieldException {Field field;String cacheKey = String.format("%s.%s", clazz.getName(), fieldName);if (FIELD_CACHE.containsKey(cacheKey)) {field = FIELD_CACHE.get(cacheKey);} else {field = clazz.getDeclaredField(fieldName);field.setAccessible(true);FIELD_CACHE.put(cacheKey, field);}return field;}}
基于 AspectJ 织入实现这种方法主要用于在未使用 Mybatis 框架的系统中，基于 AspectJ 实现对 Maven 依赖中 Jar 包类的织入，完成 SQL 染色打标的操作。同时，这种方法并不限于此，大家可以借鉴这种方法用于其他 Jar 包的织入，而不局限于 Spring 提供的 AOP 机制，毕竟 Spring 的 AOP 只能对 Bean 进行织入。所以在本小节中，更注重方法的介绍。
添加依赖和配置插件
借助 AspectJ 在 编译期 实现对 Maven 依赖中 Jar 包类的织入，这与运行时织入（如 Spring AOP 使用的代理机制）不同，编译期织入是在生成的字节码中直接包含切面逻辑，生成的类文件已经包含了切面代码。
首先，需要先添加依赖：
<dependency><groupId>org.aspectj</groupId><artifactId>aspectjrt</artifactId><version>1.8.13</version></dependency>
并且在 Maven 的 plugins 标签下添加 aspectj-maven-plugin 插件配置，否则无法实现在编译期织入：
<plugin><groupId>org.codehaus.mojo</groupId><artifactId>aspectj-maven-plugin</artifactId><version>1.11</version><configuration><!-- 解决与 Lombok 的冲突 --><forceAjcCompile>true</forceAjcCompile><sources/><weaveDirectories><weaveDirectory>${project.build.directory}/classes</weaveDirectory></weaveDirectories><!-- JDK版本 --><complianceLevel>1.8</complianceLevel><source>1.8</source><target>1.8</target><!-- 展示织入信息 --><showWeaveInfo>true</showWeaveInfo><encoding>UTF-8</encoding><!-- 重点！配置要织入的 maven 依赖 --><weaveDependencies><weaveDependency><groupId>org.apache.ibatis</groupId><artifactId>ibatis-sqlmap</artifactId></weaveDependency></weaveDependencies></configuration><executions><execution><goals><goal>compile</goal></goals></execution></executions></plugin>
解决与 Lombok 的冲突配置内容不再解释，详细请看 CSDN: AspectJ和lombok。重点需要关注的配置内容是weaveDependency标签：配置织入依赖（详细可参见 Maven: aspectj-maven-plugin 官方文档），也就是说如果我们想对SqlExecutor进行织入，那么需要将它对应的 Maven 依赖添加到这个标签下才能生效，否则无法完成织入。
完成以上内容之后，现在去实现对应的拦截器即可。
拦截器实现
拦截器的实现原理非常简单，要织入的方法是 com.ibatis.sqlmap.engine.execution.SqlExecutor#executeQuery，这个方法的签名如下：
public void executeQuery(StatementScope statementScope, Connection conn, String sql, Object[] parameters, int skipResults, int maxResults, RowHandlerCallback callback) throws SQLException;根据我们的诉求：在 SQL 执行前对 SQL 进行染色打标，那么可以直接在这个方法的第三个参数 String sql 上打标，以下是拦截器的实现：
public class SqlExecutorInterceptor {private static final int DEFAULT_INDEX = 2;public Object aroundExecuteQuery(ProceedingJoinPoint joinPoint) throws Throwable {// 获取方法参数Object[] args = joinPoint.getArgs();String sqlTemplate = "";Object arg2 = args[2];if (arg2 instanceof String) {// 实际的 SQLsqlTemplate = (String) arg2;}if (StringUtils.containsIgnoreCase(sqlTemplate, "select")) {try {// SQL 声明的 IDString mappedStatementId = "";Object arg0 = args[0];if (arg0 instanceof StatementScope) {StatementScope statementScope = (StatementScope) arg0;MappedStatement statement = statementScope.getStatement();if (statement != null) {mappedStatementId = statement.getId();}}// 方法调用栈String trace = trace();// 按顺序创建打标的内容LinkedHashMap<String, Object> markingMap = new LinkedHashMap<>();markingMap.put("STATEMENT_ID", mappedStatementId);markingMap.put("STACK_TRACE", trace);String marking = "[SQLMarking] ".concat(markingMap.toString());// 先打标后SQL，避免有些平台展示SQL时进行尾部截断，而看不到染色信息String markingSql = String.format(" /* %s */ %s", marking, sqlTemplate);args[2] = markingSql;} catch (Exception e) {// 发生异常的话恢复最原始 SQL 保证执行args[2] = sqlTemplate;log.error(e.getMessage(), e);}}// 正常执行逻辑return joinPoint.proceed(args);}}
逻辑上非常简单，获取了MappedStatementId和线程的执行堆栈以注释的形式标记在 SELECT 语句前，注意如果大家要 对 INSERT 语句进行打标时，需要将标记打在 SQL 的最后，因为部分插件如InsertStatementParser会识别 INSERT，如果注释在前，INSERT 识别会有误报错。
验证织入
完成以上工作后，我们需要验证拦截器是否织入成功，因为织入是在编译期完成的，所以执行以下 Maven 编译命令即可：
mvn clean compile在控制台中可以发现如下日志信息提示织入成功：[] --- aspectj-maven-plugin:1.11:compile (default) @ ---[] Showing AJC message detail for messages of types: [error, warning, fail][] Join point 'method-execution(void com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(com.ibatis.sqlmap.engine.scope.StatementScope, java.sql.Connection, java.lang.String, java.lang.Object[], int, int, com.ibatis.sqlmap.engine.mapping.statement.RowHandlerCallback))' in Type 'com.ibatis.sqlmap.engine.execution.SqlExecutor' (SqlExecutor.java:163) advised by around advice from 'com.your.package.sqlmarking.SqlExecutorInterceptor' (SqlExecutorInterceptor.class(from SqlExecutorInterceptor.java))
并且在相应的target/classes目录下的SqlExecutor.class文件中也能发现被织入的逻辑：
public class SqlExecutor {public void executeQuery(StatementScope statementScope, Connection conn, String sql, Object[] parameters, int skipResults, int maxResults, RowHandlerCallback callback) throws SQLException {JoinPoint.StaticPart var10000 = ajc$tjp_0;Object[] var24 = new Object[]{statementScope, conn, sql, parameters, Conversions.intObject(skipResults), Conversions.intObject(maxResults), callback};JoinPoint var23 = Factory.makeJP(var10000, this, this, var24);SqlExecutorInterceptor var26 = SqlExecutorInterceptor.aspectOf();Object[] var25 = new Object[]{this, statementScope, conn, sql, parameters, Conversions.intObject(skipResults), Conversions.intObject(maxResults), callback, var23};var26.aroundExecuteQuery((new SqlExecutor$AjcClosure1(var25)).linkClosureAndJoinPoint(69648));}}
本文分享自微信公众号 - 京东云开发者（JDT_Developers）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
