安裝sakila

我們將會使用MySQL示例數(shù)據(jù)庫sakila來進行sql的演示和講解 dev.mysql.com/doc/sakila/…

索引掃描排序

MySQL有兩種方式可以生成有序的結(jié)果:通過排序操作﹔或者按索引順序掃描﹔如果EXPLAIN出來的type列的值為“index”，則說明MySQL使用了索引掃描來做排序。
掃描索引本身是很快的，因為只需要從一條索引記錄移動到緊接著的下一條記錄。但如果索引不能覆蓋查詢所需的全部列，那就不得不每掃描一條索引記錄就都回表查詢一次對應(yīng)的行。這基本上都是隨機I/O，因此按索引順序讀取數(shù)據(jù)的速度通常要比順序地全表掃描慢，尤其是在IO密集型的工作負載時。此時可能就會用全表掃描而不是按索引查找了。
如果可能，設(shè)計索引時應(yīng)該盡可能地同時滿足排序和查找行。
只有當(dāng)索引的列順序和0RDER BY子句的順序完全一致，并且所有列的排序方向（倒序或正序）都一樣時，MySQL才能夠使用索引來對結(jié)果做排序。如果查詢需要關(guān)聯(lián)多張表，則只有當(dāng)ORDER BY子句引用的字段全部為第一個表時，才能使用索引做排序。ORDER BY子句和查找型查詢的限制是一樣的:需要滿足索引的最左前綴的要求﹔否則,MySQL都需要執(zhí)行排序操作（filesort），而無法利用索引排序。

表結(jié)構(gòu)

我們將使用rental這個表來進行講解

CREATE TABLE `rental` (
  
  UNIQUE KEY `rental_date` (`rental_date`,`inventory_id`,`customer_id`),
  KEY `idx_fk_inventory_id` (`inventory_id`),
  KEY `idx_fk_customer_id` (`customer_id`),
  KEY `idx_fk_staff_id` (`staff_id`),
  
) ENGINE=InnoDB AUTO_INCREMENT=16050 DEFAULT CHARSET=utf8mb4;

查看Extra 中是否出現(xiàn)Using filesort（MySQL中無法利用索引完成的排序操作稱為“文件排序”）當(dāng)我們試圖對一個沒有索引的字段進行排序時，就是filesort。雖然里面有個file，但它跟文件沒有任何關(guān)系，實際上是內(nèi)部的一個快速排序

可以使用索引掃描來做排序的情況

補足前導(dǎo)列

有一種情況下ORDER BY子句可以不滿足索引的最左前綴的要求，就是前導(dǎo)列為常量的時候。如果WHERE子句或者JOIN子句中對這些列指定了常量,就可以“彌補”索引的不足。 我們使用Sakila數(shù)據(jù)庫來測試一下

可以看到

書上的Extra寫的是Using where，而我執(zhí)行的時候是Using index condition ，原因是高性能MySQL中使用的版本是5.5，5.6版本中的索引條件推送（index condition pushdown）還處于未正式發(fā)布階段呢。這里沒有filesort的原因是因為有個rental_date = '2005-05-25'的常量條件，相當(dāng)于將索引的第一列補足了，這樣就符合了索引的最左前綴要求。

order by 中只包含一種排序

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date = '2005-05-25' ORDER BY  inventory_id desc

可以看到

需要注意這一條，在書中使用的的條件是rental_date>'2005-05-25'

WHERE rental_date > '2005-05-25' ORDER BY rental_date, inventory_id

此時無法使用索引排序而是直接全表掃描做了個排序，原因是因為返回數(shù)據(jù)的條數(shù)過多，用索引查詢此時已經(jīng)不劃算了

需要注意這里的解釋里面的rows并不準確，只是一個估算值，實際上按這個條件查詢有16036條數(shù)據(jù) 要想解決這個問題，就需要加上limit

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date > '2005-05-25' ORDER BY rental_date, inventory_id limit 0,10

對應(yīng)的執(zhí)行計劃

可以看到使用了索引

無法使用索引掃描的情況

查詢條件中包含不同排序方向

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date = '2005-05-25' ORDER BY  inventory_id desc,customer_id asc

索引中兩列都是正序，現(xiàn)在order by 中一列正序一列倒序就得二次排序了。

查詢條件中引用不在索引中的列

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date ='2005-08-23 21:01:09' ORDER BY  inventory_id ,staff_id

無法組合最左前綴時

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date ='2005-08-23 21:01:09' ORDER BY  customer_id

第一列是查詢范圍時

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date > '2005-08-22' ORDER BY  inventory_id,customer_id

where中有多個等于條件

SELECT rental_id, staff_id FROM sakila.rental WHERE rental_date ='2005-08-23 21:01:09' and inventory_id in(1,2)  ORDER BY  customer_id

簡單來說就是不符合索引最左前綴的就會進行一次排序。

總結(jié)

今天我們講解了MySQL中的索引掃描排序，明天我們還將繼續(xù)介紹其他建立高性能索引的方法，敬請期待，下篇再見！

以上就是MySQL 索引掃描的簡單使用的詳細內(nèi)容，更多關(guān)于MySQL 索引掃描排序的資料請關(guān)注腳本之家其它相關(guān)文章！