迁移需先加主键、重写全文索引、校验时处理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 回放比对才抓得住。
