在mysql中,通常使用limit做分頁,而且經常會跟order by 連用。在order by 上加索引有時候是很有幫助的,不然系統會做很多的filesort
經常碰到的一個問題是limit的offset太高,如:limit 100000,20,這樣系統會查詢100020條,然後把前面的100000條都扔掉,這是開銷很大的操作,導致查詢很慢。假設所有分頁的頁面訪問頻率一樣,這樣的查詢平均掃描表的一半資料。最佳化的方法,要麼限制訪問後面的頁數,要麼提升高偏移的查詢效率。
一個簡單的最佳化辦法是使用覆蓋查詢(covering index)查詢,然後再跟全行的做join操作。如:
複製程式碼
程式碼如下:
SQL>select * from user_order_info limit 1000000,5;
這條語句就可以最佳化為:
select * from user_order_info inner join (select pin from user_order_info limit 1000000,5) as lim using(pin);
SQL>explain select * from user_order_info limit 1000000,5;
+----+-------------+-----------------+------+---------------+------+---------+------+----------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
| 1 | SIMPLE | user_order_info | ALL | NULL | NULL | NULL | NULL | 23131886 | |
1 row in set (0.00 sec)
SQL>explain extended select * from user_order_info inner join (select pin from user_order_info limit 1000000,5) as lim using(pin);
+----+-------------+-----------------+--------+---------------+---------+---------+---------+----------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 5 | 100.00 | |
| 1 | PRIMARY | user_order_info | eq_ref | PRIMARY | PRIMARY | 42 | lim.pin | 1 | 100.00 | |
| 2 | DERIVED | user_order_info | index | NULL | PRIMARY | 42 | NULL | 23131886 | 100.00 | Using index |
3 rows in set, 1 warning (0.66 sec)
根據兩個explain的對比,可以清晰發現,第一個未使用索引,掃描了23131886行,第二個也掃描了同樣的行數,但是使用了索引,效率提高了。這樣可以直接使用index得到資料,而不去查詢表,當找到需要的資料之後,在與全表join,獲得其他的列。
在mysql中,通常使用limit做分頁,而且經常會跟order by 連用。在order by 上加索引有時候是很有幫助的,不然系統會做很多的filesort
經常碰到的一個問題是limit的offset太高,如:limit 100000,20,這樣系統會查詢100020條,然後把前面的100000條都扔掉,這是開銷很大的操作,導致查詢很慢。假設所有分頁的頁面訪問頻率一樣,這樣的查詢平均掃描表的一半資料。最佳化的方法,要麼限制訪問後面的頁數,要麼提升高偏移的查詢效率。
一個簡單的最佳化辦法是使用覆蓋查詢(covering index)查詢,然後再跟全行的做join操作。如:
複製程式碼
程式碼如下:
SQL>select * from user_order_info limit 1000000,5;
這條語句就可以最佳化為:
複製程式碼
程式碼如下:
select * from user_order_info inner join (select pin from user_order_info limit 1000000,5) as lim using(pin);
SQL>explain select * from user_order_info limit 1000000,5;
+----+-------------+-----------------+------+---------------+------+---------+------+----------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------------+------+---------------+------+---------+------+----------+-------+
| 1 | SIMPLE | user_order_info | ALL | NULL | NULL | NULL | NULL | 23131886 | |
+----+-------------+-----------------+------+---------------+------+---------+------+----------+-------+
1 row in set (0.00 sec)
SQL>explain extended select * from user_order_info inner join (select pin from user_order_info limit 1000000,5) as lim using(pin);
+----+-------------+-----------------+--------+---------------+---------+---------+---------+----------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-----------------+--------+---------------+---------+---------+---------+----------+----------+-------------+
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 5 | 100.00 | |
| 1 | PRIMARY | user_order_info | eq_ref | PRIMARY | PRIMARY | 42 | lim.pin | 1 | 100.00 | |
| 2 | DERIVED | user_order_info | index | NULL | PRIMARY | 42 | NULL | 23131886 | 100.00 | Using index |
+----+-------------+-----------------+--------+---------------+---------+---------+---------+----------+----------+-------------+
3 rows in set, 1 warning (0.66 sec)
根據兩個explain的對比,可以清晰發現,第一個未使用索引,掃描了23131886行,第二個也掃描了同樣的行數,但是使用了索引,效率提高了。這樣可以直接使用index得到資料,而不去查詢表,當找到需要的資料之後,在與全表join,獲得其他的列。