迁移需先加主键、重写全文索引、校验时处理NULL与排序、禁用外键清洗脏数据、修复零日期,并警惕AUTO_INCREMENT与锁行为语义变化。

迁移后表结构不一致导致主键/索引失效
MyISAM 允许没有主键,也支持全文索引和压缩表;InnoDB 强制要求聚簇索引(通常靠 PRIMARY KEY),且不支持 FULLTEXT 在旧版本(5.6 之前)中直接迁移。如果原表没设主键,ALTER TABLE ... ENGINE=InnoDB 会静默创建隐藏的 ROW_ID,但无法被业务逻辑引用,后续加主键可能失败或锁表很久。
- 迁移前务必检查:用
SHOW CREATE TABLE `tbl_name`确认是否有PRIMARY KEY,没有就先加一个(如自增id) - 避免直接
ALTER TABLE t ENGINE=InnoDB—— 大表会锁死写入,改用mysqldump --no-create-info --skip-triggers导出数据 + 手动建新 InnoDB 表再导入 - 全文索引要重写:InnoDB 的
MATCH() AGAINST()语法虽兼容,但分词器、停用词、最小词长(innodb_ft_min_token_size)默认值不同,需同步调整配置并重建索引
校验行数和校验和时忽略 NULL 和排序差异
单纯比 COUNT(*) 容易漏掉空行或重复行;用 MD5(CONCAT(...)) 做整行哈希又因字段顺序、NULL 处理、字符集排序规则(collation)不同导致结果不一致 —— 比如 MyISAM 默认用 utf8mb4_general_ci,而新 InnoDB 表可能继承 server 默认的 utf8mb4_0900_as_cs。
- 校验行数优先用
SELECT COUNT(*) FROM tbl,但必须在迁移前后同一事务隔离级别下执行(建议REPEATABLE READ),防止 MVCC 可见性干扰 - 逐行校验推荐用
SELECT MD5(GROUP_CONCAT(CONCAT_WS('|', IFNULL(col1,'\N'), IFNULL(col2,'\N')) ORDER BY id SEPARATOR ' ')) FROM tbl,显式处理NULL并固定排序字段 - 跳过 BLOB/TEXT 字段参与哈希(太慢且易超内存),改用
CRC32或抽样比对前 N 行 + 总行数 + 索引统计(INFORMATION_SCHEMA.STATISTICS)交叉验证
外键约束启用后插入失败但错误提示模糊
InnoDB 启用外键(FOREIGN_KEY_CHECKS=1)后,如果迁移时没清理脏数据(比如子表有 orphaned 记录指向已删父记录),批量插入会卡在第一条报错,错误信息只显示 Cannot add or update a child row: a foreign key constraint fails,不指明哪条数据、哪个约束。
- 迁移前先关外键检查:
SET FOREIGN_KEY_CHECKS=0,导入完再开,并立即运行SET FOREIGN_KEY_CHECKS=1触发校验 - 开检查后若报错,用
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME='child_tbl'找出约束名,再查SELECT CONSTRAINT_NAME, COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE定位字段 - 快速定位脏数据:对子表做
LEFT JOIN父表,WHERE 父表主键 IS NULL;别依赖SHOW ENGINE INNODB STATUS,它只保留最近一次失败详情
时间类型字段在严格模式下插入失败
MyISAM 对 DATETIME / TIMESTAMP 的非法值(如 '0000-00-00 00:00:00')容忍度高,InnoDB 在 SQL mode 含 STRICT_TRANS_TABLES 时直接拒绝插入 —— 这是 MySQL 5.7+ 默认行为,迁移后首次写入就可能崩。
- 迁移前查当前 SQL mode:
SELECT @@sql_mode,重点看是否含STRICT_TRANS_TABLES或NO_ZERO_DATE - 临时绕过:导入前执行
SET sql_mode=(SELECT REPLACE(@@sql_mode,'STRICT_TRANS_TABLES','')),但仅限一次性校验,不能长期关闭严格模式 - 根治方案:用
UPDATE tbl SET dt_col = NULL WHERE dt_col = '0000-00-00 00:00:00'清洗数据,或改用0001-01-01占位,避免业务误读“零日期”为有效时间
最麻烦的不是迁移动作本身,而是那些没报错但语义已变的地方:比如 MyISAM 的 AUTO_INCREMENT 不受事务影响,InnoDB 里回滚后值不回退;还有并发读写时的锁粒度差异,测试时用单线程看不出问题,上线后突然慢——这些得靠业务日志里的实际 SQL 回放比对才抓得住。


















