Mybatis基础02

1 随机的获取数据库的某几条数据可以：select * from category order by RAND() LIMIT 0,2;

2 mysql:方法一:通过mysql建立索引,比如用户名不能重复,则将用户名字段建立Unique类型的索引 方法二:程序判断喽,select一下是否存在----------:

3 唯一约束.你触发一次数据库查询

###### 如果是先查询在插入至少要 4 次网络 IO, 还可能会产生磁盘 IO

都是严重拖慢性能的东西.

当然,如果你的业务也就几千条数据,那么无所谓了~你用着爽就行

4 sql语句查询出来的这个字段名必须和dto的参数名一致，改成这样就通过了，

5 tinyint本来以为用来表示比较小的整数，结果生成了布尔型的属性。后来就表示是和否才用tinyint了。逆向生成的sql语句绝对不能人为改动，否则再次生成的时候会重复生成。但是，尽管踩过坑，我还是觉得mybatis超级好用，比hibernate好多了。虽然hibernate我只试过一点之后就完全转向了mybatis了。

6 *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中操作。**

7 在创建新记录的时候把这个字段设置为当前时间，但以后修改时，不再刷新它(可以给createtime使用这个)：TIMESTAMP DEFAULT CURRENT_TIMESTAMP
在创建新记录和修改现有记录的时候都对这个数据列刷新(可以给update使用这个)：
TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
在使用resultMap的时候，要把ID写在第一行，否则的话，就会报错。

8 如果你写了resultType为Integer，然后在业务代码中很自然的用一个变量int去接当前这个方法的返回，如果按照你传入的条件在数据库中没有找到相关的值，此时selectOne方法的返回值会是一个null，当你使用Java的自动拆箱机制的时候会报出一个无情的NPE。

原因：Java在自动拆箱的时候会调用Integer类中的intValue方法，如果当前对象为null，则抛出NPE。
因此，在接受的时候要判空，否则可能异常。

9 **多参数的使用

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

1 对象映射，建立一个Java对象，并作为接口的参数，对象的属性可以直接使用#{属性名}的方式访问；

2 Map, 参数为一个Map, key对于属性名，value对于参数值，这个方法就是传参数是需要建立一个Map的临时对象

3 @param参数注解，在接口方法参数前加入参数名称注解，这样就可以直接在Mapper中通过参数名访问
通过序号访问，第一个参数#{0}或#{param1}, 第二个参数#{1}, #{param2}

MyBatis中时间字段的使用–返回
时间字段的返回目前笔者采用放回字符串的方式：
date_format(update_time, ‘%Y-%c-%d %H:%i:%s’) updatetime

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

MyBatis中时间字段的使用–写入
写入可是直接写入Timestamp的数据，需要描述一些写入的jdbcType，如下：
{installTime, jdbcType=TIMESTAMP}**

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

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

12 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，否则会导致后续的维护非常恶心。