在5.7版本中，InnoDB实现了新的handler的records接口函数，当你需要表上的精确记录个数时，会直接调用该函数进行计算。

使用

实际上records接口函数是在优化阶段调用的，在满足一定条件时，直接去计算行级计数。其explain出来的结果相比老版本也有所不同，这里我们使用sysbench的sbtest表来进行测试，共200万行数据。

  1. mysql> show create table sbtest1\G
  2. *************************** 1. row ***************************
  3.        Table: sbtest1
  4. Create Table: CREATE TABLE `sbtest1` (
  5.   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  6.   `k` int(10) unsigned NOT NULL DEFAULT '0',
  7.   `c` char(120) NOT NULL DEFAULT '',
  8.   `pad` char(60) NOT NULL DEFAULT '',
  9.   PRIMARY KEY (`id`),
  10.   KEY `k_1` (`k`)
  11. ) ENGINE=InnoDB AUTO_INCREMENT=2000001 DEFAULT CHARSET=utf8 MAX_ROWS=1000000
  12. 1 row in set (0.00 sec)
  14. mysql> explain select count(*) from sbtest1\G
  15. *************************** 1. row ***************************
  16.            id: 1
  17.   select_type: SIMPLE
  18.         table: NULL
  19.    partitions: NULL
  20.          type: NULL
  21. possible_keys: NULL
  22.           key: NULL
  23.       key_len: NULL
  24.           ref: NULL
  25.          rows: NULL
  26.      filtered: NULL
  27.         Extra: Select tables optimized away
  28. 1 row in set, 1 warning (0.00 sec)

注意这里Extra里为”Select tables optimized away”，表示在优化器阶段已经被优化掉了。如果给id列带上条件的话，则回退到之前的逻辑

  1. mysql> explain select count(*) from sbtest1 where id > 0\G
  2. *************************** 1. row ***************************
  3.            id: 1
  4.   select_type: SIMPLE
  5.         table: sbtest1
  6.    partitions: NULL
  7.          type: range
  8. possible_keys: PRIMARY
  9.           key: PRIMARY
  10.       key_len: 4
  11.           ref: NULL
  12.          rows: 960984
  13.      filtered: 100.00
  14.         Extra: Using where; Using index
  15. 1 row in set, 1 warning (0.00 sec)

实现

在WL#6742中，为InnoDB实现了handler的records函数接口

函数栈

  1. opt_sum_query
  2. |--> get_exact_record_count
  3.     |--> ha_records
  4.         |--> ha_innobase::records
  5.             |-->row_scan_index_for_mysql
  • HA_HAS_RECORDS：引擎flag，表示是否可以把count(*)下推到引擎层
  • 总是使用聚集索引来进行计算行数
  • 只需要读取主键值，无需去读取外部存储列(row_prebuilt_t::read_just_key)，如果行记录较大的话，就可以节省客观的诸如内存拷贝之类的操作开销
  • 计算过程可中断，每检索1000条记录，检查事务是否被中断
  • 由于只有一次引擎层的调用，减少了Server层和InnoDB的交互，避免了无谓的内存操作或格式转换
  • 对于分区表，在5.7版本已经下推到innodb层，因此分区表的计算方式(ha_innopart::records)是针对每个分区调用ha_innobase::records，再将结果累加起来

相关代码: commit1 commit2

缺点

由于总是强制使用聚集索引，缺点很明显：当二级索引的大小远小于聚集索引，且数据不在内存中时，使用二级索引显然要快些，因此文件IO更少。如下例：

默认情况下检索所有行(以下测试都是在清空buffer pool时进行的)：

  1. mysql> select count(*) from sbtest1;
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. |  2000000 |
  6. +----------+
  7. 1 row in set (3.92 sec)

即时强制指定索引也没用 :(

  1. mysql> select count(*) from sbtest1 force index(k_1);
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. |  2000000 |
  6. +----------+
  7. 1 row in set (3.86 sec)

但如果带上一个简单的条件，让select count(*)走索引k_1，耗费的时间立马下降了….

  1. mysql> select count(*) from sbtest1 where k > 0;
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. |  2000000 |
  6. +----------+
  7. 1 row in set (1.05 sec)

个人认为这算是一个性能退化，退一步讲，如果用户知道force index能够走一个更好的索引来计算行数，优化器应该做出选择，而不是总是无条件选择聚集索引，提了个Bug到官方

其他

从WL#6742还提到了一个尚未公布的WL#6605，从其只言片语中可以推断官方有意向实现即时获得行数：

  1. The next worklog, WL#6605, is intended to return the COUNT(*) through this handler::records() interface almost immediately in all conditions just by keeping track if the base committed count along with transaction deltas

让我们继续对新版本保持期待吧 :)