我主要看重那條sql 雖然我沒有測試

前面原始碼分析見轉載連結。

至此整個查詢過程完成，原來PageHelper的分頁功能是通過Limit拼接SQL實現的。查詢效率低的問題也找出來了，那麼應該如何解決。

首先分析SQL語句，limit在資料量少或者頁數比較靠前的時候查詢效率是比較高的。(單表資料量百萬進行測試)

select * from user where age = 10 limit 1,10;結果顯示0.43s

當where條件後的結果集較大並且頁數達到一個量級整個SQL的查詢效率就十分低下(哪怕where的條件加上了索引也不行)。

select * from user where age = 10 limit 100000,10;結果顯示4.73s

那有什麼解決方案呢？mysql就不能單表資料量超百萬乃至千萬嘛？答案是NO，顯然是可以的。

SELECT a.* FROM USER a
INNER JOIN 
    (SELECT id FROM USER WHERE age = 10 LIMIT 100000,10) b 
ON a.id = b.id;

結果0.53s

完美解決了查詢效率問題！！！其中需要對where條件增加索引，id因為是主鍵自帶索引。select的欄位越多,欄位資料量越大,速度就越慢,所以採用查詢主鍵欄位後進行關聯大幅度提升了查詢效率。

PageHelper想要優化需要在攔截器的拼接SQL部分進行重構，由於博主能力有限暫未實現。能力較強的讀者可以自己進行重構

附上PageHelper的git地址：https://github.com/pagehelper/Mybatis-PageHelper/

轉載