Mybatis常见问题及原理

**

1、mybaties预编译

**
1.1 JDBC的预编译用法

相信每个人都应该了解JDBC中的PreparedStatement接口，它是用来实现SQL预编译的功能。其用法是这样的：

Class.forName("com.mysql.jdbc.Driver");
String url = "jdbc:mysql://127.0.0.1:3306/mybatis";
String user = "root";
String password = "123456";
//建立数据库连接
Connection conn = DriverManager.getConnection(url, user, password);
String sql = "insert into user(username, sex, address) values(?,?,?)";
PreparedStatement ps = conn.preparedStatement(sql);
ps.setString(1, "张三");  //为第一个问号赋值  
ps.setInt(2, 2);    //为第二个问号赋值
ps.setString(3, "北京");    //为第三个问号赋值
ps.executeUpdate();
conn.close();

1.2 预编译的好处

1.2.1、预编译能避免SQL注入

预编译功能可以避免SQL注入，因为SQL已经编译完成，其结构已经固定，用户的输入只能当做参数传入进去，不能再破坏SQL的结果，无法造成曲解SQL原本意思的破坏。

1.2.2、预编译能提高SQL执行效率

预编译功能除了避免SQL注入，还能提高SQL执行效率。当客户发送一条SQL语句给服务器后，服务器首先需要校验SQL语句的语法格式是否正确，然后把SQL语句编译成可执行的函数，最后才是执行SQL语句。其中校验语法，和编译所花的时间可能比执行SQL语句花的时间还要多。
如果我们需要执行多次insert语句，但只是每次插入的值不同，MySQL服务器也是需要每次都去校验SQL语句的语法格式以及编译，这就浪费了太多的时间。如果使用预编译功能，那么只对SQL语句进行一次语法校验和编译，所以效率要高。

1.3 预编译的实现过程

预编译功能如此重要，那么数据库是如何实现预编译的呢？这个问题其实可以当做一个面试题，能很好的考察面试者对预编译的理解。下面以MySQL为例说明一下预编译的过程：
MySQL执行预编译分为如三步：
第一步：执行预编译语句，例如：prepare myperson from ‘select * from t_person where name=?’
第二步：设置变量，例如：set @name=‘Jim’
第三步：执行语句，例如：execute myperson using @name
如果需要再次执行myperson，那么就不再需要第一步，即不需要再编译语句了：
设置变量，例如：set @name=‘Tom’
执行语句，例如：execute myperson using @name

2、#{}与${}的区别

（1）mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值。
（2）mybatis在处理$时，就是把${}替换成变量的值。
（3）使用#{}可以有效的防止SQL注入，提高系统安全性。原因在于：预编译机制。预编译完成之后，SQL的结构已经固定，即便用户输入非法参数，也不会对SQL的结构产生影响，从而避免了潜在的安全风险。
（4）预编译是提前对SQL语句进行预编译，而其后注入的参数将不会再进行SQL编译。我们知道，SQL注入是发生在编译的过程中，因为恶意注入了某些特殊字符，最后被编译成了恶意的执行操作。而预编译机制则可以很好的防止SQL注入。
正确的答案是：#{}是预编译处理，${}是字符串替换。

3、一级、二级缓存的作用？

（1）一级缓存: 基于 PerpetualCache 的 HashMap 本地缓存，其存储作用域为 Session，当 Session flush 或 close 之后，该 Session 中的所有 Cache 就将清空，默认打开一级缓存。
（2）二级缓存与一级缓存其机制相同，默认也是采用 PerpetualCache，HashMap 存储，不同在于其存储作用域为 Mapper(Namespace)，并且可自定义存储源，如 Ehcache。默认不打开二级缓存，要开启二级缓存，使用二级缓存属性类需要实现Serializable序列化接口(可用来保存对象的状态)，可在它的映射文件中配置 ；
（3）对于缓存数据更新机制，当某一个作用域(一级缓存 Session/二级缓存Namespaces)的进行了C/U/D 操作后，默认该作用域下所有 select 中的缓存将被 clear。

4、Dao接口的工作原理

MyBatis常见面试题10：通常一个Xml映射文件，都会写一个Dao接口与之对应，请问，这个Dao接口的工作原理是什么？Dao接口里的方法，参数不同时，方法能重载吗？
Dao接口即Mapper接口。接口的全限名，就是映射文件中的namespace的值；接口的方法名，就是映射文件中Mapper的Statement的id值；接口方法内的参数，就是传递给sql的参数。
Mapper接口是没有实现类的，当调用接口方法时，接口全限名+方法名拼接字符串作为key值，可唯一定位一个MapperStatement。在Mybatis中，每一个 、、、标签，都会被解析为一个MapperStatement对象。
举例来说：cn.mybatis.mappers.StudentDao.findStudentById，可以唯一找到namespace为 com.mybatis.mappers.StudentDao下面 id 为 findStudentById 的 MapperStatement。
Mapper接口里的方法，是不能重载的，因为是使用 全限名+方法名 的保存和寻找策略。Mapper 接口的工作原理是JDK动态代理，Mybatis运行时会使用JDK动态代理为Mapper接口生成代理对象proxy，代理对象会拦截接口方法，转而执行MapperStatement所代表的sql，然后将sql执行结果返回。

5、什么是MyBatis的接口绑定？有哪些实现方式？

接口绑定，就是在MyBatis中任意定义接口，然后把接口里面的方法和SQL语句绑定，我们直接调用接口方法就可以，这样比起原来了SqlSession提供的方法，可以有更加灵活的选择和设置。
接口绑定有两种实现方式，一种是通过注解绑定，就是在接口的方法上面加上 @Select、@Update等注解，里面包含Sql语句来绑定；另外一种就是通过xml里面写SQL来绑定，在这种情况下，要指定xml映射文件里面的namespace必须为接口的全路径名。
当Sql语句比较简单时候，用注解绑定，当SQL语句比较复杂时候，用xml绑定。一般情况下，用xml绑定的比较多。

使用MyBatis的mapper接口调用时要注意的事项有：
（1）Mapper接口方法名和mapper.xml中定义的每个sql的id相同；
（2）Mapper接口方法的输入参数类型和mapper.xml中定义的每个sql 的parameterType的类型相同；
（3）Mapper接口方法的输出参数类型和mapper.xml中定义的每个sql的resultType的类型相同；
（4）Mapper.xml文件中的namespace即是mapper接口的类路径。

6、模糊查询like语句该怎么写?

第1种：在Java代码中添加sql通配符
string wildcardname = “%tom%”;
list names = mapper.selectLike(wildcardname);

select * from users where name like #{value}

第2种：在sql语句中拼接通配符，会引起sql注入
string wildcardname = “tom”;
list names = mapper.selectLike(wildcardname);

select * from users where name like “%”#{value}"%"

第三种
select * from users where name like concat（"%"，#{value}，"%"）

7、当实体类中的属性名和表中的字段名不一样，怎么办 ？

第1种解决方案：通过在查询的sql语句中定义字段名的别名，让字段名的别名和实体类的属性名一致。

<select id="getOrder" parametertype="int" resultetype="cn.mybatis.domain.order">
    select order_id id, order_no orderNo ,order_price price form orders where order_id=#{id};
</select>

第2种解决方案：通过来映射字段名和实体类属性名的一一对应的关系。

<select id="getOrder" parameterType="int" resultMap="orderResultMap">
    select * from orders where order_id=#{id}
</select>
<resultMap id="orderResultMap" type="cn.mybatis.domain.order" >
    <!–用id属性来映射主键字段–>
    <id property="id" column="order_id">
    <!–用result属性来映射非主键字段，property为实体类属性名，column为数据表中的属性–>
    <result property= "orderNo" column="order_no"/>
    <result property="price" column="order_price"/>
</reslutMap>

8、Mybatis中的Dao接口和XML文件里的SQL是如何建立关系的

8.1 解析XML
首先，Mybatis在初始化SqlSessionFactoryBean的时候，找到mapperLocations路径去解析里面所有的XML文件，这里我们重点关注两部分。
8.1.1 创建SqlSource
Mybatis会把每个SQL标签封装成SqlSource对象，然后根据SQL语句的不同，又分为动态SQL和静态SQL。其中，静态SQL包含一段String类型的sql语句；而动态SQL则是由一个个SqlNode组成。

假如我们有这样一个SQL：

<select id="getUserById" resultType="user">
    select * from user 
    <where>
        <if test="uid!=null">
            and uid=#{uid}
        </if>
    </where>
</select>

它对应的SqlSource对象看起来应该是这样的：

8.1.2 创建MappedStatement
XML文件中的每一个SQL标签就对应一个MappedStatement对象，这里面有两个属性很重要。
id：全限定类名+方法名组成的ID。
sqlSource：当前SQL标签对应的SqlSource对象。
创建完MappedStatement对象，将它缓存到Configuration#mappedStatements中。
Configuration对象就是Mybatis中的大管家，基本所有的配置信息都维护在这里。把所有的XML都解析完成之后，Configuration就包含了所有的SQL信息。

8.2 Dao接口代理
我们的Dao接口并没有实现类，那么，我们在调用它的时候，它是怎样最终执行到我们的SQL语句的呢？
首先，我们在Spring配置文件中，一般会这样配置：

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
    <property name="basePackage" value="com.viewscenes.netsupervisor.dao" />
    <propertyname="sqlSessionFactoryBeanName" value="sqlSessionFactory"></property>
</bean>

或者你的项目是基于SpringBoot的，那么肯定也见过这种：
@MapperScan(“com.xxx.dao”)
它们的作用是一样的。将包路径下的所有类注册到Spring Bean中，并且将它们的beanClass设置为MapperFactoryBean。MapperFactoryBean实现了FactoryBean接口，俗称工厂Bean。那么，当我们通过@Autowired注入这个Dao接口的时候，返回的对象就是MapperFactoryBean这个工厂Bean中的getObject()方法对象
简单来说，它就是通过JDK动态代理，返回了一个Dao接口的代理对象，这个代理对象的处理器是MapperProxy对象。所有，我们通过@Autowired注入Dao接口的时候，注入的就是这个代理对象，我们调用到Dao接口的方法时，则会调用到MapperProxy对象的invoke方法。
8.3 执行
当我们调用Dao接口方法的时候，实际调用到代理对象的invoke方法。 在这里，实际上调用的就是SqlSession里面的东西了。

public class DefaultSqlSession implements SqlSession {
public <E> List<E> selectList(String statement, 
Object parameter,RowBounds rowBounds) {
        try {
            MappedStatement ms =
 configuration.getMappedStatement(statement);
            return executor.query(ms, wrapCollection(parameter), 
rowBounds, Executor.NO_RESULT_HANDLER);
        }
    }
}

是通过statement全限定类型+方法名拿到MappedStatement 对象，然后通过执行器Executor去执行具体SQL并返回

9、Java客户端中的一个Connection是不是在MySQL中就对应一个线程来处理这个链接呢？

不是。凡是从线程思考问题的人，一般都是被Java技术的多线程思想所禁锢了，其实在高性能服务器端端开发底层往往靠io复用来处理，这种模式就是：单线程+事件处理机制。在MySQL里面往往有一个主线程，这是单线程（与Java中处处强调多线程的思想有点不同哦），它不断的循环查看是否有socket是否有读写事件，如果有读写事件，再从线程池里面找个工作线程处理这个socket的读写事件，完事之后工作线程会回到线程池。所以：Java客户端中的一个Connection不是在MySQL中就对应一个线程来处理这个链接，而是由监听socket的主线程+线程池里面固定数目的工作线程来处理的。

10、事务执行过程中宕机的应对处理方式

问题：数据库插入百万级数据的时候，还没操作完，但是把服务器重启了，数据库会继续执行吗？ 还是直接回滚了？

答案：不会自动继续执行，不会自动直接回滚，但是可以人工手动选择继续执行或者直接回滚，依据是事务日志。
事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是人们口中常说的“日志先行”(Write-Ahead Logging)。
日志分为两种类型：redo log和undo log
（1）redo log
在系统启动的时候，就已经为redo log分配了一块连续的存储空间，以顺序追加的方式记录redo log，通过顺序io来改善性能。所有的事务共享redo log的存储空间，它们的redo log按语句的执行顺序，依次交替的记录在一起。如下一个简单示例：
记录1：<trx1, insert…>
记录2：<trx2, delete…>
记录3：<trx3, update…>
记录4：<trx1, update…>
记录5：<trx3, insert…>
此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。
（2）undo log
undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。
以下是undo+redo事务的简化过程，假设有2个数值，分别为A和B，值为1，2
start transaction;
记录 A=1 到undo log;
update A = 3；
记录 A=3 到redo log；
记录 B=2 到undo log；
update B = 4；
记录B = 4 到redo log；
将redo log刷新到磁盘
commit
在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。