没有不值得去解决的问题,也没有不值得去学习的技术!

在 MySQL 8.0 中,查询表记录总数时,超时的分析优化

一个接口请求响应超时,原因在于 count(*) SQL 耗时 54 秒。表中数据量超过 1000万 条

1、一个接口请求响应超时,原因在于 count(*) SQL 耗时 54 秒。表中数据量超过 1000万 条。如图1

一个接口请求响应超时,原因在于 count(*) SQL 耗时 54 秒。表中数据量超过 1000万 条
图1
SQL

SELECT
	count(*) AS AGGREGATE 
FROM
	`tables`

2、其中表字段 shipping_type 有添加索引,且其值仅有 1、2 两种可能。决定添加 where 条件 shipping_type IN (1,2)。查询时长 3 秒。如图2

其中表字段 shipping_type 有添加索引,且其值仅有 1、2 两种可能。决定添加 where 条件 shipping_type IN (1,2)。查询时长 3 秒
图2
SQL

SELECT
	count(*) AS AGGREGATE 
FROM
	`tables` 
WHERE
	shipping_type IN (
	1,
	2)

3、最终决定基于主键 ID 作为 where 条件,以尽量保持所有 count SQL 的 where 条件的统一。当一条 count SQL 没有 where 条件存在时,就添加 WHERE id > 0。耗时 4 秒,符合预期。如图3

最终决定基于主键 ID 作为 where 条件,以尽量保持所有 count SQL 的 where 条件的统一。当一条 count SQL 没有 where 条件存在时,就添加 WHERE id > 0。耗时 4 秒,符合预期
图3

关于作者 · 持续学习与技术实践

我是一名拥有 15 年以上开发经验的技术从业者,自 2013 年起持续运营个人技术博客,记录工作与个人项目中遇到的真实问题,以及解决问题过程中的探索、实践和思考。

除了技术写作,我也在持续开发和维护自己的独立项目,探索新技术和新工具在实际场景中的应用。我始终相信,没有不值得去解决的问题,也没有不值得去学习的技术。

如果这篇文章对你有所帮助,欢迎浏览博客中的其他文章,也欢迎交流技术经验与想法。

关于我  ·  GitHub  ·  邮件联系

评论

一条对“在 MySQL 8.0 中,查询表记录总数时,超时的分析优化”的回复

  1. […] 1、参考:在 MySQL 8.0 中,查询表记录总数时,超时的分析优化。 在 Navicat 中的执行时长为:3.075秒。如图1 […]