后端開發中為了防止?次性加載太多資料導致記憶體、磁盤IO都開銷過?，經常需要分?展示，這個時候就需要?到MySQL的LIMIT關鍵字，但你以為LIMIT分?就萬事大吉了么，LIMIT在資料量?的時候極可能造成深度分頁問題，
例如，上圖，我們在查user表時，mysql會先根據條件去磁盤檢索得到符合條件的所有資料，然后在到記憶體中去做相應的排序和分頁，最后得到一頁資料回傳，如果當我們資料達到千萬級別時，僅用limit，當查詢的條件多且大時，將會造成災難性的后果，此時，我們如何解決呢？
例如，我們通過explain分析深度分?查詢問題 **explain select * from user
where age>10 and age<90000000 order by age desc limit
8000000,10000;**執?計劃Extra列可能出現的值及含義：
- Using where：表示優化器需要通過索引回表查詢資料，
- Using index：即覆寫索引，表示直接訪問索引就?夠獲取到所需要的資料，不需要通過索引回表，通常是通過將待查詢欄位建?聯合索引實作，
- Using index condition：在5.6版本后加?的新特性，即?名鼎鼎的索引下推，是MySQL關于減少回表次數的重大優化，
- Using filesort:?件排序，這個?般在ORDER BY時候，資料量過大，MySQL會將所有資料召回記憶體中排序，比較消耗資源，
解決方案
通過主鍵索引優化
在查詢條件中帶上主鍵索引 explain select * from user where id>{maxId(即上一頁最大的id} age>10 and age<90000000 order by
age desc limit 8000000,10000;
顯然這種方法具有缺陷性，當我們的主鍵不是自增的，就會失效
2.Elastic Search搜索引擎優化（倒排索引）
實際上類似于淘寶這樣的電商基本上都是把所有商品放進ES搜索引擎?的（那么海量的資料，放進MySQL是不可能的，放進Redis也不現實），但即使?了ES搜索引擎，也還是有可能發?深度分?的問題的，這時怎么辦呢？答案是通過游標scroll
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/421699.html
標籤：其他
上一篇：六十四、Spark-分別統計各個單詞個數及特殊字符總個數
下一篇：數分-理論-大資料7-Spark