1、需求分析

需求：在代码层面获得Mybatis执行的SQL，修改SQL，并执行修改后的SQL

方案：Mybatis 拦截器：

 注意：添加拦截器后，会拦截所有的方法

 思考：其实拦截器就等同于Spring的AOP编程

 细粒度：Mybatis框架中，sql最后都会交给Sqlsession执行，拦截器拦截的其实就是：

• 1、Executor执行阶段
• 2、ParameterHandler参数处理阶段
• 3、StatementHandler预编译处理阶段
• 4、ResultSetHandler结果集处理阶段 

注：我们在执行Sql之前，需要先获取Mybatis的SqlSession对象，但框架的SqlSession下面还有四大对象，
所以SqlSession只是个甩手掌柜，
真正干活的却是Executor等四大对象：Executor,StatementHandler,ParameterHandler,ResultSetHandler。

比较形象的画图比喻：

 继续分析：

理论上来说，如果想拦截，这四个对象的所有方法均可拦截到

但是原则是原则，实际是实际

就像Java中的String类，它里面这么多方法，总有几个常用的

在这边主要拦截两个常用对象：

 按照Mybatis执行Sql的周期来说，Executor会把sql交给StatementHandler处理，

 所以我们常见的拦截方法还是StatementHandler，而且这个阶段的Sql已完成预编译，占位符出现，对Sql来说比较全面了（此时除了参数未赋值，其他都全了，就等执行了）

2、熟悉拦截器的开发结构

 1、编码 

  类实现Intercepyor接口@Override

// 核心拦截逻辑编写    
public Object intercept(Invocation invocation) throws Throwable {
     // 编写拦截逻辑
      System.out.println("编写拦截逻辑");
     // 放行该方法
     return invocation.proceed();
}


// 把这个拦截器的目标传给下一个拦截器
    @Override
    public Object plugin(Object target) {
        // 当目标类是StatementHandler类型时，才包装目标类，否者直接返回目标本身,减少目标被代理的次数
        if (target instanceof StatementHandler) {
            System.out.println("Wrapper：：");
            return Plugin.wrap(target, this);
        } else {
            System.out.println("pass on Wrapper：：");
            return target;
        }


    @Override
    public void setProperties(Properties properties) {
        //此处可以接收到配置文件的property参数，就像工作流里面的局部变量，如果业务上需要定义参数，可以通过此方法
//        System.out.println(properties.getProperty("name"));
    }

  类 标注拦截的方法和参数（防止方法重载，需参数判别方法的唯一性）

@Intercepts({@Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class})})
public class AccessControlInterceptor implements Interceptor {

}

2、配置（Configure配置）

  在  mybatis-config.xml  中通过plugins 标签配置拦截器

  或者利用SpringBoot快速定义@Configure标签标识Bean

思考：如何控制拦截器的执行顺序？
         比如我想让拦截器x执行完之后，再执行拦截器y
参考链接：https://juejin.cn/post/6926849748481605646

好的，到这里。执行到每一个mapper文件的接口对应的sql 都会起作用了。（包括PageHelper 自动生成的Count查询，同样会被拦截）

思考：1、如何只拦截SELECT类型的sql，自动过滤掉update类型？
     2、如何拦截指定的mapper接口方法？
         
方案：1、可以通过拦截方法的invocation参数利用反射获取本次执行sql的 
        MappedStatement，进而获得sqlCommandType
         
     2、可在mapper接口方法层面添加自定义注解，同样是通过反射的方式 
        获得注解标志位判定应不应该进行拦截，还可通过注解传递有含义的 
        value

3、更细致的分析 

为什么要拦截StatementHandler的prepare呢

1、Executor 会交给StatementHandler，

    在StatementHandler接口实现类的方法调用中，

    StatementHandler的prepare生产出的Statemen会作为参数提供给CRUD和批处理之类的操作

    拦截prepare方法是一劳永逸

调用结构顺序如下图：

2、拦截prepare方法可以获得当前的Connection对象，

     Connection对象是所有Java接入所有数据库的规则接口，可操作性的东西会很多

     sql片段、事务，等同于JDBC  为所欲为 

 4、拦截器应用举例

一般什么情况下会使用拦截器：当需要操作sql时

例如：分页（添加limit sql片段），乐观锁（设置版本号校验，校验成功直接更新版本和数据，校验失败直接提示线程争抢失败请重试）

应用开发之一、pagehelper如何使用拦截器实现分页

找一个

   1、com.github.pagehelper.PageInterceptor 拦截请求

 第 71 - 第99行都是校验参数、创建缓存之类的操作

   2、凭空捏造Count查询

第 100 行，pagehelper官方团队给出的注释是：查询总数

 继续追代码，进入count(..)

先判断是否存在手写的 count 查询，

存在Count查询，用原来的 ms ，更新部分参数，直接执行并返回结果，

没有的话，根据当前的 ms 创建一个返回值为 Long 类型的 ms，并放到缓存中去

最后执行Count查询，并返回Count

接着做了一个小优化

处理查询总数，当查询总数为 0 时，直接结束查询

   3、修改原始查询sql 拼接 limit进行分页

根据上一步查询来的Count，结合当前页，计算limit值，并交给Executor去执行query

至此，pagehelper整个分页粗略过程完成

4、思考使用的细节

     PageHelper是如何做到只对紧跟着的第一条SQL起作用的？即使在下面添加再多的select，他仍然只对第一个select情有独钟

先揭晓答案： PageHelper.startPage在当前线程中创建一个线程变量 t1，

                   需要的时候就去当前线程获取 t1，使用完一次就在finally中remove掉 t1

                   受限于代码同步执行的特性，实现了只对第一个select起作用

                 （思考：若开启新线程，在主查询之前执行异步查询，Pagehelper特性会失效吗？）

源代码追溯：

 （未完待续。。。）

 应用开发之二、 乐观锁使用拦截器

 （未完待续。。。）