MYSQL SQL_CALC_FOUND_ROWS / FOUND_ROWS 分页计数 迁移 OceanBase 4.3.5 MySQL 模式 怎么改

迁衡基于规则 my.func.found_rows 分析 MYSQL SQL_CALC_FOUND_ROWS / FOUND_ROWS 分页计数 到 OceanBase 4.3.5 MySQL 模式 的兼容性、改写路径与验证建议。

兼容性判定

公开资料依据 · 建议 PoC 复核
支持度partial
严重度major
置信度medium
依据规则my.func.found_rows

怎么改

先按同一连接的前一条 SELECT 分支:带 SQL_CALC_FOUND_ROWS 时,只移除全局 LIMIT 并保留完整原查询关系,再用外层 COUNT(*) 计数;DISTINCT/GROUP BY/HAVING/UNION 必须保留在被计数的完整原关系结果内,不能退化为“同 WHERE 的 COUNT(*)”,且 UNION DISTINCT 的源值可能近似,需显式批准保留或收紧。无 SQL_CALC_FOUND_ROWS 时,FOUND_ROWS() 是前一条 SELECT 的实际返回行数(含 LIMIT 上限),应由驱动/分页层记录返回行数,禁止替换成无限制总数。COUNT(*) OVER() 仅用于已证明等价且非空页的简单关系,空页回退独立 COUNT

判定说明

公开资料未明确支持;MySQL 8.0 自身已废弃,建议直接改 COUNT 方案,待真库验证

库侧 / 应用侧路径

库侧改造

不可行:MySQL 8.0 已废弃该特性,库侧无等价承接

应用侧改造

可行:分页组件关联前一条 SELECT;按有无 SQL_CALC 分别读取实际返回行数或对移除全局 LIMIT 后的完整结果关系计数

推荐路线:app_side。验证建议:在同一连接与隔离级别下覆盖无 SQL_CALC、空页、尾页、offset、DISTINCT、GROUP BY/HAVING、UNION ALL/UNION DISTINCT 和并发写入;逐例比对源 FOUND_ROWS()、实际返回行数及改写计数,并对两查与窗口方案分别做计划和耗时对比

规则样例

SELECT SQL_CALC_FOUND_ROWS * FROM t LIMIT 20
SELECT FOUND_ROWS()
SELECT COUNT(*) FROM t

参考来源

相关改造点

社群/联系

迁移卡住时,带着案例找人复核

迁移路上遇到具体问题?微信群、1v1 咨询与邮箱,随时找得到人。

微信交流群 微信二维码

扫码添加微信,邀您加入交流群;亦可搜索微信号 prejudice_me。

邮箱咨询

m01dm01db01@foxmail.com

发源库、目标库、代码规模和已脱敏案例短链,便于估算改造工作量。