前言：動態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少少！