compatibility-assessment 工具是必须前置执行的检查环节，它通过扫描慢日志、通用日志及 MyBatis mapper.xml，识别 MySQL 非标语法（如 GROUP_CONCAT、隐式类型转换等）在 openGauss B 模式下的兼容性风险，输出分级 HTML 报告并定位行号，避免上线后出现慢查询异常、分页错乱等隐性问题。
compatibility-assessment 工具不是可选步骤，而是必须前置执行的检查环节。跳过它直接迁移，90%以上的项目会在上线后暴露出隐性 SQL 兼容问题——比如慢查询突然变卡、分页结果错乱、日期计算偏移，这些都不是数据丢失，但更难定位。
为什么必须先跑 compatibility-assessment 而不是直接导出导入
MySQL 5.7 应用里大量使用非标语法：GROUP_CONCAT()、STR_TO_DATE()、IFNULL()、隐式类型转换（如字符串和数字比较）、ORDER BY 中带别名或位置序号……这些在 openGauss 的 B 兼容模式下默认不支持，或行为不一致。compatibility-assessment 能从真实 SQL 流中识别出每一处风险点，而不是靠人工翻代码猜。
- 它能扫描慢日志（
mysql.slow_log）、通用日志（mysql.general_log）、MyBatismapper.xml文件，覆盖运行时真实调用路径 - 评估结果分级明确：
完全兼容/语法兼容（需改写）/不兼容（必须替换）/不支持评估（需人工确认） - 输出 HTML 报告带行号定位，直接关联到源文件或日志偏移，省去“哪条 SQL 崩了”的排查时间
compatibility-assessment 启动前的三个硬性准备
工具本身不连数据库干活，但它依赖目标库加载插件并创建评估库。漏掉任一环都会报 extension "assessment" does not exist 或连接失败。
- openGauss 实例必须已安装
dolphin插件（社区二进制包默认包含，但手动编译部署可能缺失） - 需提前建好专用评估库：
createdatabase assessment_db dbcompatibility 'B';，然后\c assessment_db执行create extension assessment; - 若从 MySQL 日志采集 SQL，必须提前开启对应日志：
SET GLOBAL slow_query_log = ON;+SET GLOBAL long_query_time = 1;（慢日志），或SET GLOBAL general_log = ON;（通用日志）——注意通用日志会影响性能，仅限评估期临时开启
从 MyBatis mapper 文件提取 SQL 时的两个关键替换规则
工具对 #{} 和 ${} 的处理不是简单字符串替换，而是按规则映射，否则会误判参数类型导致评估失真。
-
#{id}→ 替换为$1（占位符统一编号，从 1 开始递增） -
${tableName}→ 直接替换为tableName（不加引号，保留原样） - 动态 SQL 标签（如
评估报告里最常被忽略的三类“伪兼容”项
报告中标记为 语法兼容 的 SQL，往往藏着 runtime 行为差异，上线后才暴露：
-
DATE_FORMAT(NOW(), '%Y-%m-%d')→ openGauss 对应TO_CHAR(CURRENT_DATE, 'YYYY-MM-DD')，但NOW()默认带时区，CURRENT_DATE不带，跨时区部署时结果可能差一天 -
SELECT * FROM t ORDER BY 2（用列位置排序）→ openGauss 允许语法，但执行计划不稳定，尤其配合LIMIT时可能返回非预期顺序 -
WHERE status = '1' AND amount > 0→ 字符串'1'和整数0混用，在 MySQL 中自动转成数字比较；openGauss 严格报错operator does not exist: character varying = integer，除非显式加::int
真正耗时的从来不是执行迁移命令，而是搞清哪些 SQL 在新环境里“看起来能跑，其实跑得不对”。compatibility-assessment 报告里的每一行 语法兼容，都该当作待验证的 bug 清单来处理，而不是迁完再测。
