SQL優化：limit分頁優化

分頁查詢

分頁查詢的問題點主要集中在

1. 如何快速定位起始點
2. 減少無用資料快取

mysql為分頁查詢提供了很方便的關鍵字limit，但這個關鍵字在資料量較大時，卻很低效。
“limit m,n”關鍵字的意思是，從第m行開始，掃描滿足條件的n個偏移行。若需從第1行開始，則不需要指定m值。

示例

表aaaaa中共有2375690資料。

優化前的SQL

SQL執行結果：

SELECT DISTINCT(device_id) uid FROM aaaaa WHERE status = 0 LIMIT 88000,1000;
1000 rows in set (0.48 sec)

SQL執行計劃：

MariaDB [star]> explain SELECT sql_no_cache DISTINCT(device_id) uid FROM aaaaa WHERE status = 0 LIMIT 88000,1000;
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
| id   | select_type | table         | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
|    1 | SIMPLE      | aaaaa         | ALL  | NULL          | NULL | NULL    | NULL | 2375690 | Using where; Using temporary |
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+

優化方式

迅速定位起始ID，利用主鍵索引，加快掃描速度。可以看到，derived中，SQL使用到了覆蓋索引進行掃描，雖然還是全表掃，因為只掃描id列，大大降低了掃描的IO耗費，快速定位到了id。

MariaDB [star]> explain SELECT sql_no_cache DISTINCT(device_id) uid FROM aaaaa join (select id from aaaaa limit 88000,1) k on star_device_5.id>=k.id where status=0 limit 1000; 
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+
| id   | select_type | table         | type  | possible_keys | key         | key_len | ref  | rows    | Extra                                          |
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+
|    1 | PRIMARY     |     | ALL   | NULL          | NULL        | NULL    | NULL |   88001 | Using temporary                                |
|    1 | PRIMARY     | star_device_5 | ALL   | PRIMARY       | NULL        | NULL    | NULL | 2377112 | Range checked for each record (index map: 0x1) |
|    2 | DERIVED     | star_device_5 | index | NULL          | idx_star_id | 8       | NULL | 2377112 | Using index                                    |
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+

執行結果：

SELECT sql_no_cache DISTINCT(device_id) uid FROM star_device_5 join (select id from star_device_5 limit 880000,1) k on star_device_5.id>=k.id where status=0 limit 1000;
1000 rows in set (0.19 sec)

隨著m的增大和n的增大，兩種寫法的SQL執行時間會有本質差別。我做了測試，當m值增加到880000時，優化前的SQL需要2分鐘，優化後的SQL還是0.1s左右。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29730827/viewspace-2136208/，如需轉載，請註明出處，否則將追究法律責任。