MySQL导出SQL文件在OpenGauss中导入报错，因二者在语法、数据类型、函数及默认行为上不兼容；需替换AUTO_INCREMENT为SERIAL或IDENTITY、TINYINT等映射为SMALLINT/TEXT、NOW(0)改CURRENT_TIMESTAMP，并用--compatible=postgresql导出或CSV中转防乱码与截断。
MySQL导出SQL文件时，为什么OpenGauss导入会报错？
因为mysql和opengauss的sql语法、数据类型、函数、默认行为都不兼容，直接用mysqldump生成的.sql文件几乎必然失败。
常见错误现象包括：ERROR: syntax error at or near "AUTO_INCREMENT"、ERROR: type "tinyint" does not exist、ERROR: function now(0) does not exist。
- MySQL的
AUTO_INCREMENT在OpenGauss中要改成SERIAL或GENERATED ALWAYS AS IDENTITY - MySQL的
TINYINT/MEDIUMINT/ENUM在OpenGauss里没有对应类型，得映射为SMALLINT、INTEGER、TEXT或ENUM（需手动建） -
NOW(0)、CONCAT_WS、IFNULL等函数需重写为OpenGauss支持的CURRENT_TIMESTAMP、CONCAT、COALESCE - 导出时务必加
--compatible=postgresql（虽不完美，但能规避部分语法冲突）
用csv做中间格式，字段乱码或截断怎么防？
CSV看似简单，但MySQL和OpenGauss对字符集、空值、引号、换行符的处理逻辑不同，一不留神就丢数据。
- 导出前确认MySQL客户端编码：执行
SET NAMES utf8mb4，再用SELECT ... INTO OUTFILE或mysql -e "SELECT ..." > data.csv，并加--default-character-set=utf8mb4 - OpenGauss导入时必须显式指定
ENCODING 'UTF8'，且不能省略QUOTE E'\x01'或ESCAPE '\'来处理含双引号/换行的文本字段 - 遇到
invalid byte sequence for encoding "UTF8"，八成是源库存了gbk或latin1编码脏数据，得先用iconv转码 - 数值型字段如果含千分位逗号（如
"1,234.56"），OpenGauss的COPY会直接报错，必须提前清洗
增量同步选canal还是DataMover？
纯靠一次性导出导入只能冷迁移；要热迁移，就得捕获MySQL binlog并实时转发——但两边日志机制完全不同，工具链必须“翻译”语义。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
canal只输出MySQL变更事件，不理解OpenGauss DDL，需自己写适配器把INSERT转成INSERT INTO ... ON CONFLICT DO UPDATE，外键/序列/分区表容易漏处理 -
DataMover（腾讯云）或OGG这类商业/托管服务内置了MySQL→OpenGauss映射规则，能自动转换类型、跳过不支持的DDL、重试失败事务，但配置项多、调试日志晦涩 - 关键陷阱：MySQL的
READ-COMMITTED隔离级别下，binlog可能不记录某些更新顺序，导致OpenGauss端最终状态与源库不一致，必须校验关键业务表的COUNT(*)和MD5(GROUP_CONCAT(...))
迁移后索引失效、查询变慢怎么办？
OpenGauss优化器和执行计划生成逻辑与MySQL差异极大，照搬原库索引设计大概率拖慢性能，甚至引发锁表。
- MySQL的
KEY(col1, col2)在OpenGauss中未必高效，尤其当col2选择性远高于col1时，应考虑CREATE INDEX ON t(col2, col1) - OpenGauss对
LIKE '%xxx'不走索引，而MySQL在某些版本可以，模糊查询需改用pg_trgm扩展+GIN索引 - MySQL习惯用
SELECT * FROM t ORDER BY id LIMIT 10 OFFSET 10000，OpenGauss分页深时性能骤降，得改用游标或WHERE id > last_id LIMIT 10 - 别忽略统计信息：迁移完必须立刻执行
ANALYZE VERBOSE，否则执行计划全是错的
异构迁移不是复制粘贴，而是重新理解数据在另一套引擎里的“呼吸方式”。最常被跳过的一步，是迁移后拿真实业务SQL跑一遍执行计划对比——不是看快慢，是看它有没有走你认为该走的索引。
