MySQL 8.0 之后对 count(*) 的优化提升了一倍,是真的吗?

一直以来,MySQL 对 count(*) 的执行都很头疼。MyISAM 引擎自带计数器,可以秒回;不过对 InnoDB 引擎来说实时计算就很头疼了。MySQL8.0 以前有多方法可以变相解决此类问题.

比如:

1、模拟 MyISAM 的计数器

比如要获得表 A 的总数,我们建立两个触发器分别对 insert/delete 来做记录到表 count 表,这样只需要查询表 count 表就可以得到总数。count 这张表并不会很大。不过缺点也很明显,那就是触发器会导致写性能降低。

2、用 MySQL 自带的 sql_calc_found_rows 特性来隐式计算

依然是表 A,不过每次查询的时候用 sql_calc_found_rows 和 found_rows() 来获取总数,比如:

 

 

这样的好处是写法简单,缺点也很明显:一是全表扫,二是结果不一定是完全准确的,不过行记录格式改为 ROW 就结果就没问题了。再回过头来看 warnings 信息:

SQL_CALC_FOUND_ROWS is deprecated and will be removed in a future release. Consider using two separate queries instead

MySQL 8.0 之后要淘汰的语法。

3、从数据字典里面拿出来粗略的值

 

 

缺点也是数据不精确。


4、根据表结构特性特殊的取值

这里假设表 A 的主键是连续的,并且没有间隙,那么可以直接采用max函数

 

 

这种太理想化,对表的数据要求比较高。


5. MySQL 8 建议

MySQL 8.0 建议用常规的写法来实现。

 

 

这种写法是 MySQL 8.0.17 推荐的,也就是说以后大部分场景直接实时计算就 OK 了。


相比 MySQL 5.7,8.0 对 count(*) 做了优化,我们来看看 8.0 比 5.7 在此类查询是否真的有优化?

MySQL 5.7.27

 

 

MySQL 8.0.17

 

 

从以上结果看出,8.0.17 性能(cost_info)相对5.7.27提升了一倍。

posted on   数据派  阅读(337)  评论(0编辑  收藏  举报

编辑推荐:
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
阅读排行:
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· .NET10 - 预览版1新功能体验(一)
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

点击右上角即可分享
微信分享提示