MySQL如何将MyISAM表转换为InnoDB表

ALTER TABLE ... ENGINE=InnoDB会锁表，但5.6+版本仅在最后元数据切换阶段短暂加排他锁，非全程卡死；大表仍需谨慎，建议用mysqldump+重建或pt-online-schema-change无锁迁移。

ALTER TABLE ... ENGINE=InnoDB 会锁表，但不是所有场景都卡死

直接执行 ALTER TABLE t ENGINE=InnoDB 是最常见做法，但效果取决于 MySQL 版本和表大小。5.6 之前版本全程锁表（写入阻塞），5.6+ 支持在线 DDL（ALGORITHM=INPLACE），但 MyISAM 转 InnoDB 不支持真正无锁——它仍需在最后阶段短暂加排他锁（copy table 阶段结束后的一小段元数据切换时间）。大表（比如 >10GB）执行时，应用端可能感知到几秒的写入失败或超时。

1. 确认当前版本：SELECT VERSION();，5.7+ 更稳妥
2. 检查磁盘空间：转换过程需要额外空间存新表，建议空闲空间 ≥ 原表大小 × 1.2
3. 避免在业务高峰执行；若必须在线操作，提前在从库验证耗时

mysqldump + 重建是更可控的迁移方式

导出再导入看似笨重，但对生产环境反而更安全：可控制字符集、索引顺序、AUTO_INCREMENT 值，且不依赖原表在线状态。关键是导出时要保留建表语句中的引擎信息，并手动替换。

1. 导出结构（不含数据）：mysqldump --no-data --skip-triggers db_name table_name > schema.sql
2. 编辑 schema.sql，把 ENGINE=MyISAM 全部替换成 ENGINE=InnoDB
3. 导出数据（带禁用外键检查）：mysqldump --no-create-info --skip-triggers db_name table_name > data.sql
4. 导入：mysql -e "SET FOREIGN_KEY_CHECKS=0;" db_name

转换后必须检查外键、全文索引和 AUTO_INCREMENT 行为

MyISAM 和 InnoDB 在这些机制上差异明显，直接转换不会自动修复语义问题。

1. 外键：MyISAM 忽略 FOREIGN KEY 定义，InnoDB 会校验并强制约束——如果原表有脏数据（如子表存在父表不存在的外键值），ALTER TABLE 会失败，报错类似 ERROR 1005 (HY000): Can't create table `db`.`t` (errno: 150)
2. 全文索引：MyISAM 的 FULLTEXT 索引无法被 InnoDB 直接复用，必须删除后重建（ALTER TABLE t DROP INDEX ft_idx; ALTER TABLE t ADD FULLTEXT(idx_col);）
3. AUTO_INCREMENT：InnoDB 的自增值不持久化到磁盘（重启可能重置），而 MyISAM 是持久的；若依赖该值连续性，需在转换后手动 SELECT MAX(id) FROM t 并 ALTER TABLE t AUTO_INCREMENT = N

不要忽略事务隔离与锁行为变化带来的应用影响

表引擎变了，SQL 执行表现就变了。最典型的是：MyISAM 只支持表级锁，InnoDB 默认行级锁，但如果你的应用里写了 SELECT ... LOCK IN SHARE MODE 或 UPDATE ... WHERE 条件没走索引，实际会升级成锁全表——这在 MyISAM 下根本不会发生，容易引发隐性死锁或慢查询堆积。

1. 上线前用 EXPLAIN 检查所有涉及该表的 UPDATE/DELETE 语句是否命中索引
2. 监控 Innodb_row_lock_waits 和 Innodb_row_lock_time_avg 状态变量，确认锁等待是否异常升高
3. 如果应用大量使用 SELECT COUNT(*)，注意 InnoDB 不缓存总行数，该语句会变慢（尤其无 WHERE 条件时）

转换本身不难，难的是转换后那些“看起来没报错，但行为已不同”的细节。尤其是外键约束生效、锁粒度变化、以及全文索引重建这三处，最容易在线上静默出问题。