今天我来聊聊一个程序员经常遇到的问题，尤其是在做接口性能优化时，常常发现 count(*) 查询居然是性能的“真凶”。
相信很多小伙伴也有过这样的经历，明明是个简单的查询，怎么会这么慢？问题究竟出在哪呢？不急，今天就带大家深入分析一下 count(*) 在 MySQL 中的性能瓶颈，讲一讲如何优化这个常见查询的性能。
一、问题分析：count(*) 性能差的真相
在处理 MySQL 性能优化的时候，尤其是接口响应很慢的时候，很多时候都能发现 count(*) 这个查询占据了大量的 CPU 和 I/O 资源。尤其是在一些涉及大数据量的查询时，count(*) 成为瓶颈的概率就更大了。那么为什么这个看似简单的操作会成为性能的“真凶”呢？
1.1 不同存储引擎下的表现
首先要明确的是，MySQL 在不同存储引擎下对于 count(*) 的处理方式是不同的。以 MyISAM 和 InnoDB 为例，情况就差别很大。
MyISAM 存储引擎：由于 MyISAM 是一个非事务性引擎，它会在表的元数据中存储行数。这意味着，执行
count(*)时，MyISAM 只需要返回已保存的行数，速度非常快。基本上查询返回的速度是非常快速的。InnoDB 存储引擎：InnoDB 支持事务和多版本并发控制（MVCC），因此它并不直接存储表的行数。当你执行
count(*)时，InnoDB 需要扫描整个表的数据行，哪怕你查询的是一个没有索引的字段，也得扫描所有数据。因为 InnoDB 必须确保在事务处理中数据的一致性，所以即使在count(*)查询中，它也不能直接从元数据中拿到数据，而是要真正执行行扫描，这样就导致了性能的显著下降。
二、count(*) 性能优化的思路
面对 count(*) 性能差的问题，作为程序员，我们需要有针对性的优化方法。下面我总结了几种常见的优化策略，希望能给大家带来帮助。
2.1 使用 Redis 缓存
对于一些简单的统计操作（比如某个页面的浏览量、用户数量等），如果数据更新不那么频繁，可以考虑使用 Redis 来做缓存。通过缓存 count(*) 的结果，避免每次都需要从数据库查询。
例如，你可以在 Redis 中存储一个类似 "page:12345:view_count" 的键值对，更新时通过发布订阅或者定时任务将 Redis 中的缓存更新。
但需要注意的是，缓存与数据库数据之间的一致性问题，虽然对于浏览量这类数据不一致是可以容忍的，但在一些场景下可能需要特殊处理，比如使用延迟队列、补偿机制等。
2.2 引入二级缓存
如果 Redis 不适合某些高频率查询，可以考虑使用二级缓存。比如可以在应用程序中引入 Caffeine 或 Guava 这类内存缓存来缓存查询结果，避免每次都从数据库中查询。
举个例子，我们可以用 Spring 的 @Cacheable 注解来缓存 count(*) 查询结果，减少数据库的负担。这里需要特别注意缓存失效时间的设置，确保缓存能够及时过期并更新，避免数据的不一致。
@Cacheable(value = "countCache", key = "#key")
public int countItems(String key) {
return jdbcTemplate.queryForObject("SELECT COUNT(*) FROM table_name WHERE key = ?", Integer.class, key);
}
2.3 使用多线程执行
对于需要进行多条件统计的场景，比如同时统计多个表的数据，单线程查询肯定会拖慢性能。这时，我们可以通过 多线程 或 异步 来提升查询性能。
例如，使用 CompletableFuture 来异步执行多个查询，这样就可以并行查询多个条件，大大提高效率。
CompletableFuture<Integer> future1 = CompletableFuture.supplyAsync(() -> countItems("condition1"));
CompletableFuture<Integer> future2 = CompletableFuture.supplyAsync(() -> countItems("condition2"));
CompletableFuture.allOf(future1, future2).join();
int result = future1.get() + future2.get();
这种方法虽然简单，但是能显著提升性能，尤其是当你的查询逻辑比较复杂时。
2.4 减少 JOIN 表
当 count(*) 查询涉及多个表时，MySQL 需要执行多个表的扫描和 JOIN 操作，这会大大降低查询性能。如果没有特别的需求，尽量避免不必要的 JOIN 表。
比如，如果查询中需要统计某个表的数据行数，但与其他表的 JOIN 并非必要，那么就应去掉不必要的连接，直接针对单个表进行 count(*) 查询。
2.5 使用 ClickHouse 或其他列式数据库
当你的查询条件非常复杂，且数据量非常大时，MySQL 可能就不再适合了。这时候，我们可以考虑使用 ClickHouse 这种列式存储数据库。ClickHouse 针对分析型查询做了优化，适合进行大量数据的统计查询。
通过使用 Canal 来同步 MySQL 的数据到 ClickHouse，可以减少 MySQL 上复杂查询的负担，提高查询效率。ClickHouse 适合批量数据处理，但需要注意它并不适合频繁的更新操作。因此，如果你的系统有频繁更新的需求，可能需要再评估一下是否适合使用 ClickHouse。
三、count(*) 的性能对比与优化
说到 count(*) 的性能，很多人可能不知道其实它有很多种写法，而这些不同的写法对于性能的影响是不同的。
count(*)：这个查询会统计表中所有的行数，性能是最优的。count(1)：实际上，count(1)和count(*)的性能几乎没有差别，都是全表扫描，唯一的区别是count(1)需要解析列 1。count(id)：由于需要对id字段进行索引扫描，所以性能稍逊一筹。count(普通索引列)：对于索引列的统计，性能取决于该索引的大小。count(未加索引列)：这种情况会进行全表扫描，性能最差。
性能排序大致是：count(*) ≈ count(1) > count(id) > count(普通索引列) > count(未加索引列)。
四、总结
面对 count(*) 性能差的问题，我们可以通过多种手段进行优化。最常见的优化方式包括使用缓存、引入二级缓存、使用异步查询、多线程优化等。如果数据量非常大且查询条件复杂，可以考虑使用列式存储数据库如 ClickHouse 来提高查询性能。
最后，虽然 count(*) 看起来是一个简单的查询，但它的背后牵涉到很多性能优化的问题。希望通过今天的分享，大家在面对性能瓶颈时能有更多的解决方案。其实，这个问题和写代码一样，都是不断尝试和积累经验，才最终找到最合适的解决方案。
所以，记住：count(*) 虽然简单，但要想优化它的性能，可得花点心思哦！
-END-
以上，就是今天的分享了，看完文章记得右下角给何老师点赞，也欢迎在评论区写下你的留言。
