深入理解select count(*)底层究竟做了什么

A：从 MVCC 机制与行可见性问题中可得到原因，每个事务所看到的行可能是不一样的，其 count( * )结果也可能是不同的;反过来看，则是 MySQL-Server 端无法在同一时刻对所有用户线程提供一个统一的读视图，也就无法提供一个统一的 count 值。

PS: 对于多个访问 MySQL 的用户线程 ( COUNT( * ) ) 而言，决定它们各自的结果的因素有几个: 

• 一组事务执行前的数据状态(初始数据状态)。
• 有时间重叠的事务们的执行序列 (操作时序，事务理论表明 并发事务操作的可串行化是正确性的必要条件)。
• 事务们各自的隔离级别(每个操作的输入)。

其中 1、2 对于 Server 而言都是全局或者说可控的，只有 3 是每个用户线程中事务所独有的属性，这是 Server 端不可控的因素，因此 Server 端也就对每个 COUNT( * ) 结果不可控了。

Q：InnoDB-COUNT( * ) 属 table scan 操作，是否会将现有 Buffer Pool 中其它用户线程所需热点页从 LRU-list 中挤占掉，从而其它用户线程还需从磁盘 load一次，突然加重 IO 消耗，可能对现有请求造成阻塞?

A：MySQL 有这样的优化策略，将扫表操作所 load的 page 放在 LRU-list 的 oung/old 的交界处 ( LRU 尾部约 3/8 处 )。这样用户线程所需的热点页仍然在 LRU-list-young 区域，而扫表操作不断 load 的页则会不断冲刷old区域的页，这部分的页本身就是被认为非热点的页，因此也相对符合逻辑。

PS: 个人认为还有一种类似的优化思路，是限定扫描操作所使用的 Buffer Pool 的大小为 O(1) 级别，但这样做需要付出额外的内存管理成本。 

Q：InnoDB-COUNT( * ) 是否会像 SELECT * FROM t 那样读取存储大字段的溢出页(如果存在)?

A：否。因为 InnoDB-COUNT( * ) 只需要数行数，而每一行的主键肯定不是 NULL，因此只需要读主键索引页内的行数据，而无需读取额外的溢出页。

blog.didiyun.com/index.php/2019/01/08/mysql-count/  

【编辑推荐】

1. MySQL亿级数据数据库优化方案测试-银行交易流水记录的查询
2. 层次查询SQL性能故障不断？给你份可靠的避坑指南！
3. 分析NoSQL比较火的三个数据库Memcached、Redis、MongoDB
4. MySQL痿了，放不下这么多数据！
5. 除了不要 SELECT *，数据库还有哪些技巧

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!