alter table t engine=innodb不是原子操作，因其强制使用copy算法，涉及全量数据拷贝、索引重建、重命名交换等多步不可中断流程，任一环节失败将导致磁盘空间浪费且无法回滚，同时全程持有mdl写锁阻塞读写，不满足mysql 8.0原子ddl对innodb表的事务性元数据变更要求。
直接用 ALTER TABLE t ENGINE=InnoDB 对大数据量表做迁移，不是原子操作，且会锁死写入，不能用于线上业务表。
为什么 ALTER TABLE ENGINE=InnoDB 不是真正“原子”的
MySQL 的 DDL 原子性只保证语句执行成功或失败回滚，不等于“不锁表”或“不影响业务”。MyISAM → InnoDB 强制走 COPY 算法（5.7/8.0 下不支持 ALGORITHM=INPLACE），整个过程包含：创建新表结构 → 全量拷贝数据 → 重建索引 → 重命名交换 → 清理旧文件。中间任意一步失败，原表仍保留 MyISAM 引擎，但已占用双倍磁盘空间，且无法中断重试——这不是可控的原子变更，而是高风险单点操作。
- 执行中
SHOW PROCESSLIST显示状态为copy to tmp table，不是“正在准备”，是真的在全表拷贝 - 主库上该语句持有 MDL 写锁，阻塞所有
INSERT/UPDATE/DELETE；从库回放同样卡住，Seconds_Behind_Master可能跳到数小时 - 即使加了
LOCK=NONE，MySQL 也会自动降级为LOCK=SHARED（读锁）或LOCK=EXCLUSIVE（写锁），因为引擎切换本身不支持无锁
大表迁移必须绕开 ALTER TABLE 的三个硬限制
10GB+ 表用原生命令迁移，大概率触发超时、磁盘满、主从断裂。真正能落地的方案得满足：不锁原表、可中断、可监控、不放大延迟。
-
innodb_file_per_table必须为ON（5.6+ 默认开启），否则新表数据全写进ibdata1，后续无法收缩空间 - 磁盘剩余空间需 ≥ 原表
.MYD + .MYI总大小 × 2（含临时文件、redo log、undo log） - 若表含
FULLTEXT索引，InnoDB 5.6+ 虽支持，但重建耗时翻倍，且分词逻辑与 MyISAM 不同，查不到结果可能不是 SQL 写错，而是索引行为变了
替代方案选型：什么时候用 pt-online-schema-change，什么时候等 MySQL 8.0+
线上环境别赌 ALTER 能跑通。真实选型看版本和约束：
- MySQL mysqldump 全量重建（导结构→改 ENGINE→导数据），或用
pt-online-schema-change（依赖触发器，要求binlog_format=ROW且不能有TRIGGER冲突） - MySQL 5.6–5.7：
pt-online-schema-change是主力工具；注意它会在原表建AFTER INSERT/UPDATE/DELETE触发器，若业务高频更新同一行，可能引发死锁 - MySQL 8.0+：仍不支持
ENGINE切换的ALGORITHM=INPLACE，但pt-osc的兼容性和限流能力更好；可配合--chunk-size和--max-load控制对主库压力
命令示例：pt-online-schema-change --alter "ENGINE=InnoDB" D=your_db,t=big_table --execute。执行前务必先用 --dry-run 检查权限和依赖。
最容易被忽略的验证点：转换后不是“引擎变了就完事”
引擎切换后，应用行为可能静默异常，尤其当原来依赖 MyISAM 特性时：
-
AUTO_INCREMENT列必须是索引一部分（如主键或联合索引首列），否则ALTER直接报错ERROR 1075；而 MyISAM 允许裸自增列 - 表名大小写敏感性变化：MyISAM 在 Windows 上不区分
user和User，InnoDB 受lower_case_table_names影响更严格，SQL 中混用会查不到表 -
COUNT(*)性能差异极大：MyISAM 缓存行数，COUNT(*)是 O(1)；InnoDB 需扫描索引，大表可能秒级变分钟级
真正上线前，至少要验证三件事：事务是否生效（BEGIN; INSERT; ROLLBACK; 后查是否回滚）、全文检索结果是否一致、主键自增是否连续不跳号。这些没法靠 SHOW CREATE TABLE 看出来。
