mybatis中的小知识

参考的公众号：https://mp.weixin.qq.com/s/ic5IbHnUUOTSc-ajeGk9CQ

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

2.日期问题：

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

3.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中操作。

4.时间戳类型的处理：

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写在第一行，否则的话，就会报错。

int与INteger的拆装箱问题：

前几天在项目中碰到，来说下吧。大神可绕道。在使用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大量的硬解析，也不可取。

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这种方式生成分页信息，如果你的脚本中最后一行出现了注释，则添加的部分会成为注释的一部分，执行就会报错。除此之外，某些情况下也可能导致部分条件被忽略，如下面的情况：

即使传入的参数中存在对应的参数，实际也不会产生效果，因为后面的内容实际上是被完全注释了。这种错误，如果不经过严格的测试，是很难发现的。一般情况下，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, imgPath, fromDate, toDate, insDate, insUserId, updDate, updUserId, delFlg

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

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

CDATA内部所有东西都会被解析器忽略
select type, shopCouId, imgPath 
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的优缺点，以便大家对于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），同样支持对象映射。