MyISAM转InnoDB前必须停写，否则易致数据不一致或锁表失败；大表ALTER TABLE会重建并阻塞写入，需在业务低峰期操作，备份时MyISAM用--lock-tables、InnoDB用--single-transaction，全文索引、字符集、时区、自增ID等行为差异须逐一验证。
MyISAM 转 InnoDB 前必须停写
不暂停写入就直接改表引擎，大概率触发数据不一致或锁表失败。MyISAM 的 ALTER TABLE ... ENGINE=InnoDB 在大表上会重建整张表，期间写操作会被阻塞，而如果应用还在持续插入/更新，可能卡住事务、拖垮连接池。
- 确认业务低峰期操作，用
SHOW PROCESSLIST检查无活跃写入 - 临时关闭应用写逻辑，或通过代理层（如 ProxySQL）切走写流量
- 别信“小表没事”——哪怕只有 10 万行，若字段含
MEDIUMTEXT或索引多，重建时间也可能超预期
mysqldump 备份时要加 --single-transaction 和 --skip-lock-tables
默认 mysqldump 对 MyISAM 表会执行 FLUSH TABLES WITH READ LOCK，导致整个实例只读，影响线上服务；而对 InnoDB 表，--single-transaction 才能保证一致性快照，但这个参数对 MyISAM 无效。
- 混合引擎库必须分开处理：MyISAM 表用
--lock-tables（谨慎！），InnoDB 表用--single-transaction - 更稳妥的做法是分表 dump：
mysqldump --single-transaction db_name table1 table2 > backup.sql，避开 MyISAM 表 - 备份前务必检查
max_allowed_packet，否则大 BLOB 字段可能截断，恢复后发现数据变空
转换后索引和全文检索行为完全不同
MyISAM 支持全文索引（FULLTEXT），但 InnoDB 的全文索引从 5.6 才开始支持，且分词逻辑、停用词表、最小词长（innodb_ft_min_token_size）都不同，直接迁移会导致 MATCH() AGAINST() 查询结果异常甚至报错。
- 先查原表是否建了
FULLTEXT：SHOW CREATE TABLE t1，若有，需在 InnoDB 表中重建，并调优配置项 - InnoDB 全文索引不支持中文分词，若业务依赖中文搜索，得提前接入外部方案（如 Elasticsearch）或改用 ngram 解析器
-
KEY和INDEX定义语法虽兼容，但 InnoDB 的聚簇索引特性会让主键以外的二级索引体积变大，尤其联合索引包含大字段时，注意磁盘空间预估
恢复验证不能只看 SELECT COUNT(*)
数行数一致不等于数据正确——MyISAM 的 COUNT(*) 是元数据缓存，InnoDB 需实际扫描，两者值可能因未提交事务、崩溃恢复残留而暂时不等；更危险的是字符集隐式转换、时间戳时区、自增 ID 断层等问题。
- 对比关键字段的
CRC32(CONCAT(...))哈希值，比对前 1000 行和最后 1000 行 - 检查
SHOW TABLE STATUS中的Auto_increment是否跳变，避免后续插入冲突 - 特别留意
TIMESTAMP字段：MyISAM 默认用系统时区，InnoDB 受time_zone变量影响，迁移后可能集体偏移 8 小时
真正麻烦的不是转换动作本身，而是那些没显式声明字符集、没设时区、靠 MyISAM 行计数“蒙混过关”的老表——它们不会报错，但会在某个凌晨三点的订单对账里突然露馅。
