千萬級MySQL分頁優化

     https://blog.csdn.net/persistencegoing/article/details/84376427
       對於只有幾萬條數據的表這樣做當然沒問題,也不會在用戶體驗上有何不妥,但是要是面對成百萬上千萬的數據表時,這樣就不足以滿足我們的業務需求了,如何做到對千萬級數據表進行高效分頁?首先要學會使用 explain 對你的SQL進行分析,如果你還不會使用 explain 分析SQL語句 傳送門 http://blog.itpub.net/559237/viewspace-496311
一丶合理使用 mysql 查詢緩存 結合複合索引進行查詢分頁
開啟查詢緩存的原因是為了增大吞吐率,提升查詢的性能 query_caceh_type 是否開啟查詢緩存     0 表示不開啟查詢緩存，      1 表示始終開啟查詢緩存（不要緩存使用sql_no_cache） ，     2 表示按需開啟查詢緩存 (需要緩存使用 sql_cache)。 query_cache_size 給緩存分配的最大內存空間  對於查詢緩存的一些操作。     FLUSH QUERY CACHE; // 清理查詢緩存內存碎片。     RESET QUERY CACHE; // 從查詢緩存中移出所有查詢。     FLUSH tabName; //關閉所有打開的表，同時該操作將會清空查詢緩存中的內容。
分頁說到底也是查詢的一種,既然是查詢我們就可以為他設置索引來提高查詢速度 https://blog.csdn.net/csdn265/article/details/51789754(複合索引)
二丶SQL語句的優化(不使用索引)
這裏有一張千萬級別的數據表,表結構如下
 
 b.先去查詢到最大偏移量然後再進行分頁,這樣看來時間好像變得更長了,顯示這種方式不符合我們的場景,對這句SQL再次進行優化 (SELECT uid,u_name,u_age,u_sex,u_is_delete FROM u_user WHERE uid>7000000 LIMIT 10;)
 
優化三：SELECT * FROM table WHERE id BETWEEN 1000000 AND 1000010;     這個比優化二和三還要快一些
優化二和三有個缺點就是uid中可能有缺碼，但是大多數情況下都是修改字段而不會去物理刪除，所以還是可以參考
 
優化四：SELECT * FROM table WHERE id IN(10000, 100000, 1000000);    這個可以解決優化二和三的缺點（id缺碼）但是效率沒試過，可以確定的是比limit快   
 
非常棒的查詢時間,0.001s,幾乎是秒查詢,這樣即使是千萬級的數據表分頁起來也能輕松應對
當然,這只是我能想到的實現千萬級數據表分頁的兩種方案,若有其他方式,歡迎評論
希望大家關注我一波,防止以後迷路,有需要的可以加群討論互相學習java ,學習路線探討,經驗分享與java求職     群號:721 515 304