MySQL innodb 大数据表 count 业务优化

最新推荐文章于 2024-07-01 11:30:48 发布

bifhvX123

最新推荐文章于 2024-07-01 11:30:48 发布

阅读量1.2k

点赞数

分类专栏： MySQL 文章标签： MySQL innodb 大数据表 count 优化

本文链接：https://blog.csdn.net/bifhvX123/article/details/90903943

版权

本文讲述了在MySQL 8.0.15版本中，针对2600万+数据的InnoDB表进行count操作时遇到的性能问题。随着数据量增长，查询性能下降。第一次优化是通过异步加载解决，但随着数据量进一步增加，这种方法变得不可行。最终，通过业务调整，当记录数超过1万时显示模糊数字，从而显著提升了性能。优化后的SQL语句耗时从646秒降低到2秒，强调了在数据库调优无效时，结合业务层面的优化至关重要。

摘要由CSDN通过智能技术生成

在这里插入图片描述
背景：
MySQL 版本：8.0.15
A表数据量：2600万+，分区32个，innodb引擎

背景介绍：
由于A表是记录数最大的数据表，由上线之初的100万数据，迅速增长到500万、1000万，现在数据量在2600万左右。预计未来1年内增长到1亿+。
运营管理端对A表有数据列表、条件匹配查询、分页的业务功能。
A表数据量在100万时，没有出现性能问题。
A表数据量涨到500万时，获取匹配条件记录总数的count语句性能出现了，影响了该版块的整体效率。
第一次优化：
将数据列表业务和匹配条件记录总数业务拆分，通过异步方式加载匹配条件记录总数。
表现出的效果为列表数据加载完成后，10秒内记录总数和分页会出现。暂时满足了运营部门的业务需求。
但随着数量的增长到1000万时，记录总数业务越来越慢，无法满足运营部门的需求。

优化思路：
向运营部门讲明白了数据记录总数慢的原因，以及从MySQL本身及SQL调优方面入手优化这个思路几乎没有优化的空间了，建议从业务层面进行优化；
通过磋商，当记录数超过1万+时，系统传达出的匹配记录总数为1万+和一个具体的数字，对于运营人员意义几乎是一致的。而小于1万+时，精确的数字是有意义的。
因此，优化思路如下：
1、当匹配记录总数小于1万时，统计出具体数字；
2、大于等于