直接执行ALTER TABLE t ENGINE=InnoDB在大表上必然导致长时间写入中断，因其强制走COPY算法，全程MDL写锁、磁盘空间翻倍、主从延迟飙升；必须用pt-online-schema-change配合主键/唯一索引、innodb_file_per_table=ON等前提实现低影响迁移。
直接执行 ALTER TABLE t ENGINE=InnoDB 在大表上必然导致长时间写入中断，不是平滑，是停服。 MySQL 所有版本（包括 8.0.34）对 MyISAM → InnoDB 的引擎变更都不支持 ALGORITHM=INPLACE，实际走的是全表拷贝流程，锁表、耗双倍磁盘空间、主从延迟飙升是确定性结果。
为什么 ALTER TABLE ENGINE=InnoDB 在大表上会失败
这不是“慢”，而是架构级阻塞：
-
SHOW PROCESSLIST中状态长期卡在copy to tmp table，说明真正在逐行搬运数据，不是准备阶段 - 全程持有 MDL 写锁：所有
INSERT/UPDATE/DELETE被阻塞；SELECT在REPEATABLE-READ隔离级别下也可能因一致性读等待而卡住 - 磁盘空间需 ≥ 原
.MYD+.MYI总大小 × 2.2（含 redo/undo/临时排序文件），10GB 表至少预留 22GB 空闲空间 - 即使显式加
LOCK=NONE，MySQL 也会自动降级为LOCK=EXCLUSIVE—— 引擎切换本身不支持无锁
必须用 pt-online-schema-change 实现低影响迁移
这是目前唯一能在生产环境落地的方案，它不依赖 MySQL 原生 DDL，靠影子表 + 触发器双写同步，业务写入基本不受影响。但前提是表结构合规：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 目标表必须有主键或唯一非空索引：
SHOW KEYS FROM your_table WHERE Non_unique = 0 AND Seq_in_index = 1;，否则报错This table has no primary key or unique index - 确认
innodb_file_per_table = ON（MySQL 5.6+ 默认开启，但需验证：SELECT @@innodb_file_per_table;） - 执行前停掉从库复制（或确保
Seconds_Behind_Master ≤ 1），避免触发器写入被复制冲突打乱 - 典型命令：
pt-online-schema-change --alter "ENGINE=InnoDB" D=test,t=myisam_table --execute --chunk-size=500 --max-lag=1 --check-interval=5
迁移后必须立刻验证的三件事
InnoDB 和 MyISAM 行为差异真实存在，不检查就上线等于埋雷：
-
SELECT COUNT(*)明显变慢？MyISAM 缓存行数，InnoDB 必须扫描；高频使用场景需加汇总表或缓存层 - 全文索引失效？
FULLTEXT语法相同，但分词参数不同：innodb_ft_min_token_size默认是 3（MyISAM 是 4），需比对并重设 - 插入报错
ERROR 1075？InnoDB 要求AUTO_INCREMENT列必须是索引的一部分，检查是否漏建主键或未将自增列包含进索引
真正难的不是执行命令，而是判断哪张表该迁、哪张不该动——很多只读小表或带旧版 FULLTEXT 的配置表，强行转 InnoDB 只会增加重建开销和内存争抢，反而降低稳定性。
