MySQL count count 字段實現(xiàn)上差別

2024-07-24 12:31:33

字體：大中小

供稿：網(wǎng)友

水平有限如有誤請指出
源碼版本：5.7.22

我們繼續(xù)來討論一下count(*) count(字段) 實現(xiàn)上的區(qū)別。注意我們這里都使用Innodb做為存儲引擎，不討論其他引擎。因為了有了前面的討論，更容易看出它們的區(qū)別，這里我們有如下注意點：

我們需要做到執(zhí)行計劃一樣，這里一全表掃描為例。實際上count 很可能使用到覆蓋索引（Using index），本文主要討論它們實現(xiàn)的異同。
count(*)和count(字段) 在結(jié)果上可能并不一致。比如count(字段)，但是某些行本字段為NULL的話那么將不會統(tǒng)計行數(shù)，下面將會說明這種NULL判斷的位置。
本文還是使用簡單的全表掃描來進行對比實現(xiàn)上的區(qū)別。首先我們要明確的是count使用的是一個COUNT計數(shù)器。

一、使用示例
在示例中我們也可以看到兩個語句的結(jié)果實際上并不一致

mysql> show create table baguai_f /G
*************************** 1. row ***************************
       Table: baguai_f
Create Table: CREATE TABLE `baguai_f` (
  `id` int(11) DEFAULT NULL,
  `a` varchar(20) DEFAULT NULL,
  `b` varchar(20) DEFAULT NULL,
  `c` varchar(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> select * from baguai_f ;
+------+------+------+------+
| id   | a    | b    | c    |
+------+------+------+------+
|    1 | g    | g    | NULL |
|    1 | g1   | g1   | g1   |
|    3 | g2   | g2   | g2   |
|    4 | g    | g    | NULL |
|    5 | g    | g    | NULL |
|    6 | g3   | g3   | g3   |
+------+------+------+------+
6 rows in set (0.00 sec)
mysql> desc select count(*) from baguai_f where b='g';
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE      | baguai_f | NULL       | ALL | NULL          | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)
mysql> desc select count(c) from baguai_f where b='g';
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE      | baguai_f | NULL       | ALL | NULL          | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)
mysql> select count(*) from baguai_f where b='g';
+----------+
| count(*) |
+----------+
|        3 |
+----------+
1 row in set (0.00 sec)
mysql> select count(c) from baguai_f where b='g';
+----------+
| count(c) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)
這種不一致來自于b=’g’的c列中都是NULL值，因此count(c)返回為0。

二、示例中 count(*) 獲取數(shù)據(jù)流程簡析
注意在《MySQL：查詢字段數(shù)量多少對查詢效率的影響》一文中我們已經(jīng)詳細的描述了部分流程，這里不再熬述，如果需要更加詳細的了解，自行參考。

1、MySQL層構(gòu)建read_set

這里構(gòu)建的read_set實際上只會包含列b，即一個字段。

2、Innodb層構(gòu)建模板

同理根據(jù)read_set構(gòu)建的字段模板中只會包含列b。

LOOP：這里開始循環(huán)返回每一條數(shù)據(jù)
3、Innodb層根據(jù)模板返回數(shù)據(jù)

這里我們可以看看模板的數(shù)量和模板對應(yīng)的具體列名

模板的數(shù)量
斷點：row_sel_store_mysql_rec
查看模板數(shù)量：
(gdb) p prebuilt->n_template
$1 = 1
查看模板對應(yīng)的字段
斷點：row_sel_field_store_in_mysql_format_func
查看模板對應(yīng)的字段：
(gdb) p field->name
$3 = {m_name = 0x7ffe7c99cf85 "b"}
顯然這里只是將b列的值返回給了MySQL層，這里也很好理解，因為b列在MySQL層需要繼續(xù)做過濾操作。

4、MySQL層過濾條件b=’g’

好了當(dāng)前返回給MySQL層的數(shù)據(jù)中只有b列的數(shù)據(jù)，然后施加b=’g’這個條件進行過濾。

5、MySQL層過濾后做一個COUNT計數(shù)操作

對于普通的select語句過濾后的數(shù)據(jù)就可以返回了，但是對于count這種操作，這里做的是一個計數(shù)操作，其中行會對count 字段的NULL值進行判斷，當(dāng)然這里是count（*）也就不存在NULL值判斷了，下面是這段代碼：

bool Item_sum_count::add()
{
  if (aggr->arg_is_null(false))
    return 0;
  count++;
  return 0;
}
END LOOP
最終我們只需要返回這個計數(shù)就可以了。下面是發(fā)送的數(shù)據(jù)，斷點可以設(shè)置在Query_result_send::send_data中。

$22 = Item::SUM_FUNC_ITEM
(gdb) p ((Item*)(items)->first->info)->field_type()
$23 = MYSQL_TYPE_LONGLONG
(gdb) p ((Item*)(items)->first->info)->val_int()
$24 = 3
(gdb) p (items)->first->info
$26 = (void *) 0x7ffe7c006580
(gdb) p ((Item_sum_count*)$26)->count
$28 = 3
我們可以發(fā)送的數(shù)據(jù)實際就是這個計數(shù)器，最終值為3。

三、示例中 count(c) 獲取數(shù)據(jù)流程的不同
實際上整個流程基本一致，但是區(qū)別在于：

構(gòu)建的read_set 不同，模板個數(shù)自然不同，因為需要2個字段，即b、c兩個字段，其中b列用于where條件過濾，而b列用于統(tǒng)計是否有NULL值，因此模板數(shù)量為2，如下：
(gdb) p prebuilt->n_template
$29 = 2
做COUNT計數(shù)器的時候會根據(jù)c 列的NULL值做實際的過濾，操作只要是NULL則count計數(shù)不會增加1，這個還是參考這段代碼：
bool Item_sum_count::add()
{
  if (aggr->arg_is_null(false)) //過濾NULL值
    return 0;
  count++;
  return 0;
}
最終會調(diào)入函數(shù)Field::is_null進行NULL值判斷，斷點可以設(shè)置在這里。

四、不同點總結(jié)
示例中的語句count(c)返回為0。現(xiàn)在我們很清楚了，這些數(shù)據(jù)什么時候過濾掉的，總結(jié)如下：

Innodb層返回了全部的行數(shù)據(jù)。
MySQL層通過where條件過濾，剩下了b=’g’的行。
MySQL層通過NULL判斷，將剩下的count(c)中為NULL的行也排除在計數(shù)之外。
而count(*)則沒有第3步，這是一個不同。

然后的不同點就是在返回的字段上：

count(c) 很明顯除了where條件以外，還需要返回c列給MySQL層
count(*) 則不需要返回額外的字段給MySQL層，只需要MySQL層過濾需要的b列即可。
通過上面的分析，實際上效率沒有太大的差別，我覺得同樣執(zhí)行計劃，同樣返回數(shù)據(jù)結(jié)果的前提下，可能count(*)的效率要略微高一點。

五、備用棧幀
NULL值計數(shù)過濾棧幀
#0 Field::is_null (this=0x7ffe789949d8, row_offset=0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/field.h:1129
#1 0x0000000000fbc678 in Item_field::is_null (this=0x7ffe78006a78) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item.h:2929
#2 0x000000000146ebf5 in Aggregator_simple::arg_is_null (this=0x7ffe78b451d0, use_null_value=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_sum.cc:1633
#3 0x000000000146ef18 in Item_sum_count::add (this=0x7ffe780066c0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_sum.cc:1683
#4 0x0000000001478475 in Aggregator_simple::add (this=0x7ffe78b451d0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_sum.h:682
#5 0x0000000001478301 in Item_sum::aggregator_add (this=0x7ffe780066c0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_sum.h:526
#6 0x000000000157fd0b in update_sum_func (func_ptr=0x7ffe78007740) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:535
#7 0x0000000001585d3e in end_send_group (join=0x7ffe78007370, qep_tab=0x7ffe78007bd0, end_of_records=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:3117
#8 0x0000000001582059 in evaluate_join_record (join=0x7ffe78007370, qep_tab=0x7ffe78007a58)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:1645
#9 0x000000000158145a in sub_select (join=0x7ffe78007370, qep_tab=0x7ffe78007a58, end_of_records=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:1297
#10 0x0000000001580cce in do_select (join=0x7ffe78007370) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:950

（編輯：武林網(wǎng)）

上一篇：MySQL 產(chǎn)生大量小relay log的故障一例

下一篇：MySQL 5.7安裝部署總結(jié)