前言

在實際業務中對於分頁來說是一個比較常見的業務需求。那麼就會使用到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,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,last_name,id FROM student WHERE id>=last_id ORDER BY id ASC LIMIT 1

比如last_id=1000000那麼這個查詢就會從1000000開始。這樣的場景不管資料到多大的offset效能都會很好。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對我們的支援。