mybatis攔截器實現分頁的核心在于利用其動態修改sql的能力，通過以下步驟構建通用分頁插件：1. 定義page類封裝分頁參數；2. 實現interceptor接口并攔截statementhandler的prepare方法；3. 通過反射獲取mappedstatement和boundsql對象；4. 判斷是否需要分頁處理；5. 構建count查詢獲取總記錄數；6. 根據數據庫類型生成分頁sql；7. 替換原始sql并放行執行。該方式相比其他方案更優雅，具備解耦性強、通用性高、性能優、控制粒度細等優勢，尤其避免了rowbounds內存分頁的效率問題，并支持多數據庫方言適配。核心技術點包括sql解析與重寫、數據庫方言抽象設計、反射操作內部字段及參數處理，挑戰在于復雜sql兼容性、count查詢性能優化、事務隔離影響和mybatis版本升級帶來的維護成本。在spring boot中集成時，需將插件聲明為bean并通過配置注冊，業務層使用時只需傳入page對象即可完成自動分頁邏輯。
MyBatis插件實現分頁的核心在于利用其攔截器（Interceptor）機制，在SQL執行前動態地修改sql語句，加入分頁邏輯（如LIMIT/OFFSET），并同時執行一個COUNT查詢來獲取總記錄數。這種方式能夠將分頁邏輯從業務代碼中徹底解耦，實現通用且靈活的分頁解決方案，同時兼顧不同數據庫的方言差異。
解決方案
要構建一個完整的MyBatis分頁插件，我們通常會遵循以下步驟和核心邏輯：
-
定義分頁參數對象： 創建一個Page類，包含pageNum（當前頁碼）、pageSize（每頁大小）、total（總記錄數）和list（當前頁數據列表）等屬性。這個對象將作為方法參數或通過特定方式傳遞給插件。
-
實現MyBatis Interceptor 接口： 這是插件的核心。我們需要攔截StatementHandler的prepare方法。
- 注解攔截點： 使用@Intercepts和@Signature注解指定攔截的目標對象（StatementHandler）和方法（prepare）。prepare方法是MyBatis準備SQL語句的關鍵環節。
- 獲取原始信息： 在intercept方法中，通過反射獲取StatementHandler內部的MappedStatement（包含SQL語句ID、結果映射等）和BoundSql（包含原始SQL、參數等）。
- 判斷是否需要分頁： 根據MappedStatement的ID約定（例如，以ByPage結尾）或檢查方法參數中是否存在我們定義的分頁Page對象，來決定是否對當前SQL進行分頁處理。
- 構建并執行總記錄數查詢：
- 從原始SQL中提取出用于計數的部分（通常是去除ORDER BY、LIMIT等，包裹在select COUNT(*) FROM (…) AS total中）。
- 創建一個新的MappedStatement和BoundSql來執行這個COUNT SQL。
- 利用MyBatis的Executor執行這個COUNT查詢，獲取總記錄數。
- 將總記錄數設置到傳入的Page對象中。
- 構建分頁SQL： 根據當前數據庫類型（mysql、oracle、postgresql等），將原始SQL改寫為帶有分頁子句（如LIMIT offset, limit）的SQL。這通常需要一個“數據庫方言”抽象。
- 替換原始SQL： 使用反射將BoundSql中的原始SQL替換為分頁后的SQL。
- 放行： 調用invocation.proceed()讓MyBatis繼續執行修改后的SQL。
- plugin方法： 實現plugin方法，判斷目標對象是否是StatementHandler，如果是則使用Plugin.wrap包裝目標對象。
- setProperties方法： 用于接收配置屬性，例如數據庫方言類型。
-
配置插件： 在MyBatis的配置文件（如mybatis-config.xml或spring boot的application.yml）中注冊這個攔截器。
核心代碼結構示意 (簡化版，僅展示關鍵邏輯點):
@Intercepts({@Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class})}) public class PaginationInterceptor implements Interceptor { private String databaseType; // 例如：mysql, oracle @Override public Object intercept(Invocation invocation) throws Throwable { StatementHandler statementHandler = (StatementHandler) invocation.getTarget(); MappedStatement mappedStatement = (MappedStatement) ReflectUtil.getFieldValue(statementHandler, "mappedStatement"); BoundSql boundSql = statementHandler.getBoundSql(); Object parameterObject = boundSql.getParameterObject(); // 檢查參數中是否包含Page對象，或者根據MappedStatement ID判斷 Page<?> page = findPageObject(parameterObject); if (page == null) { return invocation.proceed(); // 不進行分頁 } String originalSql = boundSql.getSql(); Connection connection = (Connection) invocation.getArgs()[0]; // 1. 執行總記錄數查詢 String countSql = DialectFactory.getDialect(databaseType).getCountSql(originalSql); long total = executeCount(mappedStatement, connection, parameterObject, countSql); page.setTotal(total); // 2. 構建分頁SQL String pageSql = DialectFactory.getDialect(databaseType).getPaginationSql(originalSql, page.getOffset(), page.getPageSize()); ReflectUtil.setFieldValue(boundSql, "sql", pageSql); // 使用反射替換SQL return invocation.proceed(); } // 省略 findPageObject, executeCount, DialectFactory 和 ReflectUtil 工具類實現 // DialectFactory 內部會根據 databaseType 返回對應的數據庫方言實現，如 MySQLDialect, OracleDialect // MySQLDialect 會實現 getCountSql 和 getPaginationSql 方法 // ReflectUtil 是一個簡單的反射工具類，用于獲取/設置私有字段 }
為什么選擇MyBatis攔截器實現分頁？它比其他方式好在哪里？
我個人覺得，MyBatis攔截器在實現分頁方面確實是“優雅”這個詞的代名詞。它提供了一種非侵入式的、高度可配置的解決方案，這在實際項目中非常有用。
首先，解耦性極佳。業務代碼完全不需要關心分頁SQL的拼接，也不需要手動計算OFFSET和LIMIT。你的Mapper接口方法可以保持最原始、最純粹的SQL定義，比如List
其次，通用性和可擴展性強。通過攔截器，我們可以輕松地實現數據庫方言的適配。MySQL用LIMIT，Oracle用ROWNUM，SQL Server用TOP或OFFSET FETCH，這些差異都被封裝在插件內部的方言實現里。當你的項目需要從MySQL遷移到Oracle時，你只需要修改一下插件的配置參數，而不需要改動任何業務SQL。這種靈活性是手動分頁或者基于RowBounds的內存分頁無法比擬的。
再者，相比MyBatis自帶的RowBounds，攔截器方案解決了其內存分頁的效率問題。RowBounds雖然也能實現分頁，但它是在數據庫查詢出所有結果后，再在內存中進行截取。對于大數據量查詢，這簡直是災難性的，會造成大量的內存消耗和不必要的網絡傳輸。而攔截器則是在SQL執行前就將分頁邏輯注入，讓數據庫只返回你需要的那一頁數據，效率自然高得多。
最后，與一些成熟的第三方分頁插件（如PageHelper）相比，自定義攔截器雖然需要自己編寫更多代碼，但它提供了極致的控制權。如果你對分頁邏輯有特殊需求，或者不想引入額外的第三方依賴，自定義攔截器是最佳選擇。它讓你對分頁的每一個細節都了如指掌，能夠根據項目的具體情況進行深度優化。在我看來，這種“掌控感”在某些場景下是無價的。
實現MyBatis分頁插件需要關注哪些核心技術點和潛在挑戰？
實現MyBatis分頁插件，說實話，一開始可能會覺得有點“黑科技”的味道，因為它確實深入到了MyBatis的內部機制。有幾個核心技術點是必須掌握的，同時也會遇到一些挑戰。
核心技術點：
- SQL解析與重寫： 這是最核心也最復雜的部分。你需要能夠從原始SQL中提取出用于計數的部分（例如，去除ORDER BY、LIMIT等子句），并將其包裹成SELECT COUNT(*) FROM (…)的形式。同時，還要能根據分頁參數（頁碼、每頁大小）將原始SQL改寫成帶有數據庫特定分頁子句的SQL。這通常涉及到正則表達式匹配或者更復雜的SQL AST（抽象語法樹）解析。我個人在處理復雜SQL時，就曾被一些嵌套子查詢、union操作搞得焦頭爛額，這部分的代碼健壯性非常重要。
- 數據庫方言抽象： 不同的數據庫有不同的分頁語法。因此，你需要設計一個Dialect接口，包含getCountSql(String sql)和getPaginationSql(String sql, int offset, int limit)等方法，然后為MySQL、Oracle、PostgreSQL等主流數據庫提供具體的實現類。這樣可以保持插件的通用性。
- MyBatis內部反射機制： MyBatis的很多核心對象（如BoundSql的sql字段）都是私有的，為了修改它們，你必須使用Java的反射機制。例如，ReflectUtil.setFieldValue(boundSql, “sql”, newSql)。雖然反射很強大，但它也帶來了一定的脆弱性——MyBatis版本升級時，如果內部字段名或結構發生變化，你的插件可能就會失效。這是一個需要權衡的風險點。
- 參數處理與總記錄數回寫： 如何將分頁參數（如PageNum、PageSize）傳遞給插件？通常是通過方法參數中的一個特定對象（比如我們定義的Page對象）。更重要的是，插件在執行完COUNT查詢后，需要將總記錄數回寫到這個Page對象中，以便業務層獲取。這同樣可能需要反射來操作參數對象。
潛在挑戰：
- 復雜SQL的兼容性： 這是最頭疼的問題。簡單的SELECT * FROM table當然沒問題，但遇到包含GROUP BY、HAVING、UNION、DISTINCT、LEFT JOIN以及各種復雜子查詢的SQL時，自動生成正確的COUNT SQL和分頁SQL就變得異常困難。例如，帶有GROUP BY的SQL，直接COUNT(*)可能就不對了，需要COUNT(DISTINCT some_column)或更復雜的子查詢。這需要你的SQL解析邏輯足夠智能和健壯。
- 性能問題： 雖然攔截器避免了內存分頁，但如果COUNT SQL生成不當，或者原始SQL本身效率低下，COUNT查詢仍然可能成為性能瓶頸，甚至導致全表掃描。優化COUNT SQL的生成邏輯，盡量利用索引，是需要仔細考慮的。
- 事務隔離級別： 計數查詢和實際數據查詢是兩次獨立的SQL執行。在某些嚴格的事務隔離級別下（如可重復讀），如果在這兩次查詢之間有數據發生變化，理論上可能導致總記錄數與實際返回數據條數不一致的問題。雖然在多數Web應用場景下影響不大，但了解這一點很重要。
- 反射的維護成本： 前面提到了，MyBatis內部結構的變動可能導致反射代碼失效。這意味著每次MyBatis大版本升級時，你可能都需要檢查并更新你的插件代碼。這就像是在一個不斷變化的沙灘上蓋房子，需要持續關注。
總的來說，實現分頁插件是一個很好的深入理解MyBatis內部機制的機會，但也確實需要你做好應對各種“奇葩”SQL和反射帶來的潛在問題的準備。
如何在Spring Boot項目中集成和配置MyBatis分頁插件？
在Spring Boot項目中集成MyBatis分頁插件，得益于Spring Boot的自動配置能力，其實比想象中要簡單得多。一旦你的分頁插件類（比如PaginationInterceptor）寫好了，接下來的配置工作就非常順暢了。
-
創建插件類： 確保你的PaginationInterceptor類已經編寫完成，并且它實現了org.apache.ibatis.plugin.Interceptor接口。
-
定義分頁參數對象： 確保你有一個Page類（或者你喜歡的任何名字），它包含了分頁所需的信息，比如pageNum、pageSize，以及用來存放總記錄數total和結果列表list的字段。
-
配置為Spring Bean： 最簡單也是最推薦的方式，就是將你的PaginationInterceptor聲明為一個Spring Bean。Spring Boot會自動檢測到這個Bean，并將其注冊到MyBatis的SqlSessionFactory中。
import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.util.Properties; @Configuration public class MyBatisConfig { @Bean public PaginationInterceptor paginationInterceptor() { PaginationInterceptor interceptor = new PaginationInterceptor(); // 如果你的插件需要配置屬性，例如數據庫方言 Properties properties = new Properties(); properties.setProperty("databaseType", "mysql"); // 示例：設置數據庫類型 interceptor.setProperties(properties); return interceptor; } }你也可以在application.yml或application.properties中直接配置，但通過Java Config聲明為Bean更靈活，尤其是在需要傳遞屬性時。
通過application.yml配置（如果插件支持無參構造器且無需額外屬性）：
mybatis: mapper-locations: classpath:mapper/*.xml configuration: # plugins 屬性是一個列表，可以添加多個插件 plugins: - com.yourcompany.plugin.PaginationInterceptor # 替換為你的插件完整包名
我個人更傾向于Java Config，因為它能更好地處理插件初始化時的屬性注入，比如你可能需要通過構造器注入一些依賴，或者設置一些運行時參數。
-
在業務代碼中使用： 在你的Service層或Controller層，當你需要進行分頁查詢時，只需將你的Page對象作為參數傳遞給Mapper方法。插件會在后臺默默地完成SQL的改寫和總記錄數的查詢。
// 假設你的Mapper接口方法 public interface UserMapper { List<User> selectUsers(Page<User> page); // 傳入Page對象 } // 在Service層調用 @Service public class UserService { @Autowired private UserMapper userMapper; public Page<User> findUsersByPage(int pageNum, int pageSize) { Page<User> page = new Page<>(pageNum, pageSize); // 初始化分頁對象 List<User> users = userMapper.selectUsers(page); // 調用Mapper方法 page.setList(users); // 將查詢結果設置回Page對象 return page; } }這里要注意的是，插件通常會在執行完COUNT查詢后，將total值設置到你傳入的Page對象中。而實際的列表數據list，則是在Mapper方法執行結束后由MyBatis返回的，你需要手動將它設置回Page對象。
集成過程中，我覺得最舒服的就是Spring Boot的“約定優于配置”理念。只要你的插件符合MyBatis攔截器的規范，并且被Spring識別為一個Bean，它就會自動幫你處理好剩下的事情。這省去了很多手動配置SqlSessionFactoryBean的繁瑣步驟，讓你可以更專注于插件本身的邏輯實現。當然，如果遇到問題，Spring Boot的日志通常會給出很清晰的提示，幫助你快速定位。
