目錄

一、索引成本計算

1、IO成本

2、CPU成本

二、cout(*)索引---選成本最小的輔助索引

總結

---

一、索引成本計算

在有多個索引的情況下， 在查詢數據前，MySQL 會選擇成本最小原則來選擇使用對應的索引，這里的成本主要包含兩個方面。

1、IO成本

即從磁盤把數據加載到內存的成本，默認情況下，讀取數據頁的 IO 成本是 1，MySQL 是以頁的形式讀取數據的，即當用到某個數據時，并不會只讀取這個數據，而會把這個數據相鄰的數據也一起讀到內存中，這就是有名的程序局部性原理，所以 （2）MySQL 每次會讀取一整頁，一頁的成本就是 1。所以 IO 的成本主要和頁的大小有關

2、CPU成本

將數據讀入內存后，還要檢測數據是否滿足條件和排序等 CPU 操作的成本，顯然它與行數有關，默認情況下，檢測記錄的成本是 0.2。
?

二、cout(*)索引---選成本最小的輔助索引

如下sql會導致慢查詢，造成全表掃描：
SELECT COUNT(*) FROM SomeTable
SELECT COUNT(1) FROM SomeTable
這種說法是有問題的，實際上針對無where條件的COUNT(*)，MySQL是有優化的，優化器會選擇成本最小的輔助索引查詢計數。

首先去生產上找了一個千萬級別的表使用 EXPLAIN 來查詢了一下執行計劃

EXPLAIN SELECT COUNT(*) FROM SomeTable

結果如下

image.png

如圖所示: 發現確實此條語句在此例中用到的并不是主鍵索引，而是輔助索引，實際上在此例中我試驗了，不管是 COUNT(1)，還是 COUNT(*)，MySQL 都會用成本最小的輔助索引查詢方式來計數，也就是使用 COUNT(*) 由于 MySQL 的優化已經保證了它的查詢性能是最好的！隨帶提一句，COUNT(*)是 SQL92 定義的標準統計行數的語法，并且效率高，所以請直接使用COUNT(*)查詢表的行數！不過是在 MySQL 5.6 之后的版本中才有這種優化。

那么這個成本最小該怎么定義呢，有時候在 WHERE 中指定了多個條件，為啥最終 MySQL 執行的時候卻選擇了另一個索引，甚至不選索引？這里成本計算見一(1)(2)

為了根據以上兩個成本來算出使用索引的最終成本，我們先準備一個表（以下操作基于 MySQL 5.7.18）

CREATE TABLE `person` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`name` varchar(255) NOT NULL,`score` int(11) NOT NULL,`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`id`),KEY `name_score` (`name`(191),`score`),KEY `create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

這個表除了主鍵索引之外，還有另外兩個索引, name_score 及 create_time。然后我們在此表中插入 10 w 行數據，只要寫一個存儲過程調用即可，如下:

CREATE PROCEDURE insert_person() begindeclare c_id integer default 1;while c_id<=100000 doinsert into person values(c_id, concat('name',c_id), c_id+100, date_sub(NOW(), interval c_id second));set c_id=c_id+1;end while; end

插入之后我們現在使用 EXPLAIN 來計算下統計總行數到底使用的是哪個索引

EXPLAIN SELECT COUNT(*) FROM person

從結果上看它選擇了 create_time 輔助索引，顯然 MySQL 認為使用此索引進行查詢成本最小，這也是符合我們的預期，使用輔助索引來查詢確實是性能最高的！

我們再來看以下 SQL 會使用哪個索引

SELECT * FROM person WHERE NAME >'name84059' AND create_time>'2020-05-23 14:39:18'

用了全表掃描！理論上應該用 name_score 或者 create_time 索引才對，從 WHERE 的查詢條件來看確實都能命中索引，那是否是使用 **SELECT *** 造成的回表代價太大所致呢，我們改成覆蓋索引的形式試一下

SELECT create_time FROM person WHERE NAME >'name84059' AND create_time > '2020-05-23 14:39:18'

結果 MySQL 依然選擇了全表掃描！這就比較有意思了，理論上采用了覆蓋索引的方式進行查找性能肯定是比全表掃描更好的，為啥 MySQL 選擇了全表掃描呢，既然它認為全表掃描比使用覆蓋索引的形式性能更好，那我們分別用這兩者執行來比較下查詢時間吧

-- 全表掃描執行時間: 4.0 ms SELECT create_time FROM person WHERE NAME >'name84059' AND create_time>'2020-05-23 14:39:18' -- 使用覆蓋索引執行時間: 2.0 ms SELECT create_time FROM person force index(create_time) WHERE NAME >'name84059' AND create_time>'2020-05-23 14:39:18'

從實際執行的效果看使用覆蓋索引查詢比使用全表掃描執行的時間快了一倍！說明 MySQL 在查詢前做的成本估算不準！我們先來看看 MySQL 做全表掃描的成本有多少。

前面我們說了成本主要 IO 成本和 CPU 成本有關，對于全表掃描來說也就是分別和聚簇索引占用的頁面數和表中的記錄數。執行以下命令

SHOW TABLE STATUS LIKE 'person'

可以發現

行數是 100264，我們不是插入了 10 w 行的數據了嗎，怎么算出的數據反而多了，其實這里的計算是估算，也有可能這里的行數統計出來比 10 w 少了，估算方式有興趣大家去網上查找，這里不是本文重點，就不展開了。得知行數，那我們知道 CPU 成本是 100264 * 0.2 = 20052.8。

數據長度是 5783552，InnoDB 每個頁面的大小是 16 KB(2^14=16384)，可以算出頁面數量是 5783552 / 16384 = 353。

也就是說全表掃描的成本是 20052.8 + 353 = 20406。

這個結果對不對呢，我們可以用一個工具驗證一下。在 MySQL 5.6 及之后的版本中，我們可以用 optimizer trace 功能來查看優化器生成計劃的整個過程 ，它列出了選擇每個索引的執行計劃成本以及最終的選擇結果，我們可以依賴這些信息來進一步優化我們的 SQL。

optimizer_trace 功能使用如下

SET optimizer_trace="enabled=on"; SELECT create_time FROM person WHERE NAME >'name84059' AND create_time > '2020-05-23 14:39:18'; SELECT * FROM information_schema.OPTIMIZER_TRACE; SET optimizer_trace="enabled=off";

執行之后我們主要觀察使用 name_score，create_time 索引及全表掃描的成本。

先來看下使用 name_score 索引執行的的預估執行成本:

{"index": "name_score","ranges": ["name84059 <= name"],"index_dives_for_eq_ranges": true,"rows": 25372,"cost": 30447 }

可以看到執行成本為 30447，高于我們之前算出來的全表掃描成本：20406。所以沒選擇此索引執行

注意：這里的 30447 是查詢二級索引的 IO 成本和 CPU 成本之和，再加上回表查詢聚簇索引的 IO 成本和 CPU 成本之和。

再來看下使用 create_time 索引執行的的預估執行成本:

{"index": "create_time","ranges": ["0x5ec8c516 < create_time"],"index_dives_for_eq_ranges": true,"rows": 50132,"cost": 60159,"cause": "cost" }

可以看到成本是 60159,遠大于全表掃描成本 20406，自然也沒選擇此索引。

再來看計算出的全表掃描成本：

{"considered_execution_plans": [{"plan_prefix": [],"table": "`person`","best_access_path": {"considered_access_paths": [{"rows_to_scan": 100264,"access_type": "scan","resulting_rows": 100264,"cost": 20406,"chosen": true}]},"condition_filtering_pct": 100,"rows_for_plan": 100264,"cost_for_plan": 20406,"chosen": true}] }

注意看 cost：20406，與我們之前算出來的完全一樣！這個值在以上三者算出的執行成本中最小，所以最終 MySQL 選擇了用全表掃描的方式來執行此 SQL。

實際上 optimizer trace 詳細列出了覆蓋索引，回表的成本統計情況，有興趣的可以去研究一下。

從以上分析可以看出， MySQL選擇的執行計劃未必是最佳的，原因有挺多，就比如上文說的行數統計信息不準，再比如 MySQL認為的最優跟我們認為不一樣，我們可以認為執行時間短的是最優的，但 MySQL 認為的成本小未必意味著執行時間短。

總結

本文通過一個例子深入剖析了 MySQL 的執行計劃是如何選擇的，以及為什么它的選擇未必是我們認為的最優的，這也提醒我們，在生產中如果有多個索引的情況，使用 WHERE 進行過濾未必會選中你認為的索引，我們可以提前使用 EXPLAIN, optimizer trace 來優化我們的查詢語句。

總結

以上是生活随笔為你收集整理的mysql count(*)使用索引和成本计算的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。