阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://yq.aliyun.com/roundtable/49835 「似水的流年」欢迎转载，保留摘要，谢谢！

• 案例一：
• 案例二：
• 案例三：
• 案例四：
• 案例五：
• 案例六：
• 案例七：
• 优缺点
  • 优点：
  • 缺点：
• 总结：

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

大多数开发者应该都使用过Hibernate或者Mybatis的框架，或多或少都踩过一些坑！ 如在MyBatis/Ibatis中#和$的区别，#方式能够很大程度防止sql注入，$方式无法防止Sql注入。所以，老司机 对新手说，最好用#。简单的说#{}是经过预编译的,是安全的,而解决一些实际问题。 如在执行sql语句时你有时并不希望让变量进行处理，而是直接赋值执行，这时就要用到(${ａ})了，在使用时还要这样赋值 @Param(value="a") String a

如日期问题： 可能会遇到日期格式的时间段问题，当数据库的时间为DATE类型时，MyBatis的jdbcType应该使用DATE jdbcType=DATE，而不是使用jdbcType=TIMESTAMP

如在使用resultMap的时候，要把ID写在第一行，否则的话，就会报错。

又如最近在做的项目，遇到myBatis的大坑，Mybatis一直报异常Java.lang.ArrayIndexOutOfBoundsException，于是开始代码查错，代码中有存储过程，然后开发使用ROOT用户执行SQL跑出来的数据结果集是正常的，在测试环境程序运行也正常，但是在正式环境就其他用户不行，最后发现是因为数据库没有给该用户授权出了问题。

案例一：

作为新手，在此记下刚踩的一个坑，（踩踩更健康= =踩过痛过才不会再次错），写了一个sql语句用到两张表，两张表中有两个字段名字是一样的都是Time和Content，然后要查询这两张表的这两个字段都要查出来放到一个dto中，dto如下图所示，

sql语句如下，

然而运行后却发现后几个在数据库表里同名的字段取出来都是null，

但是放到数据库那边执行是没有取出空数据的，

真是苦恼= =，后来经大神指点，sql语句查询出来的这个字段名必须和dto的参数名一致，改成这样就通过了，

数据都取出来了。。。。。。。。。。还记得在hibernate里用hql时放到dto里，select new dto名（）参数顺序和类型一致就可以取出来。。。这应该算一个不同点吧，，感觉还是hql用起来舒服，，，求大神科普两者的差别优缺点

当实体类中的属性名和表中的字段名不一致时，使用MyBatis进行查询操作时无法查询出相应的结果的问题，当时上网查了很多才知道，看到的一个解决方法分享给大家，通过来映射字段名和实体类属性名的一一对应关系。这种方式是使用MyBatis提供的解决方式来解决字段名和属性名的映射关系的！

案例二：

数据库表使用了联合主键，逆向生成的时候生成了两个实体类。看起来别扭。但还是可以用。后来就先取消主键，生成完后再将主键加上。还有就是，tinyint本来以为用来表示比较小的整数，结果生成了布尔型的属性。后来就表示是和否才用tinyint了。逆向生成的sql语句绝对不能人为改动，否则再次生成的时候会重复生成。但是，尽管踩过坑，我还是觉得mybatis超级好用，比hibernate好多了。虽然hibernate我只试过一点之后就完全转向了mybatis了。

案例三：

sum()和count()使用场景不对导致出错：

count()、count(1)、count(0)就是指绝对的行数，哪怕某行所有字段全部为null也会计算在内。count(1)和count()相比，innodb来说count(*)效率低。

如果count(列名)查询出来的结果就是查出列名中不为null的行数；

sum(列名)对指定列名进行求和

MyBatis把int类型的0处理成空串’’和mysql处理空串’’为0的问题，在Mybatis的Mapper中整数类型条件该如何判断？

当数据库字段类型是整数，如果参数变量为空字符串或者NULL，Mybatis会自动将参数赋值0，所以如果要判断整数参数的多种状态在传递数值到Mapper之前就要判断是否为空字符串和NULL并将相应的状态数值赋值给该参数，否则参数值等于空字符串、NULL和0得到的结果是一样的。

一般情况下，涉及到int类型的操作的时候，在Service中会统一把数字类型先变成字符串类型，然后再传递到Mapper中操作。

时间戳的使用

在创建新记录的时候把这个字段设置为当前时间，但以后修改时，不再刷新它(可以给createtime使用这个)：TIMESTAMP DEFAULT CURRENT_TIMESTAMP

在创建新记录和修改现有记录的时候都对这个数据列刷新(可以给update使用这个)：

TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

在使用resultMap的时候，要把ID写在第一行，否则的话，就会报错。

案例四：

XML转义字符，如果直接写就会报错，需要用左边一列的转义字符 < < 小于号 > > 大于号 & & 和 ' ' 单引号 " " 双引号

案例五：

前几天在项目中碰到，来说下吧。大神可绕道。在使用selectOne查询个数时， 如果你写了resultType为Integer，然后在业务代码中很自然的用一个变量int去接当前这个方法的返回，如果按照你传入的条件在数据库中没有找到相关的值，此时selectOne方法的返回值会是一个null，当你使用Java的自动拆箱机制的时候会报出一个无情的NPE。 原因：Java在自动拆箱的时候会调用Integer类中的intValue方法，如果当前对象为null，则抛出NPE。 因此，在接受的时候要判空，否则可能异常。

案例六：

多参数的使用

MyBatis的查询或者更新中，如果需要多个参数有如下几种办法：

对象映射，建立一个Java对象，并作为接口的参数，对象的属性可以直接使用#{属性名}的方式访问； Map, 参数为一个Map, key对于属性名，value对于参数值，这个方法就是传参数是需要建立一个Map的临时对象 @param参数注解，在接口方法参数前加入参数名称注解，这样就可以直接在Mapper中通过参数名访问 通过序号访问，第一个参数#{0}或#{param1}, 第二个参数#{1}, #{param2} MyBatis中时间字段的使用–返回 时间字段的返回目前笔者采用放回字符串的方式： date_format(update_time, ‘%Y-%c-%d %H:%i:%s’) updatetime 采用MySQL的时间格式化方法。 或者放回Timestamp类型的数据，要求放回对象属性参数为Timestamp.

MyBatis中时间字段的使用–参数 如果需要查询一段时间范围的数据时，可以通过以下动态SQL的方式查询数据：

and lbr.update_time > #{startTime}

and lbr.update_time < #{endTime, javaType=Date, jdbcType=TIMESTAMP}

对于的接口方法名称如下： … Date startTime, Date endTime… 我想这个方法会比通过格式转换的效率要高一些

1. MyBatis中时间字段的使用–写入 写入可是直接写入Timestamp的数据，需要描述一些写入的jdbcType，如下：

{installTime, jdbcType=TIMESTAMP}

1.Mapper层参数为Map,由Service层负责重载。

Mapper由于机制的问题，不能重载，参数一般设置成Map，但这样会使参数变得模糊，如果想要使代码变得清晰，可以通过service层来实现重载的目的，对外提供的Service层是重载的，但这些重载的Service方法其实是调同一个Mapper，只不过相应的参数并不一致。

也许有人会想，为什么不在Service层也设置成Map呢？我个人是不推荐这么做的，虽然为了方便，我在之前的项目中也大量采用了这种方式，但很明显会给日后的维护工作带来麻烦。因为这么做会使你整个MVC都依赖于Map模型，这个模型其实是很不错的，方便搭框架，但存在一个问题：仅仅看方法签名，你不清楚Map中所拥有的参数个数、类型、每个参数代表的含义。

试想，你只对Service层变更，或者DAO层变更，你需要清楚整个流程中Map传递过来的参数，除非你注释或者文档良好，否则必须把每一层的代码都了解清楚，你才知道传递了哪些参数。针对于简单MVC，那倒也还好，但如果层次复杂之后，代码会变得异常复杂，而且如果我增加一个参数，需要把每一个层的注释都添加上。相对于注释，使用方法签名来保证这种代码可控性会来得更可行一些，因为注释有可能是过时的，但方法签名一般不太可能是陈旧的。

2.尽量少用if choose等语句，降低维护的难度。

Mybatis的配置SQL时，尽量少用if choose 等标签，能用SQL实现判断的尽量用SQL来判断(CASE WHEN ,DECODE等)，以便后期维护。否则，一旦SQL膨胀，超级恶心，如果需要调试Mybatis中的SQL，需要去除大量的判断语句，非常麻烦。另一方面，大量的if判断，会使生成的SQL中包含大量的空格，增加网络传输的时间，也不可取。

而且大量的if choose语句，不可避免地，每次生成的SQL会不太一致，会导致ORACLE大量的硬解析，也不可取。 我们来看看这样的SQL：

SELECT * FROM T_NEWS_TEXT

< if test ="startdate != null and startdate != '' and enddate != null and endate != ''">

AND PUBLISHTIME >= #{startdate} AND PUBLISHTIME <= #{enddate}

AND PUBLISHTIME >= SYSDATE - 7 AND PUBLISHTIME <= SYSDATE

这样的if判断，其实是完全没有必要的,我们可以很简单的采用DECODE来解决默认值问题：

SELECT * FROM T_NEWS_TEXT
WHERE PUBLISHTIME >= DECODE(#{startdate},NULL,SYSDATE-7, #{startdate}) AND PUBLISHTIME <= DECODE(#{enddate},NULL,SYSDATE,#{enddate})

当然有人会想，引入CASE WHEN,DECODE会导致需要ORACLE函数解析，会拖慢SQL执行时间，有兴趣的同学可以回去做一下测试，看看是否会有大的影响。就个人经验而言，在我的开发过程，没有发现因为函数解析导致SQL变慢的情形。影响SQL执行效率的一般情况下是JOIN、ORDER BY、DISTINCT、PARTITATION BY等这些操作，这些操作一般与表结构设计有很大的关联。相对于这些的效率影响程度，函数解析对于SQL执行速度影响应该是可以忽略不计的。 另外一点，对于一些默认值的赋值，像上面那条SQL，默认成当前日期什么的，其实可以完全提到Service层或Controller层做处理，在Mybatis中应该要少用这些判断。因为，这样的话，很难做缓存处理。如果startdate为空，在SQL上使用动态的SYSDATE，就无法确定缓存startdate日期的key应该是什么了。所以参数最好在传递至Mybatis之前都处理好，这样Mybatis层也能减少部分if choose语句，同时也方便做缓存处理。

当然不使用if choose也并不是绝对的，有时候为了优化SQL，不得不使用if来解决，比如说LIKE语句，当然一般不推荐使用LIKE，但如果存在使用的场景，尽可能在不需要使用时候去除LIKE，比如查询文章标题，以提高查询效率。 最好的方式是使用lucence等搜索引擎来解决这种全文索引的问题。

总的来说，if与choose判断分支是不可能完全去除的，但是推荐使用SQL原生的方式来解决一些动态问题，而不应该完全依赖Mybatis来完成动态分支的判断，因为判断分支过于复杂，而且难以维护。

3.用XML注释取代SQL注释。

Mybatis中原SQL的注释尽量不要保留，注释会引发一些问题，如果需要使用注释，可以在XML中用来注释，保证在生成的SQL中不会存在SQL注释，从而降低问题出现的可能性。这样做还有一个好处，就是在IDE中可以很清楚的区分注释与SQL。

现在来谈谈注释引发的问题，我做的一个项目中，分页组件是基于Mybatis的，它会在你写的SQL脚本外面再套一层SELECT COUNT(*) ROWNUM_ FROM (….) 计算总记录数，同时有另一个嵌套SELECT * FROM(…) WHERE ROWNUM > 10 AND RONNUM < 10 * 2这种方式生成分页信息，如果你的脚本中最后一行出现了注释，则添加的部分会成为注释的一部分，执行就会报错。除此之外，某些情况下也可能导致部分条件被忽略，如下面的情况：

SELECT * FROM TEST
WHERE COL1 > 1 -- 这里是注释AND COL2 = #{a}

即使传入的参数中存在对应的参数，实际也不会产生效果，因为后面的内容实际上是被完全注释了。这种错误，如果不经过严格的测试，是很难发现的。一般情况下，XML注释完全可以替代SQL注释，因此这种行为应该可以禁止掉。

4.尽可能使用#{}，而不是${}.

Mybatis中尽量不要使用${}，尽量这样做很方便开发，但是有一个问题，就是大量使用会导致ORACLE的硬解析，拖慢数据库性能，运行越久，数据库性能会越差。对于一般多个字符串IN的处理，可以参考如下的解决方案:http://www.myexception.cn/sql/849573.html，基本可以解决大部分${}. 关于${}，另一个误用的地方就是LIKE，我这边还有个案例：比如一些树型菜单，节点会设计成'01','0101',用两位节点来区分层级，这时候，如果需要查询01节点下所有的节点，最简单的SQL便是:SELECT * FROM TREE WHERE ID LIKE '01%',这种SQL其实无可厚非，因为它也能用到索引，所以不需要特别的处理，直接使用就行了。但如果是文章标题，则需要额外注意了：SELECT * FROM T_NEWS_TEXT WHERE TITLE LIKE '%OSC%'，这是怎么也不会用到索引的，上面说了，最好采用全文检索。但如果离不开LIKE，就需要注意使用的方式： ID LIKE #{ID} || '%'而不是ID LIKE '

有人觉得使用||会增加ORACLE处理的时间，我觉得不要把ORACLE看得太傻，虽然有时候确实非常傻，有空可以再总结ORACLE傻不垃圾的地方，但是稍加测试便知：这种串联方式，对于整个SQL的解析执行，应该是微乎其微的。

当然还有一些特殊情况是没有办法处理的，比如说动态注入列名、表名等。对于这些情况，则比较棘手，没有找到比较方便的手段。由于这种情况出现的可能性会比较少，所以使用ID有人觉得使用∣∣会增加ORACLE处理的时间，我觉得不要把ORACLE看得太傻，虽然有时候确实非常傻，有空可以再总结ORACLE傻不垃圾的地方，但是稍加测试便知：这种串联方式，对于整个SQL的解析执行，应该是微乎其微的。当然还有一些特殊情况是没有办法处理的，比如说动态注入列名、表名等。对于这些情况，则比较棘手，没有找到比较方便的手段。由于这种情况出现的可能性会比较少，所以使用{}倒也不至于有什么太大的影响。当然你如果有代码洁癖的话，可以使用ORACLE的动态执行SQL的机制Execute immediate，这样就可以完全避免${}出现的可能性了。这样会引入比较复杂的模型，这个时候，你就需要取舍了。

针对于以上动态SQL所导致的问题，最激进的方式是全部采用存储过程，用数据库原生的方式来解决，方便开发调试，当然也会带来问题：对开发人员会有更高的要求、存储过程的管理等等，我这边项目没有采用过这种方式，这里不做更多的展开。

5.简单使用Mybatis。

Mybatis的功能相对而言还是比较弱的，缺少了好多必要的辅助库，字符串处理等等，扩展也比较困难，一般也就可能对返回值进行一些处理。因此最好仅仅把它作为单纯的SQL配置文件，以及简单的ORM框架。不要尝试在Mybatis中做过多的动态SQL，否则会导致后续的维护非常恶心。

几点技巧总结；

1、查询很多字段时可以提出来再引入到sql语句

提取： id, type, shopCouId, Path, fromDate, toDate, insDate, insUserId, updDate, updUserId, delFlg

引入： select from adinfo where id = #{id,jdbcType=INTEGER}

2、如果sql语句中需要使用<, >, "" 符号时，需要使用< > " 或者

 CDATA内部所有东西都会被解析器忽略
select type, shopCouId, Path
from adinfo
WHERE delFlg ='0'

and fromDate < #{date} and toDate >= #{date}

3、缓存使用

在增删查改时，可以使用缓存属性控制数据缓存

4、可以判断传进来的参数，再进行操作

and langCd = #{langCd,jdbcType=VARCHAR}

5、可以在sql语句中直接进行加减乘除计算，模糊查询时，需要注意使用方式

SELECT sum(b.netCnt) + #{netCnt,jdbcType=INTEGER}
FROM collectcnt b
WHERE b.shopId = #{shopId,jdbcType=INTEGER}
AND b.delflg = '0'


newCnt = newCnt + 1,
netCnt = netCnt +1,
sumCnt = sumCnt + 1,


AND o.oTime LIKE CONCAT('%',#{sdate},'%')

MyBatis把int类型的0处理成空串’’和mysql处理空串’’为0的问题

当数据库字段类型是整数，如果参数变量为空字符串或者NULL，Mybatis会自动将参数赋值0，所以如果要判断整数参数的多种状态在传递数值到Mapper之前就要判断是否为空字符串和NULL并将相应的状态数值赋值给该参数，否则参数值等于空字符串、NULL和0得到的结果是一样的。

一般情况下，涉及到int类型的操作的时候，在Service中会统一把数字类型先变成字符串类型，然后再传递到Mapper中操作。

案例七：

使用mybatis 进行批量insert的时候 会自动封装成一个map key是list 要存的数据变成了数组 需要注意在xml里面如果使用自己定义的collection要在传参时定义一个mapkey是自己定义的变量名哦。

在使用resultMap的时候，要把ID写在第一行，否则的话，就会报错。

优缺点

总结下mybatis的优缺点，以便大家对于mybatis的了解能更全面些。但我所说的优缺点，仅是我个人总结并结合使用体验后得出的结果，并不能代表大众想法，因此才以“浅谈”作为文章标题。如果大家的见解与我不同，欢迎积极提出来一块讨论，我也借以弥补自己认识的不足和短见。

优点：

1. 易于上手和掌握。
2. sql写在xml里，便于统一管理和优化。
3. 解除sql与程序代码的耦合。
4. 提供映射标签，支持对象与数据库的orm字段关系映射
5. 提供对象关系映射标签，支持对象关系组建维护
6. 提供xml标签，支持编写动态sql。

缺点：

1. sql工作量很大，尤其是字段多、关联表多时，更是如此。
2. sql依赖于数据库，导致数据库移植性差。
3. 由于xml里标签id必须唯一，导致DAO中方法不支持方法重载。
4. 字段映射标签和对象关系映射标签仅仅是对映射关系的描述，具体实现仍然依赖于sql。（比如配置了一对多Collection标签，如果sql里没有join子表或查询子表的话，查询后返回的对象是不具备对象关系的，即Collection的对象为null）
5. DAO层过于简单，对象组装的工作量较大。
6. 不支持级联更新、级联删除。
7. 编写动态sql时,不方便调试，尤其逻辑复杂时。 8 提供的写动态sql的xml标签功能简单（连struts都比不上），编写动态sql仍然受限，且可读性低。
8. 若不查询主键字段，容易造成查询出的对象有“覆盖”现象。
9. 参数的数据类型支持不完善。（如参数为Date类型时，容易报没有get、set方法，需在参数上加@param）
10. 多参数时，使用不方便，功能不够强大。（目前支持的方法有map、对象、注解@param以及默认采用012索引位的方式）
11. 缓存使用不当，容易产生脏数据。

总结：

mybatis的优点其实也是mybatis的缺点，正因为mybatis使用简单，数据的可靠性、完整性的瓶颈便更多依赖于程序员对sql的使用水平上了。sql写在xml里，虽然方便了修改、优化和统一浏览，但可读性很低，调试也非常困难，也非常受限，无法像jdbc那样在代码里根据逻辑实现复杂动态sql拼接。mybatis简单看就是提供了字段映射和对象关系映射的jdbc，省去了数据赋值到对象的步骤而已，除此以外并无太多作为，不要把它想象成hibernate那样强大，简单小巧易用上手，方便浏览修改sql就是它最大的优点了。 mybatis适用于小型且程序员能力较低的项目和人群使用，对于中大型项目来说我并不推荐使用，如果觉得hibernate效率低的话（实际上也是使用不当所致，hibernate是实际上是不适用于拥有高负载的工程项目），还不如直接用spring提供的jdbc简单框架（Template），同样支持对象映射。