納尼？MySQL 中 count(*) 比 count(1) 快？
今天有人跟我講 MySQL 中 count(1) 比 count(*) 快，這能忍?必須得和他掰扯掰扯。
聲明：以下討論基于 InnoDB 存儲(chǔ)引擎，MyISAM 因?yàn)榍闆r特殊我在文末會(huì)單獨(dú)說(shuō)一下。
先說(shuō)結(jié)論：這兩個(gè)性能差別不大。
1.實(shí)踐
我準(zhǔn)備了一張有 100W 條數(shù)據(jù)的表，表結(jié)構(gòu)如下：
- CREATE TABLE `user` (
- `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
- `username` varchar(255) DEFAULT NULL,
- `address` varchar(255) DEFAULT NULL,
- `password` varchar(255) DEFAULT NULL,
- PRIMARY KEY (`id`)
- ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
可以看到，有一個(gè)主鍵索引。
我們來(lái)用兩種方式統(tǒng)計(jì)一下表中的記錄數(shù)，如下：
可以看到，兩條 SQL 的執(zhí)行效率其實(shí)差不多，都是 0.14s。
再來(lái)看另外兩個(gè)統(tǒng)計(jì)：
id 是主鍵，username 以及 address 則是普通字段。
可以看出，用 id 來(lái)統(tǒng)計(jì)，也有一丟丟優(yōu)勢(shì)。松哥這里因?yàn)闇y(cè)試數(shù)據(jù)樣板比較小，所以效果不明顯，小伙伴們可以加大測(cè)試數(shù)據(jù)量，那么這種差異會(huì)更加明顯。
那么到底是什么原因造成的這種差異，接下來(lái)我們就來(lái)簡(jiǎn)單分析一下。
2. explain 分析
我們先用 explain 來(lái)看下這幾個(gè) SQL 不同的執(zhí)行計(jì)劃：
可以看到，前三個(gè)統(tǒng)計(jì)方式的執(zhí)行計(jì)劃是一樣的，后面兩個(gè)是一樣的。
我這里和大家比較下 explain 中的不同項(xiàng)：
- type：前三個(gè)的 type 值為 index，表示全索引掃描，就是把整個(gè)索引過(guò)一遍就行(注意是索引不是整個(gè)表);后兩個(gè)的 type 值為 all，表示全表掃描，即不會(huì)使用索引。
- key：這個(gè)表示 MySQL 決定采用哪個(gè)索引來(lái)優(yōu)化對(duì)該表的訪問(wèn)，PRIMARY 表示利用主鍵索引，NULL 表示不用索引。
- key_len：這個(gè)表示 MySQL 使用的鍵長(zhǎng)度，因?yàn)槲覀兊闹麈I類(lèi)型是 INT 且非空，所以值為 4。
- Extra：這個(gè)中的 Using index 表示優(yōu)化器只需要通過(guò)訪問(wèn)索引就可以獲取到需要的數(shù)據(jù)(不需要回表)。
通過(guò) explain 我們其實(shí)也能大概看出來(lái)前三種統(tǒng)計(jì)方式的執(zhí)行效率是要高一些的(因?yàn)橛玫搅怂饕?，而后面兩種的統(tǒng)計(jì)效率相對(duì)來(lái)說(shuō)要低一些的(沒(méi)用索引，需要全表掃描)。
僅有上面的分析還不夠，我們?cè)賮?lái)從原理角度來(lái)分析一下。
3. 原理分析
3.1 主鍵索引與普通索引
在開(kāi)始原理分析以前，我想先帶領(lǐng)大家看一下 B+ 樹(shù)，這對(duì)于我們理解接下來(lái)的內(nèi)容有重要作用。
大家都知道，InnoDB 中索引的存儲(chǔ)結(jié)構(gòu)都是 B+ 樹(shù)(至于什么是 B+ 樹(shù)，和 B 樹(shù)有什么區(qū)別，這個(gè)本文就不討論了，這兩個(gè)單獨(dú)都能整出來(lái)一篇文章)，主鍵索引和普通索引的存儲(chǔ)又有所不同，如下圖表示主鍵索引：
可以看到，在主鍵索引中，葉子結(jié)點(diǎn)保存了每一行的數(shù)據(jù)。
而在普通索引中，葉子結(jié)點(diǎn)保存的是主鍵值，當(dāng)我們使用普通索引去搜索數(shù)據(jù)的時(shí)候，先在葉子結(jié)點(diǎn)中找到主鍵，再拿著主鍵去主鍵索引中查找數(shù)據(jù)，相當(dāng)于做了兩次查找，這也就是我們平常所說(shuō)的回表操作。
3.2 原理分析
不知道小伙伴們有沒(méi)有注意過(guò)，我們學(xué)習(xí) MySQL 的時(shí)候，count 函數(shù)是歸在聚合函數(shù)那一類(lèi)的，就是 avg、sum 等，count 函數(shù)和這些歸在一起，說(shuō)明它也是一個(gè)聚合函數(shù)。
既然是聚合函數(shù)，那么就需要對(duì)返回的結(jié)果集進(jìn)行一行行的判斷，這里就涉及到一個(gè)問(wèn)題，返回的結(jié)果是啥?我們分別來(lái)看：
對(duì)于 select count(1) from user; 這個(gè)查詢來(lái)說(shuō)，InnoDB 引擎會(huì)去找到一個(gè)最小的索引樹(shù)去遍歷(不一定是主鍵索引)，但是不會(huì)讀取數(shù)據(jù)，而是讀到一個(gè)葉子節(jié)點(diǎn)，就返回 1，最后將結(jié)果累加。
對(duì)于 select count(id) from user; 這個(gè)查詢來(lái)說(shuō)，InnoDB 引擎會(huì)遍歷整個(gè)主鍵索引，然后讀取 id 并返回，不過(guò)因?yàn)?id 是主鍵，就在 B+ 樹(shù)的葉子節(jié)點(diǎn)上，所以這個(gè)過(guò)程不會(huì)涉及到隨機(jī) IO(并不需要回表等操作去數(shù)據(jù)頁(yè)拿數(shù)據(jù))，性能也是 OK 的。
對(duì)于 select count(username) from user; 這個(gè)查詢來(lái)說(shuō)，InnoDB 引擎會(huì)遍歷整張表做全表掃描，讀取每一行的 username 字段并返回，如果 username 在定義時(shí)候設(shè)置了 not null，那么直接統(tǒng)計(jì) username 的個(gè)數(shù);如果 username 在定義的時(shí)候沒(méi)有設(shè)置 not null，那么就先判斷一下 username 是否為空，然后再統(tǒng)計(jì)。
最后再來(lái)說(shuō)說(shuō) select count(*) from user; ，這個(gè) SQL 的特殊之處在于它被 MySQL 優(yōu)化過(guò)，當(dāng) MySQL 看到 count(*) 就知道你是想統(tǒng)計(jì)總記錄數(shù)，就會(huì)去找到一個(gè)最小的索引樹(shù)去遍歷，然后統(tǒng)計(jì)記錄數(shù)。
因?yàn)橹麈I索引(聚集索引)的葉子節(jié)點(diǎn)是數(shù)據(jù)，而普通索引的葉子節(jié)點(diǎn)則是主鍵值，所以普通索引的索引樹(shù)要小一些。然而在上文的案例中，我們只有主鍵索引，所以最終使用的就是主鍵索引。
現(xiàn)在，如果我修改上面的表，為 username 字段也添加索引，然后我們?cè)賮?lái)看 explain select count(*) from user; 的執(zhí)行計(jì)劃：
可以看到，此時(shí)使用的索引就是 username 索引了，和我們前面的分析結(jié)果是一致的。
從上面的描述中我們就可以看出，第一個(gè)查詢性能最高，第二個(gè)次之(因?yàn)樾枰x取 id 并返回)，第三個(gè)最差(因?yàn)樾枰頀呙?，第四個(gè)的查詢性能則接近第一個(gè)。
4. MyISAM 呢?
可能有小伙伴知道，MyISAM 引擎中的 select count(*) from user; 操作執(zhí)行起來(lái)是非?？斓?，那是因?yàn)?MyISAM 把表中的行數(shù)直接存在磁盤(pán)中了，需要的時(shí)候直接讀取出來(lái)就行了，所以非?？?。
MyISAM 引擎之所以這樣做，主要是因?yàn)樗遣恢С质聞?wù)的，所以它的統(tǒng)計(jì)實(shí)際上就非常容易，添加一行記錄一行就行了。
而我們常用的 InnoDB 卻不能這樣做!為啥?因?yàn)?InnoDB 支持事務(wù)!為了支持事務(wù)，InnoDB 引入了 MVCC 多版本并發(fā)控制，所以在數(shù)據(jù)讀取的時(shí)候可能會(huì)有臟讀、幻讀以及不可重復(fù)讀等問(wèn)題，具體可以參考 https://www.bilibili.com/video/BV14L4y1B7mB 視頻。
所以，InnoDB 需要將每一行數(shù)據(jù)拿出來(lái)，判斷該行數(shù)據(jù)對(duì)當(dāng)前會(huì)話是否可見(jiàn)，如果可見(jiàn)，就統(tǒng)計(jì)該行數(shù)據(jù)，否則不予統(tǒng)計(jì)。
當(dāng)然，MySQL 中的 MVCC 實(shí)際上是一個(gè)非常宏大的話題，松哥以后有空了再和大家詳細(xì)介紹 MVCC。
好啦，現(xiàn)在小伙伴們懂了吧?有問(wèn)題歡迎留言討論。
