多用户使用SQL_CALC_FOUND_ROWS导致MySQL总行数统计异常

看起来你遇到了典型的高并发场景下的分页计数不一致问题——低并发（1-10用户）时一切正常，用户量上来（20+）就出现总记录数乱跳的情况，比如实际245条却返回18条。结合这类问题的常见诱因，我整理了以下排查方向和解决思路：

可能的核心原因 #

• 竞态条件引发的计数偏差：当计数查询和数据写入/删除操作同时执行时，如果没有正确的隔离机制，计数查询可能会读取到半完成的事务数据，导致结果不准。比如统计总数的过程中，刚好有数据被删除但事务还没提交，或者新数据刚插入还没被计数查询捕获。
• 事务隔离级别设置不合理：如果数据库用了过低的隔离级别（比如READ UNCOMMITTED），计数查询会读取到未提交的脏数据；就算是READ COMMITTED级别，也可能出现不可重复读，导致不同请求拿到的计数结果不一样。
• 多查询拼接计数的不一致：如果你的总记录数是通过多次查询分别统计再相加得到的（比如多表查询后各自计数再求和），高并发下各表的数据变化不同步，就会导致总和出错。
• 缓存更新机制有漏洞：如果总记录数用了缓存，但缓存更新不是原子操作，高并发时多个请求同时更新缓存，或者缓存过期后多个请求同时重新计算计数，都可能导致错误的数值被缓存下来。

分步排查与修复方案 #

• 调整事务隔离级别：给计数查询设置合适的隔离级别，比如MySQL的REPEATABLE READ（默认级别）或者READ COMMITTED，避免脏读和不可重复读。可以在执行计数查询前显式设置：

  SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
  SELECT COUNT(*) FROM your_table WHERE [查询条件];
  

• 将多查询计数改为原子查询：如果是多表统计总和，尽量用一个原子查询完成，保证各表的数据状态在同一时刻被读取。比如：

  SELECT SUM(counts) FROM (
      SELECT COUNT(*) AS counts FROM table1 WHERE [条件]
      UNION ALL
      SELECT COUNT(*) AS counts FROM table2 WHERE [条件]
  ) AS total_counts
  

  这样能避免多次查询之间数据变化带来的不一致。
• 确保读写操作的隔离性：如果系统中有频繁的写入/删除操作，要让计数查询和这些操作在事务层面做好隔离。比如写入操作完成并提交事务后，再触发计数更新；或者在计数查询时使用行级锁（如果合适）来锁定统计范围内的数据，避免统计过程中数据变更。
• 修复缓存更新逻辑：如果用了缓存存储总记录数，要保证缓存更新是原子操作。比如用分布式锁控制只有一个请求去重新计算并更新缓存，其他请求等待缓存更新完成后再读取；或者在数据变更（插入/删除/更新）时主动更新缓存，而不是依赖缓存过期时间被动更新。
• 添加日志追踪：在高并发场景下，给计数查询和数据变更操作加上详细日志，记录每次计数的时间、请求ID、当时的数据变更记录，这样可以精准定位到是哪些操作导致了计数异常。

额外提醒 #

如果你的系统是分布式分库分表架构，还要考虑多节点的数据一致性问题——总记录数的统计需要确保所有节点的数据状态一致，可能需要用到分布式事务或者最终一致性的方案来处理。

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