MySQL innodb 大数据表 count 业务优化

背景：
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、大于等于1万时，页面显示为10000+这样模糊的数字；

优化前的SQL语句：
select count(*) from tabA where {条件}
记录总数：26330191
耗时：646s

优化后的SQL语句：
select count(*) from (
select id from tabA where {条件} limit 10000
) tt
记录总数：10000
耗时：2s

总结：
当数据库的调优已经没有再进步的空间时，一定要从业务层面入手进行优化；
无论是上缓存机制、NoSQL、主从等，这些必要的性能手段一定要结合业务层的优化；

调优参考：
1、参照了各类数据库配置参数调优；
2、参照innodb引擎下count()函数的效率优化；
3、参照explain语句时出给的模糊信息；
通过上述参考文档，均未能从技术层面解决innodb引擎大数据表的count效率问题，因此才着手从业务层面进行优化。