Mysql優化--Limit查詢的優化考慮

在實際業務中對於分頁來講是一個比較常見的業務需求。那麼就會使用到limit查詢，當咱們在使用Limit查詢的時候，在數據比較小、或者只查詢前面一部分數據的時候效率是很高的。可是當數據量大的時候，或者查詢offset數量比較大的時候，如：limit 100000,20效率每每就不盡人意了。一般的一個辦法就是Limit配合order by，若是order by有對用戶的索引的話，效率一般是比較不錯的。
對於這種狀況，最簡單的查詢就是 使用覆蓋索引，查詢某些須要的列。這樣的效果是很好的
以下面這個

mysql>   SELECT * FROM student    LIMIT 1000000,1;
+---------+------------+------------+------------+-------+---------------------+
| id      | first_name | last_name  | created_at | score | updated_at          |
+---------+------------+------------+------------+-------+---------------------+
| 1000001 | kF9DxBgnUi | yLXnPSHJpH | 2019-07-11 |    97 | 2019-07-11 14:29:59 | |
+---------+------------+------------+------------+-------+---------------------+
1 rows in set (0.31 sec)

能夠看到時間

mysql>  EXPLAIN SELECT score,first_name FROM student  ORDER BY created_at   LIMIT 1000000,20 \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: student
   partitions: NULL
         type: index
possible_keys: NULL
          key: time_sorce_name
      key_len: 69
          ref: NULL
         rows: 1000001
     filtered: 100.00
        Extra: Using index
1 row in set, 1 warning (0.00 sec)

mysql>

這樣的話查詢的列使用到的了覆蓋索引，掃描行數會減小不少，可是這樣的效果也不是很盡人意，可是若是有其餘的查詢的話，這樣的查詢也會變的很慢。
好比咱們加上last_name列。
以下

mysql>  SELECT score,first_name,last_name FROM student  ORDER BY created_at   LIMIT 1000000,1;
+-------+------------+------------+
| score | first_name | last_name  |
+-------+------------+------------+
|    86 | knKsV2g2fY | WB5qJeLZuk |
+-------+------------+------------+
1 row in set (4.81 sec)

mysql>

這個查詢須要執行 4秒多的時間。經過分析能夠看到這個查詢是沒有辦法使用索引的

mysql> explain SELECT score,first_name,last_name FROM student  ORDER BY created_at   LIMIT 1000000,1\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: student
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 6489221
     filtered: 100.00
        Extra: Using filesort
1 row in set, 1 warning (0.00 sec)

mysql>

那麼咱們如今把查詢修改以下

mysql> SELECT student.score,student.first_name FROM student INNER JOIN (SELECT id FROM student  ORDER BY created_at   LIMIT 1000000,1 ) AS temp USING(id);
+-------+------------+
| score | first_name |
+-------+------------+
|    15 | 2QWZ       |
+-------+------------+
1 row in set (0.18 sec)

mysql> EXPLAIN SELECT student.score,student.first_name,last_name FROM student INNER JOIN (SELECT id FROM student  ORDER BY created_at   LIMIT 1000000,1 ) AS temp USING(id);
+----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+
| id | select_type | table      | partitions | type   | possible_keys | key             | key_len | ref     | rows    | filtered | Extra       |
+----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+
|  1 | PRIMARY     | <derived2> | NULL       | ALL    | NULL          | NULL            | NULL    | NULL    | 1000001 |   100.00 | NULL        |
|  1 | PRIMARY     | student    | NULL       | eq_ref | PRIMARY       | PRIMARY         | 4       | temp.id |       1 |   100.00 | NULL        |
|  2 | DERIVED     | student    | NULL       | index  | NULL          | time_sorce_name | 69      | NULL    | 1000001 |   100.00 | Using index |
+----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)

分析結果,能夠看到這個時候只查詢了1000001一條數據記錄。爲何會有這樣的變化呢。這種叫延時關聯，先經過使用覆蓋索引查詢返回須要的主鍵,再根據主鍵關聯原表得到須要的數據，儘量的減小了須要掃描的行數。

在某些特定的場合，其實有另一種優化方案的。好比要獲取最新的幾條插入記錄。那麼在上一次查詢的時候咱們能夠記錄下最後一條記錄的主鍵ID(last_id)。
那麼查詢就能夠改成

SELECT score,first_name,last_name,id FROM student  WHERE id>=last_id ORDER BY id ASC   LIMIT 1

好比last_id=1000000那麼這個查詢就會從1000000開始。這樣的場景無論數據到多大的offset性能都會很好。