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