不能直接批量执行alter table ... engine=innodb，因会锁表、耗尽磁盘、拖垮主从；小表需满足无fulltext、有主键、空间充足、业务可停写四条件；大表必须用pt-online-schema-change，并确认有主键或唯一索引。
直接执行批量 ALTER TABLE ... ENGINE=InnoDB 在生产环境大概率引发锁表、磁盘爆满、主从延迟飙升——这不是语法问题，是操作风险问题。必须分清“能生成语句”和“能安全执行”的区别。
用 SQL 生成 ALTER 语句前先筛出真正要改的表
别无脑查 ENGINE != 'InnoDB'。系统表（如 mysql.event）、视图、临时表、或含零日期（'0000-00-00'）字段的 MyISAM 表，硬切会直接报错退出。
- 只选业务库中的基础表：
SELECT CONCAT('ALTER TABLE `', TABLE_NAME, '` ENGINE=InnoDB;') FROM information_schema.tables WHERE TABLE_SCHEMA = 'your_db' AND ENGINE = 'MyISAM' AND TABLE_TYPE = 'BASE TABLE'; - 排除已知高危表：加
AND TABLE_NAME NOT IN ('event', 'proc', 'general_log')（尤其 MySQL 8.0+ 的mysql库表） - 检查 FULLTEXT 索引：
SELECT TABLE_NAME, KEY_NAME FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'your_db' AND INDEX_TYPE = 'FULLTEXT';，有结果就得先确认 MySQL 版本 ≥ 5.6 且接受重建耗时
大表（>500MB 或 >100 万行）必须绕开原生命令
ALTER TABLE t ENGINE=InnoDB 对大表默认走 COPY 算法：建新表 → 拷数据 → 重建索引 → 删旧表。期间原表被加 MDL 写锁，所有写入阻塞；磁盘占用翻倍；主库 binlog 积压，从库 Seconds_Behind_Master 直接跳到几千秒。
- MySQL 5.6+ 也极少真正支持
ALGORITHM=INPLACE切引擎，状态显示copy to tmp table就说明正在拷贝 - 唯一靠谱的在线方案是
pt-online-schema-change，但要求表必须有主键或唯一非空索引 - 命令示例：
pt-online-schema-change --alter "ENGINE=InnoDB" D=your_db,t=big_table --execute --chunk-time=0.5 --max-lag=1 - 注意：迁移完旧
.MYD/.MYI文件不会自动删，得人工确认数据一致后再清理
小表可直接 ALTER，但得卡死四个前提条件
所谓“小表”不是凭感觉，而是满足全部以下条件才可尝试原生命令：
- 表无
FULLTEXT索引（SHOW INDEX FROM t WHERE Key_name = 'FULLTEXT';返回空） - 有显式主键或唯一非空索引（
SHOW KEYS FROM t WHERE Non_unique = 0 AND Seq_in_index = 1;） - 磁盘剩余空间 ≥ 原表
.MYD文件大小 × 2.2（含日志、临时文件开销） - 业务能容忍该表写入中断（
INSERT/UPDATE/DELETE全部阻塞，时间不可预估）
执行后立刻用 SHOW PROCESSLIST; 看状态，长期卡在 copy to tmp table 就得中止，别硬等。
宝塔面板或 phpMyAdmin 上操作容易漏掉关键校验
图形界面点几下就能改单表引擎，但批量操作时根本看不到底层错误。比如 mysql.event 表因 modified 字段默认值为 '0000-00-00 00:00:00'，在严格 SQL 模式下会直接报 ERROR 1067，而 phpMyAdmin 只显示“执行失败”，不提示具体原因。
- 务必先在命令行跑
SHOW CREATE TABLE mysql.event;查字段定义 - 若含零日期，默认值需先改成
CURRENT_TIMESTAMP类型再切引擎 - 宝塔里执行 SQL 批量语句时，每条
ALTER必须独占一行且以分号结尾，否则可能只执行第一条 - 改完别忘了验证：
SHOW TABLE STATUS LIKE 't';看Engine字段，别只信 phpMyAdmin 右上角的小图标
最常被忽略的是：innodb_file_per_table 是否开启。关着的话，所有 InnoDB 表数据都挤进共享表空间 ibdata1，后续磁盘空间再也收不回来。
