百萬數據量SQL，在進行分頁查詢時會出現性能問題，例如我們使用PageHelper時，由於分頁查詢時，PageHelper會攔截查詢的語句會進行兩個步驟
1.添加 select count（*）from （原查詢sql） ，用於統計查詢的總數
2.拼接 limit startPage，number 用於分頁
此時有兩個問題
第一個問題是：
用於統計的 select count（*）from （原查詢sql）在數據量大時速度慢
第二個問題時：
limit startPage，number 在大數據量時效率低
解決方案：
第一個問題：
在數據量過大時，不使用分頁插件PageHelper，select count（*）from （原查詢sql）固定返回一個固定值給到前端，例如千萬級數據，固定返回1千萬
第二個問題：
在數據量過大時，不使用分頁插件PageHelper ，使用join或者子查詢去優化
例如 id為主鍵，name為非唯一索引
優化前：
select id,name,brand from table where name=‘xxx’ limit 100000，10
優化后：
select aa.id,name,brand from table inner join (select id from table bb where name ='xxx' limit 100000,10) bb where aa.id=bb.id
原因是解決
非聚簇索引的葉子節點是聚簇索引的節點值，聚簇索引的葉子節點值才是數據的物理位置，
優化前會花費大量的隨機IO到找到聚簇索引，優化后則減少了尋找聚簇索引位置的時間；