alter table 是唯一安全路径——它原生支持跨引擎重建表结构与数据文件，自动处理隐式主键生成、全文索引重建、自增计数器重置、row_format兼容性等关键环节；存储过程无法安全替代，因其不支持稳定动态执行ddl且绕过事务与约束保障。
存储过程不能直接跨引擎迁移表
MySQL 存储过程本身不提供「迁移表」能力，它只能执行 SQL 语句；而表的存储引擎变更必须通过 ALTER TABLE ... ENGINE=InnoDB 或重建表实现。试图在存储过程中用 CREATE TABLE ... SELECT + DROP TABLE 模拟跨引擎迁移，会绕过事务一致性、外键约束、自增计数器重置等关键环节，极易导致数据错乱。
为什么 ALTER TABLE 是唯一安全路径
跨引擎变更（如 MyISAM → InnoDB）本质是重建表结构+重写数据文件，ALTER TABLE 是 MySQL 唯一原生支持该操作的机制。它会自动处理：
- 隐式主键生成逻辑（MyISAM 无主键时，InnoDB 会用
row_id，但后续 DML 可能误匹配） - 全文索引重建（MyISAM 的
FULLTEXT语法与 InnoDB 不兼容，需显式REPAIR TABLE或重建） - 自增计数器重置（MyISAM 的
AUTO_INCREMENT值不会被mysqldump正确还原，ALTER TABLE会从当前最大值续推） - ROW_FORMAT 和
innodb_file_per_table兼容性（MySQL 8.0+ 要求ROW_FORMAT=DYNAMIC，否则加载失败）
批量迁移必须脚本化，不能靠存储过程硬编码
若需批量变更多个表引擎，应查询 information_schema.tables 生成 ALTER TABLE 语句，而非写死在存储过程中。原因：
- 存储过程无法动态拼接并执行 DDL（
PREPARE/EXECUTE对ALTER TABLE支持不稳定，尤其在事务上下文中） - 每个表的引擎变更可能需不同前置条件（如先加主键、删全文索引、调整字符集），硬编码逻辑无法泛化
- 大表执行
ALTER TABLE会锁表或耗尽内存，需配合pt-online-schema-change或ALGORITHM=INPLACE控制
正确做法是用 shell 或 Python 脚本生成语句：
SELECT CONCAT('ALTER TABLE `', table_name, '` ENGINE=InnoDB ROW_FORMAT=DYNAMIC;')
FROM information_schema.tables
WHERE table_schema = 'your_db' AND engine = 'MyISAM';
最容易被忽略的三个落地细节
就算走通 ALTER TABLE，以下三点不做就等于白干：
- 迁移前必须确认目标表有显式主键——InnoDB 依赖主键组织数据，无主键表会隐式使用
row_id，UPDATE/DELETE 行为不可控 - 导入后立刻执行
ANALYZE TABLE t1;——否则优化器统计信息仍是旧引擎残留，查询计划严重失真 - MyISAM 表若有全文索引，必须在
ALTER TABLE后手动重建：ALTER TABLE t1 DROP INDEX ft_idx; ALTER TABLE t1 ADD FULLTEXT(content);，否则索引无效
