這篇文章依然源于一位讀者的提問：explain 顯示 count(*) 使用了索引，optimizer trace 卻顯示為全表掃描，這是為什么？

還記得當時調試源碼的過程中，如果 explain 顯示會使用二級索引進行全索引掃描，執行時也確實只會從二級索引中讀取記錄，不會進行全表掃描。

不過，那會沒有關注過 optimizer trace 是怎么顯示的。

既然不能從記憶里找到答案，那就只能從源碼里找答案了。

擼完源碼發現：和 5.7.35 版本相比，8.0.32 的 count(*) 實現邏輯，確實有了一些變化。

接下來，我們一起來看看。

本文基于 MySQL 8.0.32 源碼，存儲引擎為 InnoDB。如需轉載，請聯系『一樹一溪』公眾號作者。

1、準備工作

創建測試表：

CREATE TABLE `t1` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `i1` int DEFAULT '0',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_i1` (`i1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

插入數據：

INSERT INTO `t1`(`id`, `i1`)
VALUES (10, 101), (20, 201), (30, 301);

2、問題重現及分析

explain 查看執行計劃：

EXPLAIN SELECT COUNT(*) FROM `t1`;

結果如下（只截取了部分字段）：

圖片

再來看看 optimizer trace 描述的執行計劃，依次執行以下 3 條 SQL：

-- 開啟 optimizer trace
SET optimizer_trace = "enabled=on";

-- 執行 SELECT 語句
SELECT COUNT(*) FROM `t1`;

-- 獲取 optimizer trace
SELECT * FROM information_schema.optimizer_trace;

結果如下（只截取了部分內容）：

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

我們來對比下 explain 和 optimizer trace 的結果：

• explain 輸出結果中，type 字段值為 index、key 字段值為 idx_i1，表示會使用 idx_i1 作為覆蓋索引執行 select 語句。由于沒有 where 條件，select 語句會對二級索引 idx_i1 進行全索引掃描，以獲取 t1 表的記錄數量。
• optimizer trace 輸出結果中，沒有顯示會使用索引 idx_i1，而且，access_type 為 scan，看起來像是會進行全表掃描。

我在 5.7.35 中調試了這條 SQL：

SELECT COUNT(*) FROM `t1`

可以證實，select 語句執行過程中，確實對 idx_i1 進行了全索引掃描，和 explain 輸出的執行計劃一致。

同時也確認了：不管是對主鍵索引進行全索引掃描（也就是全表掃描），還是對二級索引進行全索引掃描，optimizer trace 的輸出結果中，access_type 字段值都是 scan。

我又在 8.0.32 中調試了上面的 SQL，發現了新情況：InnoDB 對不包含 where 條件的 select count(*) from table 語句進行了特殊處理。

跟隨調試過程，我們一起來看看 InnoDB 做了什么特殊處理。

程序執行到 ha_records() 方法時，我們可以看到，index 參數的值是 1，這就是執行計劃確定要使用的索引 ID。

圖片

我們在調試控制臺打印索引名字，可以看到 ID = 1 的索引就 idx_i1：

圖片

ha_records() 會調用 records_from_index()，代碼如下：

圖片

從以上代碼可以看到，ha_records() 把索引 idx_i1 的 ID 傳給了 records_from_index() 的第 2 個參數，但是，該方法的第 2 個參數，只有類型（uint），沒有名字，這說明第 2 個參數不能被使用。

也就是說，雖然執行計劃確定了要使用索引 idx_i1 來統計 t1 表的記錄數量，records_from_index() 卻沒有真正使用 idx_i1。

從代碼注釋也可以看到：在實現二級索引的并行掃描之前，records_from_index() 會強制使用主鍵索引來統計表中的記錄數量。

在 github 中追溯代碼提交歷史，發現 records_from_index() 是 8.0.17 版本新加的。

從這個版本開始，到最新的 8.0.33，對于不包含 where 條件的 select count(*) from table 語句，都會強制使用主鍵索引（也就是會進行全表掃描）。

之所以這么做，是為了使用多個線程對主鍵索引進行并行掃描，以提升執行速度。

3、總結

雖然本文內容比較短，但是本著完整的原則，還是進行個簡單的總結：

• 8.0.16（含）版本之前，對于 select count(*) from table 語句，如果表中有二級索引，InnoDB 會選擇對某個二級索引進行全索引掃描，以獲取表中的記錄數量。
• 從 8.0.17（含）版本開始，直到目前的最新版本（8.0.33），如果表中有二級索引，explain 輸出的執行計劃也表示會使用二級索引，然而，實際執行過程中，InnoDB 卻會強制進行全表掃描，以使用主鍵索引的并行掃描能力。
• optimizer trace 的結果中，對于 select count(*) from table 語句，二級索引的全索引掃描和全表掃描同等對待，執行計劃的 access_type 字段值都是 scan。