MySQL 分页总数怎样从 FOUND_ROWS 迁移到独立 COUNT

如果一个分页接口仍然依赖 SQL_CALC_FOUND_ROWS 和 FOUND_ROWS()，迁移方向很明确：保留一条带 LIMIT 的列表查询，再用同一组筛选条件执行一条不带 LIMIT 的 COUNT(*)。MySQL 8.4 文档已经把这两个旧能力标记为 deprecated，并明确建议使用这个替代方案。

迁移的重点不是把函数名机械替换掉，而是把“取当前页”和“算匹配总数”拆成两个有边界的职责。这样做以后，筛选条件、排序、事务快照、索引和接口返回值都需要重新说清楚。

分页 SQL 负责 rows，独立 COUNT(*) 负责 total；两条语句共享 WHERE，但 COUNT 不应继承 LIMIT，也不必继承只服务于展示顺序的 ORDER BY。

先看清 FOUND_ROWS 隐含了什么

传统写法把两个动作绑在一次会话上下文里：第一条查询加上 SQL_CALC_FOUND_ROWS，第二条立即调用 FOUND_ROWS()。第二条拿到的是“第一条查询不受 LIMIT 影响时本来会返回多少行”。这个结果是瞬时的，后续语句一旦改变了上下文，调用时机就会变得敏感。

-- 旧写法：第一条语句负责取页数据，同时让服务器计算完整结果集
SELECT SQL_CALC_FOUND_ROWS id, title, created_at
FROM articles
WHERE status = 'published' AND category_id = 12
ORDER BY created_at DESC
LIMIT 20 OFFSET 40;

-- 旧写法：依赖紧邻的上一条 SELECT 读取总数
SELECT FOUND_ROWS();

它看起来只少了一次显式的 COUNT 查询，但代价是查询优化空间和状态边界都被隐藏了。官方文档还说明，SQL_CALC_FOUND_ROWS 会让某些优化失效；因此迁移的目标应当是恢复两条 SQL 各自可解释、可调优的形态。

从一条语句拆成两个结果契约

把分页接口先写成两个结果：rows 是本页数据，total 是满足筛选条件的记录数。分页查询需要排序和窗口，计数查询只需要影响“是否匹配”的条件。两个查询应当共享参数绑定，不要通过字符串拼接重新组装条件。

-- 分页查询：只取当前窗口，排序只服务于页内稳定展示
SELECT id, title, created_at
FROM articles
WHERE status = 'published' AND category_id = 12
ORDER BY created_at DESC, id DESC
LIMIT 20 OFFSET 40;

-- 总数查询：复用筛选条件，但去掉 LIMIT；COUNT(*) 返回匹配行数
SELECT COUNT(*) AS total
FROM articles
WHERE status = 'published' AND category_id = 12;

这里的 ORDER BY 没有放进 COUNT 查询，因为它不改变匹配行数。分页查询额外使用 id 作为同值时间的次级排序，让翻页边界更稳定；这属于列表结果的契约，不是总数计算的条件。

复用 WHERE，但不要把 LIMIT 一起复制

迁移中最常见的错误是从分页 SQL 复制出 COUNT SQL 后，只把字段改成 COUNT(*)，却忘记删除 LIMIT。另一类错误是为了复用代码，把排序和关联表全部原样带入计数查询，导致总数查询承担了不必要的工作。

可以把动态筛选拆成“过滤参数”和“展示参数”。例如关键词、状态、分类、时间范围属于过滤参数；页码、每页数量和排序方向属于展示参数。构造查询时，过滤参数同时进入两条 SQL，展示参数只进入分页 SQL。

-- 过滤条件可以由同一个参数对象绑定到两条语句
-- 关键词为空时由应用层省略该条件，避免把空字符串当成真实搜索词
SELECT id, title, created_at
FROM articles
WHERE status = :status
  AND (:category_id IS NULL OR category_id = :category_id)
  AND (:keyword IS NULL OR title LIKE CONCAT('%', :keyword, '%'))
ORDER BY created_at DESC, id DESC
LIMIT :page_size OFFSET :offset;

-- COUNT 只保留会改变匹配集合的条件，不复制排序和窗口
SELECT COUNT(*) AS total
FROM articles
WHERE status = :status
  AND (:category_id IS NULL OR category_id = :category_id)
  AND (:keyword IS NULL OR title LIKE CONCAT('%', :keyword, '%'));

示例中的可选条件只是表达迁移边界。实际项目若使用预编译语句，应遵循所用驱动对 LIMIT 参数和命名占位符的支持方式；不要为了让示例看起来统一而绕过驱动的参数规则。

动态数据下，先决定一致性边界

两条独立查询之间可能发生插入、删除或状态更新，所以“本页 rows”和“total”不一定来自完全相同的瞬间。多数后台列表可以接受轻微的总数漂移；如果页面必须让两者对应同一数据视图，就要把两条语句放在合适的事务边界内，并根据存储引擎和事务隔离级别确认读视图行为。

这不是简单地把“两个查询”改成“一次事务”就万事大吉。事务会带来连接占用和更长的读视图生命周期；在高并发列表中，如果产品只需要一个大致页数，完全可以先取 rows，再异步或按需取 total。关键是把产品要求写成明确契约：

让 COUNT 走自己的索引路径

独立 COUNT 不代表天然更快。它仍然要执行相同筛选条件；如果条件没有合适索引，数据库依旧可能扫描大量记录。先用实际查询计划观察过滤列和组合索引，再决定是否需要覆盖计数查询的索引。不要为了一个分页接口盲目建立很多重复索引。

同时要留意语义变化：COUNT(*) 统计的是匹配行，COUNT(column) 会忽略该列为 NULL 的行；如果分页列表基于多表连接，还要确认是否需要 COUNT(DISTINCT articles.id)，否则一对多连接可能把总数放大。

-- 一对多 JOIN 可能重复主表行，计数时按列表实体去重
SELECT COUNT(DISTINCT a.id) AS total
FROM articles AS a
JOIN article_tags AS t ON t.article_id = a.id
WHERE a.status = 'published'
  AND t.tag_id = :tag_id;

-- 列表查询仍按文章实体返回，避免分页窗口被标签行占满
SELECT DISTINCT a.id, a.title, a.created_at
FROM articles AS a
JOIN article_tags AS t ON t.article_id = a.id
WHERE a.status = 'published'
  AND t.tag_id = :tag_id
ORDER BY a.created_at DESC, a.id DESC
LIMIT :page_size OFFSET :offset;

迁移时保留一个可检查的接口契约

应用层不要再把“紧邻上一条 SQL”当成总数来源。建议让仓储层一次返回明确的 rows 和 total，并在日志中分别记录两条查询的耗时、命中条件摘要与分页参数；敏感的关键词内容不应原样写入日志。

迁移完成后可以按下面的清单收尾：

• 全文搜索并删除 SQL_CALC_FOUND_ROWS 与 FOUND_ROWS() 的调用链。
• 确认 COUNT 复用了所有过滤条件，没有复制 LIMIT。
• 检查 JOIN 后是否需要 DISTINCT，并用边界数据比较总数。
• 决定 rows 与 total 是否需要同一事务快照。
• 分别查看分页查询和 COUNT 查询的执行计划，避免只优化其中一条。
• 为最后一页、空结果、同一时间戳和数据并发变化补上接口测试。

常见疑问

FOUND_ROWS() 还能不能继续用？

在当前文档中它仍被描述，但已经与 SQL_CALC_FOUND_ROWS 一起标记为 deprecated，并提示未来版本可能移除。新代码应直接使用独立 COUNT(*)，存量代码按接口逐步迁移。

COUNT 查询必须和分页查询放在同一个事务里吗？

不一定。取决于页面是否要求 total 与 rows 来自同一数据视图。普通列表通常可以接受轻微漂移；强一致要求的场景才需要结合事务隔离级别设计。

为什么 COUNT 查询还会慢？

因为它仍然需要判断哪些行满足 WHERE。筛选列缺少合适索引、条件选择性低、JOIN 产生重复行，都可能让 COUNT 变重，应分别看执行计划和数据分布。

参考资料：https://dev.mysql.com/doc/refman/8.4/en/information-functions.html、https://dev.mysql.com/doc/refman/8.4/en/counting-rows.html