今天的話題，要給大家分享的是：百萬級資料表分頁查詢，為什么不是千萬，億級呢，你想啊，單表千萬上億，你不是瘋了嗎，早就分表了，單表資料量通常都是控制在幾百萬左右，真正實際專案中，都是百萬級資料，維恩老師今天要給大家講的前提是，專案 redis 快取策略，架構都搭完了，查詢命中了資料庫表來查詢的情況，如何進行優化，所以我們要搞明白這三個問題：
沒有百萬級以上資料查詢分頁經驗怎么辦？
提升海量資料查詢效率的關鍵因素？
三年作業經驗了，如何突破晉升下一階段？
互聯網大廠關于海量資料查詢的面試題
互聯網大廠必問題 ：通常出現在 阿里/京東 等電商平臺面試機率大，
百萬級資料表分頁查詢做過嗎？
你們的查詢時間要求是多少？
有沒有遇到慢查詢的情況？
你是如何解決的？
注意面試官的預期
面試開始，接招吧
面試官：做過海量資料查詢及分頁的專案嗎？你是怎么優化的？
面試者：是的，在之前的一個專案中的訂單業務中涉及到大資料量查詢問題
案例場景
1、一個訂單業務系統中，在mysql庫中訂單表（ordertb）500萬條記錄：
SELECT COUNT(id) FROM ordertb2、現在的需求是，要篩選：2010全年資料約為200萬條，要求分頁顯示：
大資料量分頁查詢產生的問題
我們要如何解決這個問題呢？
咱們來講一講，建索引的幾大原則：
1、最左前綴匹配原則非常重要的原則，mysql會一直向右匹配直到遇到范圍查詢(>、<、between、like)就停止匹配，比如a =1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整，
2、=和in可以亂序比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢優化器會幫你優化成索引可以識別的形式，
3、盡量選擇區分度高的列作為索引區分度的公式是count(distinct col)/count(*)，表示欄位不重復的比例，比例越大我們掃描的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別欄位可能在大資料面前區分度就是0，那可能有人會問，這個比例有什么經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的欄位我們都要求是0.1以上，即平均1條掃描10條記錄，
4、索引列不能參與計算，保持列“干凈”比如from_unixtime (create_time)= 2014-05-29’就不能使用到索引，原因很簡單，b+ 樹中存的都是資料表中的欄位值，但進行檢索時，需要把所有元素都應用函式才能比較，顯然成本太大，所以陳述句應該寫成create_time = unix_timestamp(’2014-05-29’);
5、盡量的擴展索引，不要新建索引，比如表中已經有a的索引，現在要加(a,b)的索引，那么只需要修改原來的索引即可，
使用explain查看執行計劃
添加索引后的效果
這可咋整？添加了索引的ucreatetime 列相同的資料太多，如下圖：
這就要重新分析一下問題：
1、分頁頁碼越大查詢效率越低
2、選擇區分度高的列作為索引，否則未索引起反效果
3、需要根據業務場景具體分析，不盲目添加索引
重新分析一下這個問題：
如何解決問題：
把分頁限定條件優化為篩選條件，變相降低了分頁起始位置，
總結
分表后的單表資料量在幾百萬的情況下，查詢優化問題（分頁）排查慢查詢
咱們要充分理解索引建立的幾大原則，然后使用explain查看執行計劃，了解慢查詢的問題在哪里，這一步是分析問題，再結合業務方面的使用場景，來優化你的SQL陳述句，
OK，文章最后，想說，經驗可以學習，場景來自實際作業，學習Java的路上，咱們一起學習，一起成長！零基礎學習到就業，免費領取學習資料了 找小助理領取哈
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/415138.html
標籤：其他
上一篇：hive函式 next_day