前言：动态SQL调试的痛与解决方案

作为一名CRUD工程师，我们每天都在与MyBatis-Plus打交道。MP的动态SQL功能确实强大，一个LambdaQueryWrapper就能轻松搞定复杂的条件查询。但不知道你有没有遇到过这种情况：明明代码逻辑看起来没问题，可就是查不出数据，或者查询结果不符合预期。这时候如果能看到MP实际生成的SQL语句，问题可能就迎刃而解了。

今天就跟大家分享一下，如何在IDEA中通过断点调试，直观地查看MyBatis-Plus动态生成的SQL语句，以及一些实用技巧和避坑指南。亲测有效，建议收藏备用！

一、准备工作：调试前的检查清单

在开始调试之前，我们需要确保几件事：

1. MyBatis-Plus版本：建议使用3.5.x以上版本，我目前用的是3.5.1，功能比较完善。

2. 项目调试配置：确保你的Spring Boot项目已经配置了正确的调试启动项。在IDEA右上角的运行配置中，检查是否勾选了"Debug"模式。

3. 依赖检查：pom.xml中需要包含MyBatis-Plus的依赖：

<dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</artifactId><version>3.5.1</version>
</dependency>

4. 调试环境：最好使用本地开发环境，避免直接在生产/测试环境调试，以防意外。

二、基础方法：SqlSessionTemplate断点调试

这是最直接有效的方法，也是我日常开发中用得最多的方式。话不多说，直接上步骤：

步骤1：定位SqlSessionTemplate类

在IDEA中，按下Ctrl+N（Mac用户Cmd+O）打开类搜索框，输入SqlSessionTemplate，找到org.mybatis.spring.SqlSessionTemplate这个类。

小贴士：如果记不住完整类名，也可以只输入"SqlSession"，IDEA会智能提示相关类。

步骤2：在invoke方法上设置断点

打开SqlSessionTemplate类后，找到invoke方法。这个方法是MyBatis执行SQL的关键入口。在方法名左侧的 gutter 区域点击一下，设置一个断点。

步骤3：启动调试并触发SQL执行

以调试模式启动你的应用（IDEA中点击那个绿色的小虫子图标），然后操作相关功能，触发你想要调试的SQL语句执行。

当程序执行到刚才设置的断点时，IDEA会自动暂停，进入调试视图。

步骤4：查看生成的SQL语句

根据图中的步骤一步一步往下找，就能找到MP生成的SQL语句啦

小技巧：可以将常用变量添加到监视列表，下次调试时直接查看。

三、MyBatis-Plus增强：特殊场景处理

MP相比原生MyBatis提供了更多便利功能，但在调试时也有一些特殊情况需要注意：

3.1 BaseMapper接口方法调试

当调用MP提供的BaseMapper接口方法（如selectById、selectList等）时，断点同样会触发。但需要注意的是，MP会自动生成方法名对应的SQL，这些SQL是动态生成的，可能不在你的XML文件中。

例如调用userMapper.selectList(wrapper)时，生成的SQL会根据wrapper中的条件动态拼接。这时候查看BoundSql的sql属性，就能清晰地看到拼接后的完整SQL。

3.2 自定义SQL与XML混合调试

如果你项目中既有MP的LambdaQueryWrapper，又有自定义的XML SQL语句，调试方法是通用的。但需要注意：

• 自定义XML中的SQL：可以直接在XML文件中点击右键，选择"Go to Declaration"跳转到对应的方法
• 注解方式的SQL：如@Select("select * from user where id = #{id}")，可以直接在注解上设置断点

3.3 条件构造器的SQL预览

对于复杂的LambdaQueryWrapper，我有个小技巧：在代码中临时添加一行System.out.println(wrapper.getSqlSegment())，可以打印出条件部分的SQL片段。虽然不是完整SQL，但对于调试条件拼接很有帮助。

LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(User::getId, 1).like(User::getName, "张三").orderByDesc(User::getCreateTime);
// 临时添加，调试用
System.out.println("SQL条件片段：" + wrapper.getSqlSegment());
List<User> userList = userMapper.selectList(wrapper);

四、高级技巧：让调试效率翻倍

掌握了基础方法后，这些高级技巧能让你的调试效率大大提升：

4.1 使用条件断点，避免频繁暂停

如果你只想调试某个特定的SQL，可以设置条件断点：右键点击断点图标，选择"Edit Breakpoint"，在Condition中输入判断条件。

例如，只想调试用户相关的SQL：

method.getName().contains("user")

或者根据SQL的ID进行过滤：

args[0].toString().contains("com.example.mapper.UserMapper.selectById")

这样只有满足条件的SQL执行时才会触发断点，避免了调试过程中频繁暂停的烦恼。

4.2 表达式求值，动态查看变量

在调试过程中，可以随时按下Alt+F8（Mac用户Option+F8）打开表达式求值窗口，输入任何你想查看的变量或表达式，IDEA会实时计算并显示结果。

比如直接输入boundSql.getSql()，就能立即看到生成的SQL，非常方便。

4.3 保存断点配置，一键复用

如果你经常需要调试SQL，可以将常用的断点配置保存起来：在Breakpoints窗口（Ctrl+Shift+F8）中，选中你设置的SQL调试断点，点击"Save"按钮，起个名字保存。下次需要时直接"Load"即可，无需重复设置。

五、避坑指南：常见问题与解决方案

5.1 断点不触发怎么办？

这是最常见的问题，可能有以下几个原因：

1. 类路径不对：确认你断点设置的SqlSessionTemplate是项目实际使用的那个，有时候可能存在多个版本的MyBatis包。

2. 方法没被调用：检查你的代码逻辑，确保你要调试的SQL确实被执行了。有时候可能因为条件判断导致代码没有走到。

3. 调试模式没启动：确认你是用调试模式启动的应用，而不是普通运行模式。

4. 断点被禁用：检查断点图标是不是灰色的（被禁用了），点击一下让它变成红色即可。

5.2 SQL语句显示不完整或有问号？

这是因为MyBatis的SQL中使用了占位符?，实际参数值需要单独查看。在BoundSql对象中，parameterObject属性就是参数值，或者查看getParameterMappings()方法的返回结果。

如果你想看到带参数的完整SQL，可以使用下面这个小工具类（我自己写的，很好用）：

public class SqlUtils {public static String showSql(Configuration configuration, BoundSql boundSql) {// 实现代码略，主要功能是将?替换成实际参数值// 完整代码可以在我的GitHub上找到：https://github.com/xxx/utils}
}

5.3 调试影响性能怎么办？

长时间的调试可能会影响应用性能，特别是在循环中执行的SQL。这时候可以：

1. 使用条件断点，只在需要时触发
2. 调试完成后及时移除或禁用断点
3. 避免在生产环境进行长时间调试

六、总结与扩展

掌握MyBatis-Plus动态SQL的调试技巧，能帮我们快速定位问题，提高开发效率。本文介绍的通过IDEA断点调试查看SQL的方法，是我日常工作中最常用也最有效的方式。

除了这种方法，还有一些其他工具也可以查看MyBatis生成的SQL，比如：

• MyBatis Log Plugin：IDEA插件，能自动格式化并输出MyBatis执行的SQL
• p6spy：一个SQL拦截器，能记录所有执行的SQL语句
• MP的内置日志：通过配置日志级别，让MP输出执行的SQL

但这些方法要么需要额外配置，要么会输出大量日志，不如断点调试来得直接和灵活。

最后，送大家一句我很喜欢的话：“工欲善其事，必先利其器”。掌握好调试技巧，能让我们的开发之路走得更顺畅。希望本文对你有帮助，祝大家调试愉快，Bug少少！