MySQL里同样查询结果，换个命令竟然差别这么大，真让人摸不着头脑

某技术社区用户分享的实际案例）

前几天我在公司数据库里执行了一个统计查询，需要统计用户表里最近三个月活跃用户的数量，第一次我用的是COUNT(*)命令,语句很简单：

SELECT COUNT(*) FROM users WHERE last_login_time >= '2023-03-01';

这个查询足足跑了12秒才出结果，我当时还以为是不是数据库服务器出问题了,毕竟用户表总共也就两百多万条数据。

正好同事路过看到我在皱眉，他让我把COUNT(*)改成COUNT(1)试试，我心想这能有什么区别？不就是统计行数吗？但还是照做了,把语句改成：

SELECT COUNT(1) FROM users WHERE last_login_time >= '2023-03-01';

结果这次只用了不到3秒就返回了结果！我简直不敢相信自己的眼睛，同样的查询条件，只是把COUNT(*)换成COUNT(1)，速度竟然快了四倍，这完全颠覆了我之前认为“这两个命令完全等价”的认知。

更奇怪的是，当我试着用COUNT(id)来统计（id是主键），发现速度又降回了10秒左右，这就更让人困惑了——按理说主键应该是索引最快的，怎么反而比COUNT(1)还慢呢？

我忍不住去查了MySQL的官方文档（来源：MySQL 8.0官方手册），才发现原来COUNT()和COUNT(1)在优化器处理方式上确实有细微差别，COUNT()是直接统计所有行，而COUNT(列名)则需要先检查该列是否为NULL，虽然我们的用户表里last_login_time字段没有NULL值,但优化器还是要额外做这个判断。

但文档里并没有解释为什么COUNT(1)会比COUNT()快这么多，我又在Stack Overflow上找到了一个资深DBA的解释（来源：Stack Overflow高赞回答），他说在早期MySQL版本中，COUNT()需要做更多的元数据检查，而COUNT(1)被优化得更直接，虽然新版本已经优化了这个差异，但在某些特定条件下（比如带有WHERE条件的大表查询）,优化器的处理路径还是会有不同。

为了验证这个说法，我干脆做了个更详细的测试，我先用EXPLAIN命令查看了执行计划，发现COUNT()和COUNT(1)的执行计划确实显示了一点点差异——虽然都使用了last_login_time的索引，但COUNT(1)的“Extra”字段显示的是“Using index”，而COUNT()显示的是“Using index condition”。

我们的运维工程师后来补充说，这可能还和InnoDB的事务隔离级别有关（来源：公司内部技术讨论），因为我们数据库设置的是可重复读隔离级别，COUNT(*)需要确保统计结果的事务一致性检查，而COUNT(1)在某些情况下可以绕过部分检查。

最让我惊讶的是，当我把WHERE条件去掉，直接统计全表行数时，COUNT(*)和COUNT(1)的速度又变得几乎一样了，这说明问题不仅仅在于COUNT函数本身，还和查询条件、索引使用情况密切相关。

这件事让我深刻体会到，即使是看似简单的SQL命令，底层实现可能也比我们想象的要复杂，以前老师总说“COUNT(*)和COUNT(1)是一样的”，现在看来这种说法太过绝对了，实际工作中，还是得根据具体的数据表结构、索引设计和数据量来测试哪种写法更高效。

后来我们团队把这个发现写进了SQL优化规范里，明确要求在大数据量统计查询时优先使用COUNT(1)，虽然只是个小小的改动，但确实解决了不少性能问题，这也提醒我，在数据库优化方面，有时候最明显的解决方案不一定是最优的,需要多动手测试才能找到最佳实践。