最安全的批量转换方案是使用pt-online-schema-change或MySQL 5.6+的ALGORITHM=INPLACE在线DDL；需确认版本、检查FULLTEXT索引、确保innodb_file_per_table=ON，并验证转换后的COUNT(*)、事务行为和全文检索兼容性。
怎么安全地把 MyISAM 表批量改成 InnoDB
直接 ALTER TABLE t ENGINE=InnoDB 是最常用做法，但线上库不能这么干——锁表时间长、主从延迟飙升、磁盘空间翻倍是大概率事件。真正能落地的方案得绕开全表拷贝，用 pt-online-schema-change 或 MySQL 5.6+ 的在线 DDL（ALGORITHM=INPLACE）。
实操建议：
- 先确认 MySQL 版本：5.6 及以上才支持
ALGORITHM=INPLACE对引擎转换的在线操作；低于 5.6 必须用pt-osc或停机窗口 - 检查表是否有 FULLTEXT 索引：MyISAM 支持，InnoDB 5.6+ 才支持，且转换时会重建，耗时明显增加
- 确保
innodb_file_per_table=ON，否则所有表数据会挤进ibdata1，后续无法收缩 - 执行前用
SELECT table_name, engine FROM information_schema.tables WHERE table_schema='your_db' AND engine='MyISAM';拉出待转清单，别漏掉视图依赖的底层表
为什么 ALTER TABLE ... ENGINE=InnoDB 会卡住主从同步
因为默认 DDL 是 blocking 操作：主库执行时会持有 MDL 写锁，阻塞所有对该表的读写；从库回放时同样要等锁释放，而大表转换可能持续几十分钟，中间积压的 binlog 就变成延迟源头。
常见错误现象：
- 从库
Seconds_Behind_Master突然跳到几千秒 - 主库
SHOW PROCESSLIST里看到altering table状态长期不退 - 监控发现磁盘 IO 暴涨、
innodb_log_waits上升，说明日志刷不过来
根本原因不是引擎本身，而是 MySQL 在老版本中对 DDL 的加锁粒度太粗。5.7+ 默认开启 innodb_online_alter_log_max_size 限流，但依然要配合 LOCK=NONE 显式声明才能真正免锁。
pt-online-schema-change 转换时最容易踩的坑
这个工具本质是“影子表 + 触发器”双写，不锁原表，但对业务有隐性要求。很多人跑一半失败，不是脚本问题，是环境没兜住。
关键条件和风险点：
- 目标表必须有主键或唯一非空索引，否则
pt-osc无法分块同步，会报错This table has no primary key or unique index - 触发器会拦截所有
INSERT/UPDATE/DELETE，如果业务用了LOAD DATA INFILE或批量REPLACE INTO，可能被忽略或报错 - 默认超时是 120 秒，大表迁移容易触发
--chunk-time超时，建议调成--chunk-time=0.5（单位秒）并配--max-lag=1 - 不要在从库上运行，它只应在主库执行；且执行期间禁止手动删/改原表结构，否则触发器失效导致数据不一致
转换后必须立刻验证的三件事
引擎改完不等于万事大吉。InnoDB 和 MyISAM 在事务、锁、计数、崩溃恢复上行为完全不同，很多问题上线后才暴露。
务必检查：
-
SELECT COUNT(*)结果是否突变：MyISAM 存行数缓存，InnoDB 需实时扫描，数值一样但响应时间可能差百倍；若应用依赖SELECT COUNT(*)做分页总数，得加覆盖索引或换方案 - 事务行为：MyISAM 不支持事务，之前靠
LOCK TABLES实现的“伪事务”，现在必须用BEGIN/COMMIT包裹，否则并发更新会丢数据 - 全文检索语法兼容性：MyISAM 的
MATCH ... AGAINST在 InnoDB 中要求字段有FULLTEXT索引，且ft_min_word_len默认是 4（MyISAM 是 3），搜短词可能查不到
最常被忽略的是自增主键初始化方式——MyISAM 启动时扫最大值，InnoDB 从内存或 ibdata1 里读，如果曾人工 ALTER TABLE ... AUTO_INCREMENT=xxx 过，重启后可能重复插入失败。
