1. 項目概述精準控制MyBatis-Plus的日志輸出在基于MyBatis-Plus進行企業級應用開發時日志輸出是一個既基礎又關鍵的環節。尤其是在調試復雜SQL、排查數據問題或者進行性能分析時我們常常需要查看框架執行的SQL語句。然而默認情況下MyBatis-Plus或底層的MyBatis的日志輸出可能會將完整的SQL語句、參數以及龐大的結果集一股腦地打印到控制臺或日志文件中。想象一下當你執行一個SELECT * FROM large_table查詢返回了上千條記錄控制臺瞬間被刷屏不僅難以定位到真正關心的SQL文本還可能因為輸出過多內容而拖慢應用性能甚至在某些日志量計費的云服務場景下造成不必要的成本。因此實現“僅打印SQL不打印Result結果數據”的需求就從一個簡單的配置問題上升為關乎開發效率、系統性能和運維成本的實際工程問題。這個需求的核心在于對MyBatis日志系統的精細化控制。MyBatis-Plus作為MyBatis的增強工具其日志行為本質上繼承并擴展了MyBatis的日志體系。MyBatis通過其內置的日志工廠適配了市面上主流的日志框架如SLF4JLogback、Log4j2、JUL等。當我們設置mybatis-plus.configuration.log-impl或通過其他方式開啟日志后框架會為每個Mapper接口或命名空間創建一個日志記錄器并在執行SQL的不同階段準備語句、設置參數、執行查詢、處理結果輸出不同級別的日志。我們想要攔截的正是那個處理結果集并打印出所有行數據的階段。實現這個目標通常有幾種不同粒度的思路最粗粒度的是全局日志級別控制但這可能把其他有用的調試信息也關掉了最細粒度的是自定義日志實現完全接管日志輸出格式但實現成本較高而最實用、最常用的則是利用MyBatis/MyBatis-Plus提供的現有配置或擴展點對特定類型SELECT查詢或特定Mapper的日志輸出行為進行外科手術式的精準調整。接下來我們就從設計思路開始拆解幾種主流方案并深入實操細節和避坑指南。2. 核心思路與方案選型解析要實現“只打印SQL不打印結果”我們需要先理解MyBatis日志輸出的完整鏈條。一次查詢的日志輸出通常包含以下幾個部分Preparing: 打印即將執行的SQL語句其中參數占位符為?。Parameters: 打印SQL語句中每個占位符對應的實際參數值。Total: 打印該查詢執行所耗費的總時間如果配置了。Result Set: 打印查詢返回的結果集每行數據都會以類似{id1, name‘John’, …}的格式輸出。這正是我們想要屏蔽的部分。因此我們的目標就是在日志輸出鏈條中攔截或禁用“Result Set”部分的打印同時保留前三個部分。這通常需要在日志框架的配置層面或MyBatis的日志實現層面進行操作。2.1 方案一調整日志框架的Logger級別最直接但可能誤傷這是最直觀的想法。MyBatis的日志輸出最終是通過我們項目使用的日志框架如Logback、Log4j2來輸出的。每個Mapper接口在日志框架中對應一個Logger其名稱通常為Mapper接口的全限定名如com.example.mapper.UserMapper。MyBatis在執行不同階段會使用不同的日志級別DEBUG, TRACE等進行記錄。通常“Preparing”和“Parameters”是在DEBUG級別輸出的而“Result Set”的詳細內容往往是在更低的TRACE級別輸出的。操作思路將特定Mapper或全局的日志級別設置為DEBUG而非TRACE。優點配置簡單無需修改代碼通過logback-spring.xml或log4j2.xml即可完成。缺點粒度較粗。如果其他組件或MyBatis本身有在TRACE級別輸出的有用信息例如更詳細的連接池狀態、緩存操作細節這些信息也會被一并屏蔽。這屬于一種“范圍誤傷”。適用場景當你非常確定只需要DEBUG級別的SQL和參數信息且不關心任何TRACE信息時可以采用此方案。它適合作為快速驗證或臨時調試的手段。2.2 方案二配置MyBatis的log-impl并自定義日志實現最靈活但較復雜MyBatis允許我們指定一個自定義的日志實現類。我們可以繼承官方提供的某個日志適配器如Slf4jImpl然后重寫其中打印結果集的方法。操作思路創建一個自定義類繼承自org.apache.ibatis.logging.slf4j.Slf4jImpl假設使用SLF4J。重寫debug方法或相關的結果集打印方法。在MyBatis的日志調用鏈中結果集的打印最終會調用日志實例的某個輸出方法。我們需要找到這個點并進行過濾。在MyBatis配置中將log-impl指向我們這個自定義類。優點控制力極強可以精確到只過濾結果集日志不影響其他TRACE或DEBUG信息。理論上最干凈。缺點實現相對復雜需要深入理解MyBatis內部日志調用機制。并且不同版本的MyBatis其日志類的內部方法可能有所不同存在一定的兼容性維護成本。適用場景對日志輸出有極其精確的控制需求且項目架構允許進行此類底層定制。通常在中大型、對可觀測性要求極高的項目中會考慮。2.3 方案三使用MyBatis-Plus的PerformanceInterceptor或自定義插件推薦平衡方案這是我個人最推薦也是實踐中使用最廣泛的方案。MyBatis-Plus提供了一些內置的插件其中PerformanceInterceptor性能分析攔截器就具備輸出SQL和執行時間的功能。更重要的是我們可以通過自定義插件Interceptor來攔截StatementHandler的query方法在執行完畢后手動輸出我們想要的日志SQL和參數而完全跳過框架默認的結果集打印流程。操作思路關閉MyBatis自帶的詳細日志將日志級別設為WARN或以上或者不配置log-impl從根本上阻止其輸出結果集。創建一個實現MyBatisInterceptor接口的自定義插件。在插件的intercept方法中攔截StatementHandler的query或update方法。在方法執行前后獲取BoundSql對象從中解析出SQL語句和參數然后使用我們自己的日志工具如log.debug按我們喜歡的格式進行打印。將這個插件配置到MyBatis的插件鏈中。優點完全可控日志格式、內容、級別都由我們自己決定。可以輕松實現“只打印SQL和參數”。功能強大插件機制是MyBatis的核心擴展點我們可以在同一插件中輕松集成性能監控、SQL格式化、慢查詢告警等其他功能。無侵入性不需要修改MyBatis的日志實現類通過標準擴展點實現更符合框架設計哲學。缺點需要編寫少量代碼并理解MyBatis插件的基本工作原理。適用場景絕大多數生產環境和需要精細化日志管理的開發環境。它提供了性能、靈活性和可控性的最佳平衡。注意在MyBatis-Plus 3.4.0及以上版本官方推薦使用MybatisPlusInterceptor這個統一攔截器并將各種功能以“內部攔截器”的方式添加進去。但對于自定義日志打印我們依然可以創建獨立的傳統插件并添加到這個統一攔截器之前或之后邏輯是相通的。綜合來看方案三自定義插件因其強大的靈活性和可控性成為解決本需求的首選。接下來我們將深入方案三的實操細節。3. 通過自定義插件實現精準日志控制我們將一步步實現一個自定義的MyBatis插件用于在控制臺或日志文件中打印SQL語句和參數同時避免輸出結果集。3.1 環境準備與依賴確認首先確保你的項目是基于Spring Boot并集成了MyBatis-Plus。一個典型的pom.xml依賴配置如下dependencies !-- Spring Boot Starter -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus Starter -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version !-- 請使用最新穩定版 -- /dependency !-- 數據庫驅動例如MySQL -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 日志框架這里使用Spring Boot默認的Logback -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-logging/artifactId /dependency /dependencies關鍵點在于mybatis-plus-boot-starter它已經包含了MyBatis的所有必要依賴。我們不需要額外引入MyBatis的核心包。3.2 關閉MyBatis原生詳細日志為了避免我們的自定義插件和MyBatis原生日志同時輸出造成重復和混亂第一步是先關閉MyBatis原生的DEBUG/TRACE級別日志。在application.yml或application.properties中進行配置application.yml 示例# 關閉MyBatis原生日志實現防止其輸出結果集 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 可以設置為一個不輸出的實現或者不配置。這里設為StdOutImpl僅作示例實際我們會用插件控制。 # 更推薦的做法是通過全局日志級別控制 logging: level: # 將你的Mapper接口所在包的日志級別設為WARN或ERROR關閉其DEBUG/TRACE輸出 com.yourcompany.yourproject.mapper: WARN # 將MyBatis核心包的日志級別也調高 org.apache.ibatis: WARN java.sql: WARN # 也可以關閉JDBC的日志通過將Mapper包和MyBatis核心包的日志級別設為WARN我們有效地禁用了它們DEBUG和TRACE級別的輸出其中就包含了我們不想要的結果集打印。3.3 創建自定義SQL日志打印插件現在我們來創建核心的自定義插件。這個插件將攔截所有執行的SQL語句。package com.yourcompany.yourproject.plugin; import lombok.extern.slf4j.Slf4j; import org.apache.ibatis.executor.statement.StatementHandler; import org.apache.ibatis.mapping.BoundSql; import org.apache.ibatis.mapping.ParameterMapping; import org.apache.ibatis.plugin.*; import org.apache.ibatis.reflection.MetaObject; import org.apache.ibatis.reflection.SystemMetaObject; import org.apache.ibatis.session.Configuration; import org.apache.ibatis.type.TypeHandlerRegistry; import org.springframework.stereotype.Component; import java.lang.reflect.Method; import java.sql.Statement; import java.util.List; import java.util.Properties; /** * 自定義SQL日志打印插件 * 攔截StatementHandler的prepare和parameterize方法打印SQL和參數 */ Intercepts({ Signature(type StatementHandler.class, method prepare, args {java.sql.Connection.class, Integer.class}), Signature(type StatementHandler.class, method parameterize, args {Statement.class}) }) Component Slf4j // 使用Lombok的Slf4j注解確保插件使用項目統一的日志框架 public class SqlLoggerInterceptor implements Interceptor { Override public Object intercept(Invocation invocation) throws Throwable { // 1. 獲取被攔截的目標對象 StatementHandler statementHandler (StatementHandler) invocation.getTarget(); MetaObject metaObject SystemMetaObject.forObject(statementHandler); // 2. 獲取BoundSql它包含了SQL語句和參數映射信息 BoundSql boundSql statementHandler.getBoundSql(); Configuration configuration (Configuration) metaObject.getValue(delegate.configuration); // 3. 獲取方法名區分是prepare階段還是parameterize階段 Method method invocation.getMethod(); String methodName method.getName(); Object returnValue null; if (prepare.equals(methodName)) { // prepare階段可以獲取到原始的帶占位符的SQL String rawSql boundSql.getSql(); log.debug( Preparing: {}, formatSql(rawSql)); } else if (parameterize.equals(methodName)) { // parameterize階段參數已設置可以獲取到完整的帶參數的SQL // 注意直接獲取到的sql可能還是帶?的我們需要自己拼接參數 String sql boundSql.getSql(); Object parameterObject boundSql.getParameterObject(); ListParameterMapping parameterMappings boundSql.getParameterMappings(); // 格式化SQL將?替換為實際參數值 String formattedSql formatSqlWithParameters(sql, parameterObject, parameterMappings, configuration); log.debug( Parameters: {}, formattedSql); // 也可以選擇在這里打印最終SQL但注意參數可能包含敏感信息 // log.debug( Executing SQL: {}, formatFinalSql(sql, parameterObject, parameterMappings, configuration)); } // 4. 繼續執行原方法鏈 returnValue invocation.proceed(); // 5. 如果需要可以在執行后打印影響行數或時間需額外攔截update/query方法 // 本例專注于打印SQL和參數結果集打印已被我們忽略 return returnValue; } /** * 格式化原始SQL美化換行等 */ private String formatSql(String sql) { return sql.replaceAll([\\s], ).trim(); } /** * 將SQL中的占位符?替換為實際的參數值用于DEBUG查看 * 注意此方法僅用于日志輸出不能用于實際執行且需處理參數類型轉換。 */ private String formatSqlWithParameters(String sql, Object parameterObject, ListParameterMapping parameterMappings, Configuration configuration) { if (parameterMappings null || parameterMappings.isEmpty() || parameterObject null) { return sql; } TypeHandlerRegistry typeHandlerRegistry configuration.getTypeHandlerRegistry(); StringBuilder sqlBuilder new StringBuilder(sql); // 這里是一個簡化的實現實際參數替換邏輯更復雜需要考慮多個參數、IN列表等。 // 更健壯的做法可以參考MyBatis自帶的ParameterHandler邏輯或者使用第三方工具。 // 此處僅作演示將參數以JSON格式附在SQL后面而不是替換?。 try { // 使用Fastjson、Jackson或Gson將參數對象轉換為字符串 // 示例String paramsJson JSON.toJSONString(parameterObject); // 為了簡單這里直接調用toString() String paramsStr parameterObject.toString(); // 避免輸出過長可以截斷 if (paramsStr.length() 500) { paramsStr paramsStr.substring(0, 500) ... [truncated]; } return sql -- Params: paramsStr; } catch (Exception e) { return sql -- [Parameter display error]; } } Override public Object plugin(Object target) { // 使用MyBatis提供的Plugin.wrap方法來創建代理對象 return Plugin.wrap(target, this); } Override public void setProperties(Properties properties) { // 可以從配置文件中讀取插件屬性此處暫無需求 } }代碼關鍵點解析Intercepts 和 Signature這是定義MyBatis插件攔截點的核心注解。我們攔截了StatementHandler接口的兩個方法prepare準備語句和parameterize設置參數。這是打印SQL和參數的最佳時機。獲取BoundSqlBoundSql對象是MyBatis中承載一次SQL執行所有信息的核心對象包括SQL文本、參數對象、參數映射列表。區分階段在prepare階段我們打印出原始的、帶?的SQL語句 Preparing:。在parameterize階段我們嘗試獲取并格式化參數信息 Parameters:。日志級別我們使用log.debug()進行輸出。這意味著你需要在日志配置中為這個插件類com.yourcompany.yourproject.plugin.SqlLoggerInterceptor或它的包開啟DEBUG級別日志才會被打印出來。不打印結果集插件根本沒有攔截結果集處理的步驟如ResultSetHandler的handleResultSets方法所以自然就不會打印結果集。這正是我們想要的效果。3.4 配置與啟用自定義插件在Spring Boot中我們需要將自定義插件注冊到MyBatis的插件鏈中。由于我們使用了Component注解Spring會自動管理這個Bean。但是我們需要確保它被添加到MyBatis的配置里。創建一個配置類package com.yourcompany.yourproject.config; import com.yourcompany.yourproject.plugin.SqlLoggerInterceptor; import com.baomidou.mybatisplus.extension.plugins.MybatisPlusInterceptor; import com.baomidou.mybatisplus.extension.plugins.inner.PaginationInnerInterceptor; // 分頁插件示例 import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class MyBatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); // 添加分頁插件這是MyBatis-Plus的常用插件 interceptor.addInnerInterceptor(new PaginationInnerInterceptor()); // 注意我們的SqlLoggerInterceptor是傳統的Interceptor // 需要單獨添加到SqlSessionFactory中而不是加到這里。 return interceptor; } /** * 單獨注冊我們的自定義SQL日志插件。 * 另一種方式是在SqlLoggerInterceptor類上直接使用Bean注解。 * 這里顯式聲明是為了更清晰地控制。 */ Bean public SqlLoggerInterceptor sqlLoggerInterceptor() { return new SqlLoggerInterceptor(); } }重要提示在Spring Boot MyBatis-Plus環境中只要插件類被Spring容器管理即加了Component或BeanMyBatis的自動配置機制通常會自動發現并注冊所有實現了Interceptor接口的Bean。所以上面的sqlLoggerInterceptor()Bean方法有時不是必須的Component注解可能就足夠了。但顯式聲明是一個好習慣可以避免因依賴掃描順序導致的問題。3.5 配置日志輸出級別最后我們需要在application.yml中配置日志確保我們的插件能輸出日志而其他干擾日志被關閉。logging: level: # 1. 關閉MyBatis和JDBC的詳細日志防止結果集輸出 org.apache.ibatis: WARN java.sql: WARN java.sql.Connection: WARN java.sql.Statement: WARN java.sql.PreparedStatement: WARN java.sql.ResultSet: WARN # 2. 關閉你項目Mapper接口的詳細日志防止和插件輸出重復 com.yourcompany.yourproject.mapper: WARN # 3. 為你自定義的插件類開啟DEBUG日志這樣我們打印的SQL才會顯示 com.yourcompany.yourproject.plugin.SqlLoggerInterceptor: DEBUG # 4. 如果你想知道插件是否被加載可以將其級別設為INFO或DEBUG com.yourcompany.yourproject.plugin: DEBUG pattern: console: %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n這個配置實現了精準控制第1、2步關閉了所有可能輸出結果集和冗余SQL信息的源頭。第3步只為我們自定義的插件打開了DEBUG通道讓它能輸出我們精心格式化的“Preparing”和“Parameters”日志。啟動你的Spring Boot應用執行一個查詢操作你將在控制臺看到類似如下的輸出并且絕對不會出現結果集數據2023-10-27 14:30:25.123 [http-nio-8080-exec-1] DEBUG c.y.y.p.SqlLoggerInterceptor - Preparing: SELECT id, username, email FROM user WHERE age ? 2023-10-27 14:30:25.124 [http-nio-8080-exec-1] DEBUG c.y.y.p.SqlLoggerInterceptor - Parameters: SELECT id, username, email FROM user WHERE age ? -- Params: 184. 高級優化與生產實踐基礎的插件已經能工作但在生產環境中我們還需要考慮更多細節。4.1 優化SQL參數格式化上面的示例中formatSqlWithParameters方法實現得很簡單只是將參數對象的toString()結果附在后面。這對于簡單類型如Integer, String尚可但對于復雜對象、集合如List用于IN查詢或Map輸出可讀性很差。一個更專業的做法是模擬MyBatis內置的日志實現將SQL中的?逐個替換為格式化的參數值。這里提供一個增強版的格式化方法思路private String formatSqlWithParametersEnhanced(String sql, Object parameterObject, ListParameterMapping parameterMappings, Configuration configuration) { if (parameterMappings null || parameterMappings.isEmpty()) { return sql; } TypeHandlerRegistry typeHandlerRegistry configuration.getTypeHandlerRegistry(); StringBuilder formattedSql new StringBuilder(); int index 0; int paramIndex 0; String sqlText sql; // 遍歷SQL字符串找到?并替換 for (ParameterMapping mapping : parameterMappings) { int qIndex sqlText.indexOf(?, index); if (qIndex -1) { break; } formattedSql.append(sqlText, index, qIndex); // 追加?之前的部分 // 獲取參數值 Object value; String propertyName mapping.getProperty(); if (boundSql.hasAdditionalParameter(propertyName)) { value boundSql.getAdditionalParameter(propertyName); } else if (parameterObject null) { value null; } else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) { value parameterObject; } else { // 從參數對象中獲取屬性值這里簡化了實際需處理復雜對象圖 MetaObject metaObject configuration.newMetaObject(parameterObject); value metaObject.getValue(propertyName); } // 格式化參數值用于顯示 formattedSql.append(formatParameterValue(value)); index qIndex 1; paramIndex; } formattedSql.append(sqlText.substring(index)); // 追加剩余部分 return formattedSql.toString(); } private String formatParameterValue(Object value) { if (value null) { return null; } if (value instanceof String || value instanceof Character) { return value.toString().replace(, ) ; } if (value instanceof Date) { return new SimpleDateFormat(yyyy-MM-dd HH:mm:ss).format((Date) value) ; } // 其他類型直接返回字符串形式 return value.toString(); }注意上述增強格式化邏輯較為復雜且需要處理BoundSql的additionalParameters等細節。在實際項目中如果你需要完美的參數替換效果可以考慮直接使用MyBatis內置的ParameterHandler邏輯或者參考開源項目如p6spy的思路。對于大多數調試場景將參數以JSON形式附在SQL后面如初始示例已經足夠清晰。4.2 集成性能監控與慢查詢日志既然我們已經有了一個插件攔截了SQL執行很容易就能擴展其功能例如添加執行時間計算實現慢查詢警告。修改SqlLoggerInterceptor的intercept方法我們主要攔截StatementHandler的query或update方法這需要修改Signature并在方法執行前后記錄時間。更簡單的方式是我們可以創建一個獨立的性能監控插件。這里展示如何在一個插件里集成簡單計時Intercepts({ Signature(type StatementHandler.class, method update, args {Statement.class}), Signature(type StatementHandler.class, method query, args {Statement.class, ResultHandler.class}) }) public class PerformanceAndSqlLoggerInterceptor implements Interceptor { private static final long SLOW_QUERY_THRESHOLD_MS 1000; // 慢查詢閾值1秒 Override public Object intercept(Invocation invocation) throws Throwable { long startTime System.currentTimeMillis(); // ... (這里可以調用之前的邏輯打印SQL或獨立打印) ... StatementHandler handler (StatementHandler) invocation.getTarget(); BoundSql boundSql handler.getBoundSql(); String sql boundSql.getSql(); log.debug(Executing SQL: {}, formatSql(sql)); Object result invocation.proceed(); // 執行SQL long endTime System.currentTimeMillis(); long cost endTime - startTime; if (cost SLOW_QUERY_THRESHOLD_MS) { log.warn(Slow SQL detected! Cost: {} ms, SQL: {}, cost, formatSql(sql)); } else { log.debug(SQL executed. Cost: {} ms, cost); } // 關鍵不打印result對象本身 return result; } // ... plugin, setProperties 方法 ... }這個插件在查詢/更新執行后計算耗時并對慢查詢進行WARN級別的報警同時依然不輸出結果集內容。4.3 敏感信息脫敏處理在生產環境中SQL日志可能包含敏感信息如手機號、郵箱、身份證號等。直接在日志中打印這些數據是危險的。我們需要在插件中對參數值進行脫敏。可以在formatParameterValue方法中加入脫敏邏輯private String formatParameterValue(Object value) { if (value null) { return null; } String strValue value.toString(); // 簡單示例對可能是手機號、郵箱的參數進行脫敏這里需要更精確的字段名判斷 // 實際項目中可以維護一個需要脫敏的字段名列表或正則規則 // 假設通過某種方式如解析ParameterMapping的property知道當前參數對應字段名 String fieldName getCurrentFieldName(); // 這是一個需要實現的方法 if (fieldName ! null (fieldName.contains(phone) || fieldName.contains(mobile))) { // 手機號脫敏138****1234 if (strValue.length() 11) { return strValue.substring(0, 3) **** strValue.substring(7) ; } } if (fieldName ! null fieldName.contains(email)) { // 郵箱脫敏a***example.com int atIndex strValue.indexOf(); if (atIndex 1) { return strValue.charAt(0) *** strValue.substring(atIndex) ; } } // ... 其他類型格式化 ... return strValue ; }實操心得脫敏邏輯的復雜性取決于你的需求。一種更通用的做法是在插件中不直接進行復雜的脫敏而是將原始SQL和參數記錄下來發送到專門的安全日志處理服務如ELK棧并配置脫敏管道在存儲和展示前進行統一的脫敏處理。這樣業務代碼更干凈脫敏規則也更容易集中管理。5. 常見問題排查與解決方案實錄在實際配置和使用過程中你可能會遇到以下問題5.1 插件不生效沒有日志輸出可能原因及排查步驟插件未正確注冊確保你的插件類被Spring容器管理有Component或Bean注解并且所在的包在Spring Boot的主應用掃描路徑下。可以通過在插件的構造方法或PostConstruct方法中打日志來驗證是否被實例化。日志級別配置錯誤這是最常見的原因。檢查application.yml中logging.level下的配置。確保你的插件類如com.yourcompany.yourproject.plugin.SqlLoggerInterceptor的日志級別是DEBUG或TRACE。同時確保全局的日志框架如Logback的根級別沒有覆蓋為ERROR。MyBatis-Plus版本兼容性不同版本的MyBatis-Plus對插件的自動注冊機制可能有細微差別。如果懷疑是此問題可以嘗試在配置類中顯式地將插件添加到SqlSessionFactoryBean中。Bean public SqlSessionFactory sqlSessionFactory(DataSource dataSource, SqlLoggerInterceptor sqlLoggerInterceptor) throws Exception { MybatisSqlSessionFactoryBean factoryBean new MybatisSqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); // 手動添加攔截器 factoryBean.setPlugins(new Interceptor[]{sqlLoggerInterceptor}); return factoryBean.getObject(); }多個插件沖突如果你配置了多個MyBatis插件如分頁插件、樂觀鎖插件需要確保它們的執行順序不會導致某個插件“吃掉”異常或改變執行流程。通常日志插件應該放在插件鏈的最外層最先執行。5.2 日志輸出重復SQL被打印兩次可能原因及排查步驟MyBatis原生日志未關閉你雖然配置了自定義插件但MyBatis原生的log-impl例如StdOutImpl或Slf4jImpl仍然在工作并且其日志級別也是DEBUG。這會導致SQL被打印兩次一次來自你的插件一次來自MyBatis自身。解決方案確保在application.yml中將mybatis-plus.configuration.log-impl設置為一個不輸出的實現或者不配置使用默認的空實現并且將org.apache.ibatis和java.sql相關Logger的級別設為WARN如上文配置所示。多個自定義日志插件檢查是否無意中創建了多個功能相似的插件或者將插件注冊了多次。5.3 參數格式化顯示為null或不正確可能原因及排查步驟參數對象為null如果執行的SQL沒有參數parameterObject可能為null。參數映射復雜對于動態SQL如if標簽、foreach循環用于IN查詢或嵌套參數對象BoundSql中的parameterMappings和parameterObject結構會變得復雜。上面提供的簡單格式化方法無法正確處理這些情況。解決方案對于生產環境如果對參數可讀性要求高建議采用更穩健的方案方案A使用第三方SQL打印工具如p6spy。它可以無縫集成提供非常完善的SQL格式化包含參數替換并且完全獨立于MyBatis的日志系統。方案B只打印帶?的SQL和參數對象的JSON快照就像我們第一個簡單示例那樣。雖然不夠完美但足夠用于大多數調試場景且實現簡單穩定。方案C深入研讀MyBatis源碼實現一個能處理所有復雜情況的參數提取器。這需要投入較多精力。5.4 性能影響可能原因及排查步驟DEBUG日志開銷即使日志最終不被輸出因為Appender配置判斷日志級別isDebugEnabled()和拼接參數字符串尤其是復雜對象的JSON序列化本身也有開銷。解決方案在插件的日志輸出前使用if (log.isDebugEnabled())進行判斷避免不必要的字符串拼接。在生產環境中通過日志配置將插件類的日志級別設為INFO或WARN徹底關閉SQL打印功能。考慮使用異步日志框架如Log4j2的AsyncLogger來減少I/O阻塞對業務線程的影響。插件本身邏輯復雜如果插件的intercept方法里做了太多事情如復雜的脫敏、遠程調用等會影響每個SQL的執行速度。解決方案保持插件邏輯精簡。將非關鍵操作如慢查詢統計的聚合上報、脫敏字典查詢改為異步或批量處理。我個人在實際項目中的體會是通過自定義插件控制SQL日志輸出是一個一勞永逸的解決方案。初期搭建需要花費一些時間理解MyBatis的攔截器機制和日志框架配置但一旦配置成功它帶來的整潔日志、可控輸出和強大的擴展能力如集成慢查詢監控會讓日常開發和運維排查效率大幅提升。最關鍵的是它完美地解決了“結果集刷屏”這個痛點讓日志文件重新變得清晰可讀。在配置過程中務必記得“關閉其他只開自己”的日志級別配置原則這是避免日志混亂的關鍵。