深入理解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 *，数据库尚有哪些能力

（编辑：湖南网）

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