做后端开发、DBA的朋友，几乎都踩过MySQL大表COUNT查询的坑——明明只是想统计一下某张表的总条数，比如“查询用户总数”“统计订单总量”，执行一句SELECT COUNT(*) FROM 表名，结果等了几十秒甚至几分钟，接口直接超时，前端报错，更要命的是，频繁的慢查询还会占满数据库连接，拖垮整个业务，用户投诉不断，领导追问不停。
我之前就遇到过这样的情况：公司业务迭代快，用户表短短半年就从100万条数据涨到了5000万条，原本毫秒级返回的用户总数统计接口，慢慢变成了10秒、20秒，高峰期直接超时失败。运营同事反馈后台数据统计页面打不开，市场部门要做用户复盘，查个总数要等半天，更严重的是，因为这个慢查询，数据库连接池经常被占满，导致正常的用户注册、登录接口也出现卡顿，直接影响了用户留存。
相信很多人都有过类似的经历，一开始以为是SQL写得有问题，反复优化COUNT语句，比如换成COUNT(1)、COUNT(主键)，但效果微乎其微；也有人尝试加索引，但要么加了没用，要么加索引的时候锁表，影响业务正常运行。其实，MySQL大表COUNT查询慢，不是你写的SQL不行，而是MySQL本身的执行机制，决定了它在面对千万级、亿级大表时，COUNT操作天生就“慢”。
今天就用最口语化的方式，跟大家把这件事讲透：为什么MySQL大表COUNT这么慢？哪些常规优化方法没用？真正能解决问题、让查询秒出结果的“缓存计数+索引统计”方案，到底该怎么落地？全程不搞虚的，全是实战干货，不管你是后端开发还是DBA，看完就能直接套用，彻底解决COUNT查询拖垮业务的难题。
首先，我们得搞明白一个核心问题：同样是COUNT查询，为什么小表秒出结果，大表却要等几十秒？这里不是MySQL故意“偷懒”，而是它的执行逻辑决定的。
很多人以为，MySQL里的COUNT(*)，是直接从某个地方拿出一个“总条数”的缓存值，其实根本不是这样。MySQL的COUNT操作，本质上是“逐行统计”——它会扫描表中的每一行数据，判断这一行是否符合查询条件（如果没有WHERE条件，就是扫描所有行），然后累计计数，直到扫描完所有行，才会返回最终的结果。
举个例子，你有一张5000万条数据的用户表，执行SELECT COUNT(*) FROM user，MySQL会从头到位，把这5000万行数据全部扫一遍，每扫一行就加1，扫完之后才告诉你“总共有50000000条”。这个过程就像你要数一个装满大米的麻袋，只能一粒一粒数，数完才能知道总数，自然快不起来。
可能有人会问：那为什么小表就快？因为小表的数据量少，比如10万条数据，扫描一遍只需要几毫秒，感觉不到延迟；但大表的数据量达到千万、亿级，扫描一遍可能需要几十秒，甚至几分钟，这期间，数据库连接会一直被占用，其他需要操作这张表的SQL，就只能排队等待，久而久之，整个数据库的性能就会下降，甚至拖垮业务。
还有一个容易被忽略的点：如果你的表没有主键、没有合适的索引，MySQL会采用“全表扫描”的方式统计，速度会更慢；就算有索引，如果你用的是COUNT(*)，MySQL也可能不会走索引，还是会全表扫描——这里要纠正一个常见的误区：很多人觉得COUNT(1)比COUNT(*)快，其实在MySQL5.7及以上版本，这两种写法的执行效率几乎没有区别，MySQL会自动优化，真正影响速度的，是是否能走索引，以及索引的类型。
再说说我们平时踩过的那些“无效优化”，很多人遇到COUNT查询慢，第一反应就是做这些操作，但其实根本解决不了问题，甚至会帮倒忙。
第一种无效优化：把COUNT(*)改成COUNT(主键)、COUNT(1)。前面已经说过，在新版本的MySQL中，这三种写法的执行计划几乎一致，不会因为改了写法就变快。比如你用COUNT(id)，如果id是主键，MySQL可能会走主键索引，但如果你的表数据量极大，就算走主键索引，扫描一遍所有主键也需要很长时间，速度依然很慢。
第二种无效优化：给表加普通索引。很多人觉得，加个索引就能让COUNT查询走索引，从而变快，但其实不然。如果你的索引是普通索引，比如给user表的name字段加索引，执行COUNT(name)，MySQL确实会走name索引，但普通索引的叶子节点存储的是“索引值+主键值”，扫描普通索引依然需要遍历所有索引节点，速度并没有本质提升；而且，加索引会增加写入成本——插入、更新、删除数据时，都需要维护索引，反而会影响业务的写入性能。
第三种无效优化：限制查询范围，比如用LIMIT。有人想，既然全表扫描慢，那我用SELECT COUNT(*) FROM user LIMIT 10000000，是不是就能快一点？其实完全没用，因为COUNT查询的本质是统计所有符合条件的行数，不管你加不加LIMIT，MySQL都要扫描完所有行才能得到总数，LIMIT在这里没有任何优化效果，反而会让SQL语义变得混乱。
还有一种更危险的操作：直接禁用MySQL的查询缓存。很多人听说“查询缓存能提升查询速度”，就盲目开启，结果发现不仅没效果，反而因为缓存的维护成本，导致数据库性能下降。而且，MySQL8.0版本已经彻底移除了查询缓存功能，就算你用的是低版本，查询缓存也只对“完全相同的SQL”有效，一旦表数据有任何修改，缓存就会失效，对于频繁更新的大表来说，查询缓存几乎没有作用，反而会拖慢性能。
既然这些常规方法没用，那我们该怎么办？其实，解决MySQL大表COUNT查询慢的核心思路，就是“避开全表扫描”——既然逐行统计太慢，那我们就提前把统计结果存起来，需要的时候直接取，或者利用MySQL的索引特性，让统计操作只扫描少量数据，这样就能实现秒出结果。
而目前最实用、最稳定，能直接落地到生产环境的方案，就是“缓存计数+索引统计”结合——缓存计数负责快速返回结果，索引统计负责校准缓存，避免缓存数据不准确，两者结合，既能保证查询速度，又能保证数据的一致性，彻底解决COUNT查询拖垮业务的问题。
先跟大家讲第一个核心方案：缓存计数。缓存计数的思路很简单：既然COUNT查询慢，那我们就把统计结果存到缓存里（比如Redis），每次需要查询总数的时候，直接从缓存里取，不用再去数据库扫描表，这样就能实现毫秒级返回。
具体怎么操作？分为三步，非常简单，看完就能落地。
第一步：初始化缓存。首先，我们需要执行一次全表COUNT查询，把初始的总条数存到Redis里。比如，我们执行SELECT COUNT(*) FROM user，得到结果50000000，然后用Redis的SET命令，把这个值存起来，key可以设置为“user:count”，value就是50000000，同时可以设置一个过期时间，但这里不建议设置太长，也不建议不设置——设置过期时间是为了防止缓存数据长期不更新，导致和数据库数据偏差太大；但过期时间也不能太短，否则会频繁触发缓存失效，又要去数据库查询，反而影响性能，一般设置10-30分钟即可。
第二步：维护缓存一致性。这是最关键的一步，缓存里的计数，必须和数据库里的实际数据保持一致，否则返回的结果就是错误的，反而会影响业务。那怎么维护一致性？核心就是“数据变更时，同步更新缓存”。
比如，当有新用户注册时，执行INSERT INTO user(...) VALUES(...)，此时用户总数增加1，我们就需要在执行插入操作之后，调用Redis的INCR命令，把“user:count”的值加1；当有用户注销（删除数据）时，执行DELETE FROM user WHERE id=...，此时用户总数减少1，调用Redis的DECR命令，把“user:count”的值减1；如果有批量插入、批量删除的操作，就根据实际新增或删除的条数，调用INCRBY或DECRBY命令，批量更新缓存。
这里有一个细节需要注意：更新缓存和更新数据库的顺序，一定要搞对，否则会出现数据不一致的问题。正确的顺序应该是“先更新数据库，再更新缓存”——如果先更新缓存，再更新数据库，万一数据库更新失败，缓存里的数据就会比数据库里的多，导致数据偏差；而先更新数据库，再更新缓存，就算缓存更新失败，下次缓存过期后，重新从数据库查询初始化，也能恢复一致，相对更安全。
另外，如果你的业务对数据一致性要求不是特别高（比如允许缓存和数据库有1-2分钟的偏差），可以不用每次数据变更都同步更新缓存，而是采用“定时更新”的方式——比如每隔10分钟，执行一次全表COUNT查询，更新Redis里的缓存值，这样可以减少缓存更新的频率，降低系统开销；但如果业务对数据一致性要求很高（比如实时统计用户总数），就必须采用“实时同步更新”的方式。
第三步：缓存失效处理。就算我们维护得再好，也可能出现缓存失效的情况——比如Redis宕机、缓存过期、缓存被意外删除，这时候就需要有兜底方案，避免接口报错。兜底方案很简单：当从Redis中获取不到缓存值，或者缓存值为空时，直接去数据库执行COUNT查询，获取最新的总数，然后更新到Redis中，同时返回结果。这样就算缓存失效，也能保证接口正常返回，只是偶尔会有一次慢查询，但不会影响整体业务。
缓存计数的优势很明显：实现简单，不需要修改太多代码，查询速度极快，毫秒级就能返回结果，能彻底解决COUNT查询拖慢业务的问题；但它也有一个缺点：缓存和数据库之间可能会有短暂的偏差，而且如果出现批量数据变更（比如批量导入10万条用户数据），同步更新缓存时，可能会有一定的延迟。
所以，我们需要结合第二个方案：索引统计，来校准缓存，减少数据偏差，同时进一步提升查询速度。索引统计的核心思路，是利用MySQL的“覆盖索引”特性，让COUNT查询只扫描索引，而不扫描表数据，从而提升查询速度，同时用索引统计的结果，定期校准缓存中的值，保证数据一致性。
首先，我们要明白什么是覆盖索引。覆盖索引，就是指索引中包含了查询语句所需的所有字段，MySQL在查询时，只需要扫描索引，不需要回表查询表中的数据，这样就能大大提升查询速度。对于COUNT查询来说，如果我们能创建一个合适的覆盖索引，MySQL就能通过扫描这个索引，快速统计出总条数，而不用全表扫描。
那怎么创建合适的覆盖索引？这里有一个关键技巧：创建一个“单列索引”，而且这个字段必须是“非空”的。因为MySQL的COUNT(*)，会统计所有非空的行数，如果我们创建一个非空字段的单列索引，MySQL就能直接扫描这个索引的所有节点，统计出总条数，速度会比全表扫描快很多。
举个例子，我们给user表的id字段（主键，非空）创建主键索引，主键索引本身就是一种覆盖索引，执行SELECT COUNT(*) FROM user，MySQL会走主键索引，扫描所有主键节点，统计总条数，速度会比全表扫描快3-5倍；如果你的表没有主键，也可以给某个非空字段（比如create_time，创建时间，每个用户都有，不会为空）创建一个单列索引，然后执行SELECT COUNT(create_time) FROM user，MySQL会走create_time的索引，快速统计出总条数。
这里要注意两个点：第一，索引字段必须是非空的，如果字段允许为空，MySQL会跳过空值，导致统计结果不准确；第二，尽量选择字段长度小的字段创建索引，比如id（int类型，4个字节），比create_time（datetime类型，8个字节）的索引节点更小，扫描速度更快。
索引统计的优势是：数据准确，直接从数据库查询，不会有缓存偏差，而且查询速度比全表扫描快很多；缺点是，就算走索引，对于千万级、亿级大表来说，扫描一遍索引也需要几秒时间，不能像缓存那样毫秒级返回。
所以，我们把“缓存计数”和“索引统计”结合起来，就能取长补短，既保证速度，又保证数据一致性。具体的结合方案，分为两种，大家可以根据自己的业务场景选择。
方案一：实时缓存+定时索引校准（适合对数据一致性要求中等的业务，比如用户总数统计、订单总数统计）。
具体操作：平时查询总数时，直接从Redis缓存中获取，实现毫秒级返回；然后，每隔一段时间（比如10分钟），执行一次基于覆盖索引的COUNT查询（比如SELECT COUNT(id) FROM user），用这个查询结果，更新Redis中的缓存值，校准缓存数据，避免缓存和数据库偏差太大。
这种方案的优势是：平时查询速度极快，定时校准能保证数据的一致性，而且系统开销小，不需要频繁操作数据库；适合大多数业务场景，比如后台管理系统的统计页面、前端的用户数展示等。
方案二：缓存优先+索引兜底（适合对数据一致性要求高的业务，比如实时统计交易笔数、实时用户在线数）。
具体操作：平时查询总数时，先从Redis缓存中获取，如果缓存存在且未过期，直接返回结果；如果缓存失效，或者业务需要获取绝对准确的数据，就执行基于覆盖索引的COUNT查询，返回结果的同时，更新Redis缓存，下次查询直接用缓存。
这种方案的优势是：既能保证大部分场景下的快速查询，又能在需要准确数据时，通过索引查询得到绝对准确的结果，适合对数据一致性要求高的业务；缺点是，缓存失效时，会有一次索引查询的延迟，但这种情况很少见，而且索引查询的速度也比全表扫描快很多。
除了这两个核心方案，还有一些细节优化，能进一步提升COUNT查询的性能，大家可以一起做好，让效果更稳定。
第一个细节：避免使用COUNT(*)查询带WHERE条件的统计。如果你的需求是统计“满足某个条件的行数”，比如“查询近7天注册的用户数”，这时候用COUNT(*)结合WHERE条件，就算有索引，也可能会扫描大量数据，速度依然很慢。这种情况下，建议采用“分区表+索引”的方式——把表按照时间分区（比如按天分区），然后给查询条件中的字段（比如create_time）创建索引，这样MySQL就能只扫描指定分区的索引，大大减少扫描的数据量，提升查询速度。
第二个细节：合理设置Redis缓存的过期时间。过期时间太长，缓存和数据库的偏差会变大；过期时间太短，会频繁触发缓存失效，增加数据库压力。建议根据业务的更新频率来设置，比如用户表每小时更新1000条数据，过期时间可以设置为10-15分钟；如果更新频率很高，比如每分钟更新1000条数据，过期时间可以设置为5分钟，确保缓存数据不会偏差太大。
第三个细节：批量操作时，批量更新缓存。如果有批量插入、批量删除的操作，比如批量导入1000条用户数据，不要一条一条调用INCR命令，而是用INCRBY命令，一次性把缓存值加1000，这样能减少Redis的调用次数，提升系统性能，同时避免多次更新缓存导致的偏差。
第四个细节：监控缓存和数据库的状态。定期监控Redis的缓存命中率、缓存失效次数，以及数据库的慢查询日志，如果发现缓存命中率太低，或者频繁出现慢查询，及时调整缓存策略和索引结构；同时，做好Redis的高可用，比如部署主从架构，避免Redis宕机导致缓存失效，影响业务。
最后，跟大家分享一个实战案例，看看我们是怎么用“缓存计数+索引统计”方案，解决5000万用户表COUNT查询慢的问题的。
之前我们公司的用户表，数据量达到5000万条，执行SELECT COUNT(*) FROM user，耗时长达28秒，接口超时，后台统计页面无法正常打开，甚至影响了用户注册接口的正常运行。我们尝试过修改COUNT语句、加普通索引，都没有效果，后来采用了“实时缓存+定时索引校准”的方案，具体操作如下：
1. 给user表的id字段（主键）创建主键索引，确保COUNT(id)能走覆盖索引，执行SELECT COUNT(id) FROM user，耗时从28秒优化到3秒；
2. 初始化Redis缓存，执行SELECT COUNT(id) FROM user，得到50000000，用SET user:count 50000000 EX 600（过期时间10分钟），把结果存到Redis；
3. 在用户注册、注销、批量导入的代码中，添加缓存更新逻辑：注册时INCR user:count，注销时DECR user:count，批量导入时INCRBY user:count 批量条数；
4. 编写定时任务，每隔10分钟，执行一次SELECT COUNT(id) FROM user，用查询结果更新Redis缓存，校准数据；
5. 优化接口逻辑，查询用户总数时，先从Redis获取，缓存失效时，执行COUNT(id)查询，更新缓存后返回。
优化之后，用户总数查询接口的响应时间从28秒，降到了10毫秒以内，后台统计页面秒开，数据库的慢查询次数减少了99%，再也没有出现因为COUNT查询拖垮业务的情况，运营和市场同事的工作效率也提升了很多。
其实，MySQL大表COUNT查询慢，并不是一个无解的问题，关键是要找对思路——避开全表扫描，利用缓存快速返回结果，利用索引统计校准数据，两者结合，就能轻松解决问题。而且，这个方案不需要复杂的技术架构，不需要引入额外的中间件，只用Redis和MySQL自身的索引特性，就能落地，适合大多数中小企业和创业公司。
可能有人会问：如果我的表数据量达到亿级，这个方案还能用吗？答案是肯定的。亿级大表的话，我们可以进一步优化：比如把表分成多个分表，每个分表单独维护缓存，然后汇总缓存结果；或者采用“近似统计”的方式，比如用MySQL的EXPLAIN语句中的rows字段，获取近似的行数，适合对数据准确性要求不高的场景，查询速度能达到毫秒级。
另外，还要提醒大家一点：优化COUNT查询，不能只盯着SQL本身，还要结合业务场景——如果业务不需要绝对准确的实时数据，就可以大胆用缓存，牺牲一点点一致性，换取更高的性能；如果业务必须要绝对准确的实时数据，就用“缓存优先+索引兜底”的方案，既保证速度，又保证准确性。
总结一下，解决MySQL大表COUNT查询慢的核心方案，就是“缓存计数+索引统计”：缓存负责快速返回结果，解决业务卡顿问题；索引负责校准缓存，保证数据一致性。按照上面的方法操作，不管你的表数据量是千万级还是亿级，都能实现COUNT查询秒出结果，彻底摆脱慢查询拖垮业务的困扰。
最后再补充一个小技巧：如果你的业务中，COUNT查询的场景很多，比如既要统计用户总数，又要统计订单总数、商品总数，可以把所有的计数缓存，统一管理，比如用Redis的Hash结构，key为“count:all”，field为“user_count”“order_count”“goods_count”，这样既能方便维护，又能减少Redis的key数量，提升Redis的性能。
还有，在生产环境中，一定要做好测试，比如模拟千万级数据，测试缓存更新的延迟、索引查询的速度，确保方案能稳定运行；同时，做好监控，及时发现问题、调整策略，避免出现缓存雪崩、数据不一致等问题。
其实，MySQL的优化，从来都不是一蹴而就的，而是一个不断调整、不断优化的过程。遇到问题不要慌，先找到问题的根源，再结合业务场景，选择合适的解决方案，就能轻松解决。希望这篇文章，能帮到那些正在被MySQL大表COUNT查询慢困扰的朋友，让大家的业务跑得更流畅，少踩坑、少加班。
来源：618同城网 www.tiancebbs.cn
