SQL優化之SELECT COUNT(*)

前言

SQL優化之SQL 進階技巧（上） SQL優化之SQL 進階技巧（下）中提到使用如下 sql 會致使慢查詢

SELECT COUNT(*) FROM SomeTable
SELECT COUNT(1) FROM SomeTable

緣由是會形成全表掃描，有位讀者說這種說法是有問題的，實際上針對無 where_clause 的 COUNT(*)，MySQL 是有優化的，優化器會選擇成本最小的輔助索引查詢計數，其實反而性能最高，這位讀者的說法對不對呢

針對這個疑問，我首先去生產上找了一個千萬級別的表使用  EXPLAIN 來查詢了一下執行計劃

EXPLAIN SELECT COUNT(*) FROM SomeTable

結果以下

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

因此這位讀者的說法確實是對的。但有個前提，在 MySQL 5.6 以後的版本中才有這種優化。

那麼這個成本最小該怎麼定義呢，有時候在 WHERE 中指定了多個條件，爲啥最終 MySQL 執行的時候卻選擇了另外一個索引，甚至不選索引？

本文將會給你答案，本文將會從如下兩方面來分析

• SQL 選用索引的執行成本如何計算
• 實例說明

SQL 選用索引的執行成本如何計算

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

• IO 成本: 即從磁盤把數據加載到內存的成本，默認狀況下，讀取數據頁的 IO 成本是 1，MySQL 是以頁的形式讀取數據的，即當用到某個數據時，並不會只讀取這個數據，而會把這個數據相鄰的數據也一塊兒讀到內存中，這就是有名的程序局部性原理，因此 MySQL 每次會讀取一整頁，一頁的成本就是 1。因此 IO 的成本主要和頁的大小有關
• CPU 成本：將數據讀入內存後，還要檢測數據是否知足條件和排序等 CPU 操做的成本，顯然它與行數有關，默認狀況下，檢測記錄的成本是 0.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;
personidnamescorecreate_timeidname_scorenamescorecreate_timecreate_time

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

CREATE PROCEDURE insert_person()
 begin
 declare c_id integer default 1;
     while c_id<=100000 do
 insert 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'

能夠發現

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

2. 數據長度是 5783552，InnoDB 每一個頁面的大小是 16 KB，能夠算出頁面數量是 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 來優化咱們的查詢語句。

相關文章

SQL優化之SQL 進階技巧（上）

SQL優化之SQL 進階技巧（下）