为何我的MySQL中sql_calc_found_rows比count(*)更快？

你的这个情况其实非常典型，核心原因在于没有索引加上你的查询是多表关联+复杂过滤的场景，和资料里描述的单表带索引的常规情况完全不一样——咱们一步步拆解：

1. 为什么你的场景里sql_calc_found_rows几乎没额外开销？ #

当你在带LIMIT/OFFSET的查询里加上sql_calc_found_rows时，MySQL的执行逻辑是：在遍历符合条件的行（为了返回你要的前N条数据）的同时，顺带统计所有符合条件的总行数。因为你的查询本身就要做大量的表关联、行匹配操作，这个统计动作相当于“搭便车”，额外的计算成本被原查询的开销摊薄了，所以你感觉不到明显变慢。

2. 为什么单独的count(*)反而慢一倍？ #

当你执行不带LIMIT的count(*)时，MySQL需要重新执行整个多表关联查询，并且要遍历所有符合WHERE条件的行来计数。由于你没有任何索引，MySQL无法通过索引快速统计行数，只能实打实的把所有表关联后的中间结果集都生成出来，再逐行计数。多左连接本身就容易产生较大的中间结果，这个过程的耗时自然会比带LIMIT的查询（只需要处理前N行）加上顺带统计的成本高很多，所以出现了执行时间翻倍的情况。

3. 资料里说count(*)更快的场景是什么？ #

那些结论大多针对单表、存在合适索引的情况：比如单表上的count(*)如果有覆盖索引，MySQL可以直接从索引中读取行数，完全不需要扫描表数据；而sql_calc_found_rows还要同时处理返回结果的逻辑，这时候count(*)肯定更快。但你的场景没有索引，还是多表关联，这个优化逻辑根本不适用。

4. 长远解决方案（毕竟sql_calc_found_rows要被弃用） #

虽然现在它用着顺手，但官方已经标记弃用，还是得提前准备替代方案：

• 建立合适的覆盖索引：针对WHERE子句里的过滤字段、表关联的连接字段创建联合索引，让count(*)可以通过索引快速统计，避免全表扫描和全量关联。
• 优化查询逻辑：检查是否有不必要的左连接，或者能不能把部分过滤条件提前到子查询里，减少关联时的中间结果集大小。
• 考虑计数缓存：如果业务对总条数的实时性要求不是极高，可以把计数结果缓存到Redis之类的存储中，定时更新或者在数据变更时更新，避免每次都执行耗时的count(*)。

内容的提问来源于stack exchange，提问作者arslancharyev31