先讲一下我们问题的背景：
在使用一些ORM框架（例如hibernate mybatis等等），甚至在ORM框架基础上使用一些快速构建工具（比如mybatis的通用mapper工具mybatis-tk）的时候，由于我们对框架和工具的不熟悉，有时候在调试上就带来了很大的困难。
ORM的特点之一就是对我们应用层开发人员屏蔽SQL语言，例如对于本来的SQL语句select * from user where id = #{id}，我们开发者只需要用一个selectByPrimaryKey(int id)方法就可以实现。
但在实际开发中，有时候我们可能会需要做一些错综复杂的查询，而不是像上例中如此简单。当我们使用一些方法，借助ORM来进行SQL语言拼接的时候，就时常会导致不理想的拼接结果，致使最终查询结果不对甚至直接报错。
那么怎样解决这个问题呢？
可以想到的一个办法，我们去研究框架or工具的源码，看看它内部是如何做SQL拼接的……
好吧这太反人类了。
那我们还可以采用一种迂回的方式，就是跳过寻找框架的SQL拼接逻辑，而是找出它的SQL拼接结果。
那么怎么查看SQL拼接结果呢？
框架和工具显然是没有提供这种功能的，所以我们从MySQL入手。
MySQL有一个日志表，可以把历史中执行过哪些SQL语句存储起来。但是默认这个功能是不开启的，因为如果记录所有历史查询SQL语句的话存储量太大了。
需要调试的时候，我们来输入命令开启这个功能：
//日志开启（日志输出到表：mysql.general_log）
SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = 'ON';
然后我们可以调用我们的应用程序，由框架或工具拼接SQL语句并执行。
接下来打开我们mysql数据库中的general_log表，可以看到有这样一些信息。
（这里笔者使用的是navicat可视化工具。用命令行来查看也不影响）
我们看argument字段，点击一下，并单击“备注”，可以看到具体执行的SQL语句。
在这里，其实也就可以找到我们的SQL拼接结果。有了结果，再回过头去检查我们的应用层代码是不是要做出一些修改，就能顺利许多。
最后，在调试结束后别忘记关掉这个日志功能，不然信息量太大：
SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = 'OFF';
再补充一个小tip，如果你要清空general_log的话，要用以下语句：
truncate table mysql.general_log;
这是因为在我们的日志表中不能加锁，而delete操作是需要加锁的，所以只能使用truncate。
（当然如果你硬要修改事务隔离级别也可以）
