大家好，我是架构摆渡人。这是实践经验系列的第九篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

Mybatis是我们经常用的一款操作数据库的框架，它的插件机制设计的非常好，能够在很多需求场景下派上用场。如果你还没用过Mybatis的插件（Mybatis 插件实际是一种拦截器），那么需要仔细阅读这篇文章。

SQL监控埋点

说句大实话，大部分性能问题都发生在存储层。当然对于优化我们需要有足够的样本，这些样本也就是慢SQL。数据库本身就有慢SQL的日志，但不方便我们跟具体的接口和trace进行关联。

如果要跟trace进行关联那么就必须自己进行埋点上报性能数据，像我们之前用Cat做监控的时候，就是基于Mybatis的插件进行埋点，这样可以在Cat中看到每次请求下执行了哪些SQL，以及SQL的执行时间。

SQL校验

如果你们的表做了水平拆分，也就是分库分表。当然有可能是用开源框架实现的，也有可能是自研的框架。对于SQL的写法没有过多要求，但是如果是分库分表，而你的查询语句中没有带分片的字段，这个时候一般都是会进行所有表的查询，然后合并结果返回。

假如你想打破这个规则，查询的SQL中必须带分片的字段，否则就直接报错。当然可以对你们的分库分表框架进行改造，如果是开源的改起来比较麻烦，那是否可以简单点实现呢？

可以的，答案就是用Mybatis插件进行扩展，拿到执行的SQL进行分析，然后做校验。

SQL改写相对来说用的比较少，主要是改写是个很危险的事情，稍有不慎，线上就要炸锅了。那么改写会有哪些场景下需要呢？

之前有遇到过的场景就是，我们接了一个新的分库分表的框架，老框架是支持分表场景下update分片字段的。比如你user表的分片字段是id，那么update语句中可以带上这个id，只不过值还是原来的，不影响数据，这种也经常会在用一些自动生成SQL的场景下会有。

自从接了新框架后，对SQL更新有要求啦，分片字段是不允许更新的，不能出现在update的SQL中，如果有就直接报错。所以这个时候改写SQL就排上用场了，当然为了稳定性，我们还是采用了最原始的方式，将所有SQL都改了一遍。

SQL中透传信息这个很实用，问题在于透传的信息给谁使用呢？

其实这个要归根于你们有没有使用Proxy方式的分库分表中间件，如果有的话就需要透传信息。

比如读写分离场景，Proxy怎么知道你的SQL要走主库还是走从库呢？

比如在做压测的时候，Proxy怎么知道你的SQL要走正常库还是影子库呢？当然这个你也可以把影子库控制放在客户端。

那么如何通过SQL进行信息透传呢？如下：

/*master:true*/ SELECT * FROM table

其实就是在SQL的前面加一些特殊的信息，然后中间件去解析做对应的处理。