ALTER TABLE table_name ENGINE = InnoDB 实际重建表：新建InnoDB空表、逐行复制、重建索引、原子替换；期间加读锁，阻塞写操作，耗I/O与临时空间，失败则回滚不丢数据，但需备份并验证兼容性。
ALTER TABLE table_name ENGINE = InnoDB 是最常用的方法，但“不丢失数据”不等于“零风险”——它确实保留所有行、索引和约束，但会锁表、耗资源、可能失败。真正安全的前提是：你已备份，且清楚新引擎对现有结构的兼容性限制。
ALTER TABLE 语句改引擎时到底发生了什么
MySQL 实际上会新建一个空表（用目标引擎），逐行复制数据，重建索引，最后原子替换原表。这个过程不是“就地修改”，而是重建。
- 全程对原表加读锁（
SELECT可继续，但INSERT/UPDATE/DELETE会被阻塞） - 复制期间占用大量磁盘 I/O 和临时空间，大表可能触发
tmp_table_size或innodb_log_file_size不足而中断 - 如果中途失败（如磁盘满、连接断开），原表不受影响，但操作回滚，没改成功——不是丢数据，是没改成
-
ENGINE=InnoDB会自动启用事务支持，但不会帮你补外键；如果原表有FULLTEXT索引（MyISAM 特有），改完就失效，必须手动重建
为什么 SHOW CREATE TABLE 比 SHOW TABLE STATUS 更可靠
SHOW TABLE STATUS LIKE 'table_name' 只返回 Engine 字段，但可能滞后或不准（尤其在复制延迟高、或使用了 information_schema 缓存的场景）。真正验证是否生效，必须看建表语句：
SHOW CREATE TABLE table_name;
检查输出中 ENGINE= 后面的值，并确认 CREATE TABLE 语句里没有残留的 MyISAM 特有语法（比如 DELAY_KEY_WRITE=1），这些字段在 InnoDB 下会被忽略，但说明结构未完全适配。
- 若看到
ENGINE=InnoDB且无警告，基本算成功 - 若执行后仍显示
ENGINE=MyISAM，大概率是语句没执行成功（权限不足、表名拼错、或被 SQL mode 拦截） - 注意：某些 MySQL 版本（如 5.7 之前）对大小写敏感，
ENGINE=innodb小写可能被静默转成默认引擎
大表改引擎时容易被忽略的三个硬限制
当表超过 1GB 或百万级行数，ALTER TABLE ... ENGINE 很可能卡住或失败，不是因为语法错，而是底层资源瓶颈：
-
innodb_buffer_pool_size过小：复制过程频繁刷脏页，导致性能雪崩；建议至少设为物理内存的 50%–75% -
max_allowed_packet不够：如果某一行超长（比如含巨大TEXT字段），复制时会报错Packets larger than max_allowed_packet are not allowed - 磁盘剩余空间
此时别硬扛，改用 CREATE ... LIKE + INSERT INTO ... SELECT 分批导入更可控。
改完引擎后必须立刻检查的兼容性问题
InnoDB 和 MyISAM 在行为层面差异远大于语法，改完引擎不等于万事大吉：
- 全文索引：MyISAM 的
FULLTEXT在 InnoDB 中需要 MySQL 5.6+ 且表必须是ROW_FORMAT=DYNAMIC，否则创建失败 - 自增主键：InnoDB 的
AUTO_INCREMENT值在重启后可能跳变（因只记 checkpoint），而 MyISAM 是持久化到磁盘的；如果业务依赖连续 ID，得额外处理 - 锁粒度变化：MyISAM 是表锁，InnoDB 是行锁——看似更好，但如果原来靠表锁做简单并发控制（比如手动“锁表写日志”），现在可能出竞态
-
count(*)性能反转：MyISAM 快速返回行数（元数据缓存），InnoDB 需实际扫描，大表SELECT COUNT(*) FROM t可能从毫秒级变成秒级
这些不是 bug，是引擎本质差异。不测不上线，尤其不能只在测试库跑一遍 SELECT 就认为 OK。
