摘要：會話在插入一條新數(shù)據(jù)，在查詢時的結(jié)果是時會話語句已經(jīng)提交，所以在會話的事務(wù)中能看到這個更新。由于會話在時事務(wù)還沒有提交，會話看不到會話的更新，所以會話在時的結(jié)果是。

相信每個人在寫代碼時都有遇到過要獲取MYSQL表里數(shù)據(jù)行數(shù)的情況，多數(shù)人獲取數(shù)據(jù)表行數(shù)時都用COUNT(*)，但同時也流傳了不少其他方式，比如說COUNT(1)、COUNT(主鍵)、COUNT(字段)。到底哪種方式MYSQL執(zhí)行起來更快也是眾說紛紜，其實之前我也不知道到底哪個執(zhí)行起來快，到底誰說的對(笑哭)。好在最近在認(rèn)真學(xué)習(xí)極客時間的MySQL專欄，其中專門有一節(jié)是對這個問題的討論，看完后也是解除了長久以來的疑惑。

文章中都是針對MySQL的InnoDB引擎展開討論的，MyISAM引擎是把一個表的總行數(shù)記錄在了磁盤里，查詢時效率很高(如果加了where條件也不能直接從磁盤返回)。而InnoDB由于多版本并發(fā)控制（MVCC）的原因，即使時同一時刻的查詢InnoDB表應(yīng)該"返回多少行"也是不確定的，比如假設(shè)表t中有10000行數(shù)據(jù)：

會話A在T1開啟事務(wù)拿到一致性視圖，可重復(fù)讀級別下在事務(wù)中任何時刻讀到數(shù)據(jù)都一樣，其他事務(wù)的更新對會話A沒影響所以count(*)的結(jié)果是10000，會話B在T4開啟事務(wù)拿到一致性視圖，T4之前會話C已經(jīng)新插入了一條語句并提交（多帶帶執(zhí)行一條更新語句，InnoDB會自己啟動一個事務(wù)，語句執(zhí)行完馬上提交）。會話B在T5插入一條新數(shù)據(jù)，在T6查詢時count(*)的結(jié)果是10002(T4 begin時會話C insert語句已經(jīng)提交，所以在會話B的事務(wù)中能看到這個更新)。由于會話B在T6時事務(wù)還沒有提交，會話C看不到會話B的更新，所以會話C在T6時count(*)的結(jié)果是10001。

COUNT是一個聚合函數(shù)，它的功能是對返回的結(jié)果集中每一行進(jìn)行判斷，如果COUNT函數(shù)的參數(shù)不是NULL則累加1，否則不累加，最后返回累計值。接下來看一下每個COUNT版本的執(zhí)行效率：

COUNT(主鍵ID) InnoDB遍歷全表，把每一行的主鍵值都取出來返回給MySQL的Server層，因為主鍵不可能為NULL，Server層直接按行累加最后返回累計值給客戶端。

COUNT(1) 遍歷全表但不取值，Server層對返回的每一行放個數(shù)字"1"進(jìn)去，按行累加。COUNT(1)比COUNT(主鍵)快，因為不需要取值，減少了數(shù)據(jù)傳輸。

COUNT(字段) 遍歷全表，一行行從記錄中讀出字段值給Server層，Server層判斷值不為NULL了再累加。

COUNT(*) MySQL專門做了優(yōu)化，會找到表中最小的索引樹，InnoDB普通索引樹比主鍵索引小很多，對于COUNT(*)遍歷哪個樹是一樣的，count(*)時MySQL不取記錄值，count(*)也肯定不為NULL，Server層中直接按行累加。

所以這個版本COUNT的從低到高分別為：

COUNT(字段) < COUNT(主鍵) < COUNT(1) ≈ COUNT(*)

所以建議你盡量使用count(*)來獲取記錄行數(shù)。

另外要注意，很多人為了銷量會把表的行數(shù)記錄到Redis中，但這樣不能保證Redis里的計數(shù)和MySQL表里的數(shù)據(jù)保持精確一致，這是兩個不同的存儲系統(tǒng)不支持分布式事務(wù)所以就無法拿到精確的一致性視圖，如果為了效率把表行數(shù)多帶帶存儲那么最好存放在一個多帶帶的MySQL表里，這樣無法拿到一致性視圖的問題就能解決了。

關(guān)于MySQL更詳細(xì)的分析，推薦關(guān)注MySQL實戰(zhàn)45講