摘要：会话在插入一条新数据，在查询时的结果是时会话语句已经提交，所以在会话的事务中能看到这个更新。由于会话在时事务还没有提交，会话看不到会话的更新，所以会话在时的结果是。
相信每个人在写代码时都有遇到过要获取MYSQL表里数据行数的情况，多数人获取数据表行数时都用COUNT(*)，但同时也流传了不少其他方式，比如说COUNT(1)、COUNT(主键)、COUNT(字段)。到底哪种方式MYSQL执行起来更快也是众说纷纭，其实之前我也不知道到底哪个执行起来快，到底谁说的对(笑哭)。好在最近在认真学习极客时间的MySQL专栏，其中专门有一节是对这个问题的讨论，看完后也是解除了长久以来的疑惑。
文章中都是针对MySQL的InnoDB引擎展开讨论的，MyISAM引擎是把一个表的总行数记录在了磁盘里，查询时效率很高(如果加了where条件也不能直接从磁盘返回)。而InnoDB由于多版本并发控制（MVCC）的原因，即使时同一时刻的查询InnoDB表应该"返回多少行"也是不确定的，比如假设表t中有10000行数据：
| 时刻 | 会话A | 会话B | 会话C |
|---|---|---|---|
| T1 | begin; | ||
| T2 | select count(*) from t; | ||
| T3 | insert into t (插入一行); | ||
| T4 | begin; | ||
| T5 | insert into t (插入一行); | ||
| T6 | select count(*) from t; （返回10000） | select count(*) from t; （返回10002）; | select count(*) from t; （返回10001） |
会话A在T1开启事务拿到一致性视图，可重复读级别下在事务中任何时刻读到数据都一样，其他事务的更新对会话A没影响所以count(*)的结果是10000，会话B在T4开启事务拿到一致性视图，T4之前会话C已经新插入了一条语句并提交（多带带执行一条更新语句，InnoDB会自己启动一个事务，语句执行完马上提交）。会话B在T5插入一条新数据，在T6查询时count(*)的结果是10002(T4 begin时会话C insert语句已经提交，所以在会话B的事务中能看到这个更新)。由于会话B在T6时事务还没有提交，会话C看不到会话B的更新，所以会话C在T6时count(*)的结果是10001。
COUNT是一个聚合函数，它的功能是对返回的结果集中每一行进行判断，如果COUNT函数的参数不是NULL则累加1，否则不累加，最后返回累计值。接下来看一下每个COUNT版本的执行效率：
COUNT(主键ID) InnoDB遍历全表，把每一行的主键值都取出来返回给MySQL的Server层，因为主键不可能为NULL，Server层直接按行累加最后返回累计值给客户端。
COUNT(1) 遍历全表但不取值，Server层对返回的每一行放个数字"1"进去，按行累加。COUNT(1)比COUNT(主键)快，因为不需要取值，减少了数据传输。
COUNT(字段) 遍历全表，一行行从记录中读出字段值给Server层，Server层判断值不为NULL了再累加。
COUNT(*) MySQL专门做了优化，会找到表中最小的索引树，InnoDB普通索引树比主键索引小很多，对于COUNT(*)遍历哪个树是一样的，count(*)时MySQL不取记录值，count(*)也肯定不为NULL，Server层中直接按行累加。
所以这个版本COUNT的从低到高分别为：
COUNT(字段) < COUNT(主键) < COUNT(1) ≈ COUNT(*)
所以建议你尽量使用count(*)来获取记录行数。
另外要注意，很多人为了销量会把表的行数记录到Redis中，但这样不能保证Redis里的计数和MySQL表里的数据保持精确一致，这是两个不同的存储系统不支持分布式事务所以就无法拿到精确的一致性视图，如果为了效率把表行数多带带存储那么最好存放在一个多带带的MySQL表里，这样无法拿到一致性视图的问题就能解决了。
关于MySQL更详细的分析，推荐关注MySQL实战45讲
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/62864.html
摘要：会话在插入一条新数据，在查询时的结果是时会话语句已经提交，所以在会话的事务中能看到这个更新。由于会话在时事务还没有提交，会话看不到会话的更新，所以会话在时的结果是。 相信每个人在写代码时都有遇到过要获取MYSQL表里数据行数的情况，多数人获取数据表行数时都用COUNT(*)，但同时也流传了不少其他方式，比如说COUNT(1)、COUNT(主键)、COUNT(字段)。到底哪种方式MYSQ...
摘要：会话在插入一条新数据，在查询时的结果是时会话语句已经提交，所以在会话的事务中能看到这个更新。由于会话在时事务还没有提交，会话看不到会话的更新，所以会话在时的结果是。 相信每个人在写代码时都有遇到过要获取MYSQL表里数据行数的情况，多数人获取数据表行数时都用COUNT(*)，但同时也流传了不少其他方式，比如说COUNT(1)、COUNT(主键)、COUNT(字段)。到底哪种方式MYSQ...
摘要：根据优化器生成的执行计划，调用存储引擎的来执行查询。常见原因有以下查询不需要的记录。关联子查询的子查询实现是非常糟糕的。建议使用左外连接代替子查询。解决方法参考这篇函数索引分页下面这条查询，非常常见。 欢迎关注公众号：【爱编码】如果有需要后台回复2019赠送1T的学习资料哦！！ showImg(https://segmentfault.com/img/remote/1460000018...
最近遇到一个比较有意思的问题，用户MySQL5.6升级MySQL5.7后，出现MySQL5.7执行count(*)统计类SQL，比MySQL5.6慢很多，并且可以100%复现。初始我们怀疑和Cardinality（基数）采样有关。（详情参考文章：MySQL优化器之Cardinality（Analyzetable））但是经过验证发现Cardinality采样指标并无不妥之处。所以我们就在google...
摘要：有非常多的原因会导致选择错误的执行计划，比如统计信息不准确不会考虑不受其控制的操作成本用户自定义函数存储过程认为的最优跟我们想的不一样我们希望执行时间尽可能短，但值选择它认为成本小的，但成本小并不意味着执行时间短等等。 说起MySQL的查询优化，相信大家收藏了一堆奇技淫巧：不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的理解这些...
阅读 4332·2021-09-29 09:34
阅读 1225·2021-09-24 10:38
阅读 1291·2021-09-22 15:15
阅读 2796·2021-09-09 09:33
阅读 782·2019-08-30 11:08
阅读 522·2019-08-30 10:52
阅读 1124·2019-08-30 10:52
阅读 2195·2019-08-28 18:01
