亿级帖子搜索分页优化：限制结果为1000+且保留分页实现方案

核心思路是弃用天生会扫描全量匹配结果的SQL_CALC_FOUND_ROWS语法，通过阈值截断逻辑，让数据库最多检索到1000条匹配结果就终止查询，同时保留完整的前100页分页能力。

具体实现步骤 #

1. 改造总数查询逻辑，增加结果截断 #

不再统计全量匹配结果总数，单独写总数查询语句，固定加LIMIT 1001的限制，让数据库找到1001条匹配结果后立刻停止扫描，不用遍历剩余数据：

SELECT xxx_posts.ID
FROM xxx_posts
WHERE 1=1
AND xxx_posts.post_title LIKE '%a%'
LIMIT 1001

拿到查询结果后按行数判断总数展示逻辑：

• 如果结果行数 ≤ 1000：真实匹配总数就是当前行数，分页逻辑按原有规则正常计算总页数
• 如果结果行数 = 1001：直接判定总结果为「1000+」，分页导航最多只生成到第100页（按每页10条计算，100页刚好覆盖1000条结果）

2. 改造分页数据查询逻辑 #

去掉原查询里的SQL_CALC_FOUND_ROWS，正常按分页参数查询当前页的列表数据即可：

SELECT xxx_posts.ID
FROM xxx_posts
WHERE 1=1
AND xxx_posts.post_title LIKE '%a%'
LIMIT <页偏移量>, 10

增加服务端页码校验逻辑：当总结果被判定为1000+时，如果用户传入的页码超过100，直接把偏移量锁死为990（对应第100页的起始位置），返回第100页内容，避免非法传入超大offset触发慢查询。

3. 前端展示适配 #

根据后端返回的总数标记调整展示内容：

• 若返回的是真实总数（≤1000）：正常展示「显示X-Y条，共Z条结果」，分页导航按真实总页数生成
• 若返回的是1000+截断标记：展示「显示X-Y条，共1000+条结果」，分页导航最多渲染到第100页，不展示后续页码

注意事项 #

• 不要用COUNT(*)做全量总数统计，无LIMIT截断的COUNT(*)在匹配结果上亿时一样会触发全表扫描，性能问题和SQL_CALC_FOUND_ROWS没有区别
• SQL_CALC_FOUND_ROWS本身在MySQL 8.0.17及之后版本已经被官方标记为弃用，本身执行效率就低于两次独立查询的方案，废弃没有兼容风险
• 如果后续需要调整最大展示量级，比如改成展示「5000+」，只需要把总数查询的LIMIT值改为5001，同时把最大允许页码调整为阈值/每页条数即可，核心逻辑不用改动
• 如果搜索量级持续增长，可以配合全文索引替代LIKE '%关键词%'的模糊匹配，进一步提升查询性能，和截断逻辑不冲突

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