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）执行时，应用端可能感知到几秒的写入失败或超时。
- 确认当前版本：
SELECT VERSION();，5.7+ 更稳妥 - 检查磁盘空间：转换过程需要额外空间存新表，建议空闲空间 ≥ 原表大小 × 1.2
- 避免在业务高峰执行；若必须在线操作，提前在从库验证耗时
mysqldump + 重建是更可控的迁移方式
导出再导入看似笨重，但对生产环境反而更安全：可控制字符集、索引顺序、AUTO_INCREMENT 值，且不依赖原表在线状态。关键是导出时要保留建表语句中的引擎信息，并手动替换。
- 导出结构（不含数据）：
mysqldump --no-data --skip-triggers db_name table_name > schema.sql - 编辑
schema.sql，把ENGINE=MyISAM全部替换成ENGINE=InnoDB - 导出数据（带禁用外键检查）：
mysqldump --no-create-info --skip-triggers db_name table_name > data.sql - 导入：
mysql -e "SET FOREIGN_KEY_CHECKS=0;" db_name
转换后必须检查外键、全文索引和 AUTO_INCREMENT 行为
MyISAM 和 InnoDB 在这些机制上差异明显，直接转换不会自动修复语义问题。
- 外键：MyISAM 忽略
FOREIGN KEY定义，InnoDB 会校验并强制约束——如果原表有脏数据（如子表存在父表不存在的外键值），ALTER TABLE会失败，报错类似ERROR 1005 (HY000): Can't create table `db`.`t` (errno: 150) - 全文索引：MyISAM 的
FULLTEXT索引无法被 InnoDB 直接复用，必须删除后重建（ALTER TABLE t DROP INDEX ft_idx; ALTER TABLE t ADD FULLTEXT(idx_col);） - 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 下根本不会发生，容易引发隐性死锁或慢查询堆积。
- 上线前用
EXPLAIN检查所有涉及该表的UPDATE/DELETE语句是否命中索引 - 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg状态变量，确认锁等待是否异常升高 - 如果应用大量使用
SELECT COUNT(*)，注意 InnoDB 不缓存总行数，该语句会变慢（尤其无 WHERE 条件时）
