很早之前参考别人写的一版读写分离插件
@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})})
@Slf4j
public class MasterSlaveSuffixAutoRoutingPlugin implements Interceptor, DdConstants {
@Override
public Object intercept(Invocation invocation) throws Throwable {}
@Override
public Object plugin(Object target) {
return target instanceof Executor ? Plugin.wrap(target, this) : target;
}
@Override
public void setProperties(Properties properties) {}
}
当时写完了，写了个测试发现没有问题就一直没管了，今天debug过程中发现，执行某些Mapper接口方法的时候，都不走这个插件，致使所有的sql其实都会请求到默认主库上去。
于是我把断点打在Executor的query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) 方法上，发现debug完全都不走这个方法。而是去走了query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey cacheKey, BoundSql boundSql) 这个有6个参数的方法。
因为代码里面看，我一直以为所有的查询sql执行都会经过这4个参数的sql然后再调用6个参数的。发现我调用的Mapper接口方法，直接就走的这6个参数的方法。（但是这个方法我们没拦截）
@Override
public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
BoundSql boundSql = ms.getBoundSql(parameter);
CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
}
这里我初步怀疑是不是其他的插件造成的锅？ 看了一些config里面配置的插件：
果然有一个PageHelper的插件，去看看里面的逻辑：
@Intercepts(
{
@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}),
}
)
public class PageInterceptor implements Interceptor {
@Override
public Object intercept(Invocation invocation) throws Throwable {
try {
Object[] args = invocation.getArgs();
MappedStatement ms = (MappedStatement) args[0];
Object parameter = args[1];
RowBounds rowBounds = (RowBounds) args[2];
ResultHandler resultHandler = (ResultHandler) args[3];
Executor executor = (Executor) invocation.getTarget();
CacheKey cacheKey;
BoundSql boundSql;
//由于逻辑关系，只会进入一次
if (args.length == 4) {
//4 个参数时
boundSql = ms.getBoundSql(parameter);
cacheKey = executor.createCacheKey(ms, parameter, rowBounds, boundSql);
} else {
//6 个参数时
cacheKey = (CacheKey) args[4];
boundSql = (BoundSql) args[5];
}
checkDialectExists();
//对 boundSql 的拦截处理
if (dialect instanceof BoundSqlInterceptor.Chain) {
boundSql = ((BoundSqlInterceptor.Chain) dialect).doBoundSql(BoundSqlInterceptor.Type.ORIGINAL, boundSql, cacheKey);
}
List resultList;
//调用方法判断是否需要进行分页，如果不需要，直接返回结果
if (!dialect.skip(ms, parameter, rowBounds)) {
//判断是否需要进行 count 查询
if (dialect.beforeCount(ms, parameter, rowBounds)) {
//查询总数
Long count = count(executor, ms, parameter, rowBounds, null, boundSql);
//处理查询总数，返回 true 时继续分页查询，false 时直接返回
if (!dialect.afterCount(count, parameter, rowBounds)) {
//当查询总数为 0 时，直接返回空的结果
return dialect.afterPage(new ArrayList(), parameter, rowBounds);
}
}
resultList = ExecutorUtil.pageQuery(dialect, executor,
ms, parameter, rowBounds, resultHandler, boundSql, cacheKey);
} else {
//rowBounds用参数值，不使用分页插件处理时，仍然支持默认的内存分页
resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);
}
return dialect.afterPage(resultList, parameter, rowBounds);
} finally {
if(dialect != null){
dialect.afterAll();
}
}
}
可以看到，这里面改写了正常的逻辑，他在拦截到4个参数的query之后，如果发现这个执行sql不需要进行分页会走这个逻辑：
{
//rowBounds用参数值，不使用分页插件处理时，仍然支持默认的内存分页
resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);
}
他自己转而去调用6个参数的query去了。这就操蛋了，而且他的顺序在我之前，他先拦截了，导致我拦截4个参数直接就被跳过去了。
之前因为PageHelper插件的问题也遇到过一些，比如使用涉及对sql改写的插件都要注意和PageHelper的前后顺序的兼容，不然可能会有各种问题。但是这次以为只是做个数据源切换，并不会相互影响，大意了。
解决方法很简单，我也加上对6个参数的query做拦截就好了（虽然也可以调整顺序来解决，但是并不好，没法避免其他再加个插件又来这么一出）：
@Intercepts({
@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}),
@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class})})
总接下：
后面需要拦截读操作的时候，拦截Executor的方法的时候，记得要把6个参数和4个参数的query方法都拦截了（其实只要拦截6个参数的就行了）。
