是，alter table转换引擎会锁表。旧版本全程全表锁阻塞dml；5.6+虽优化为“拷贝-替换”，但仍需最后短暂加锁切换元数据，大表操作易卡住业务写入。
ALTER TABLE转换引擎时会锁表吗？
会，而且是全表锁。MySQL在执行ALTER TABLE ... ENGINE=InnoDB时，旧版本（5.6之前）全程独占写入，期间所有DML（INSERT/UPDATE/DELETE）都会被阻塞；5.6+支持Online DDL的部分操作，但ENGINE变更仍需重建表，本质仍是“拷贝-替换”流程，只在最后短暂加锁切换元数据。
这意味着：大表转换可能持续数分钟甚至小时，业务写入会卡住。别指望它“悄悄完成”。
- 确认表大小：
SELECT table_name, round(((data_length + index_length)/1024/1024),2) AS size_mb FROM information_schema.tables WHERE table_schema='your_db' AND table_name='your_table'; - 避开高峰时段操作，提前通知上下游依赖服务
- 生产环境强烈建议在从库上先试跑，观察耗时和复制延迟
为什么不能直接用ALTER TABLE ENGINE=InnoDB？
能，语法本身没问题，但实际失败常因隐含约束。MyISAM和InnoDB对SQL模式、索引、字段类型容忍度不同，转换时MySQL会做校验，不通过就中断并报错。
典型报错包括：ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes（InnoDB默认页大小下，UTF8MB4字段索引超长）、ERROR 1067 (42000): Invalid default value for 'xxx'（严格模式下datetime默认值为'0000-00-00'被拒绝）。
- 先运行
SHOW CREATE TABLE your_table;，检查是否有TINYTEXT/TEXT字段带FULLTEXT索引——InnoDB虽支持全文索引，但5.6+才开始，旧版本不兼容 - 检查
sql_mode是否含STRICT_TRANS_TABLES或NO_ZERO_DATE，临时调整可绕过部分默认值校验（但不推荐长期关闭） - 对含自增主键的表，确保该列已显式定义为
PRIMARY KEY——MyISAM允许无主键存在自增列，InnoDB不允许
如何安全完成引擎转换？
核心思路：避免单次大操作，用可中断、可回滚的方式分步推进。
- 备份原表：
CREATE TABLE your_table_myisam_backup AS SELECT * FROM your_table;（注意：不复制索引和约束，仅数据） - 创建新InnoDB表：
CREATE TABLE your_table_innodb LIKE your_table; ALTER TABLE your_table_innodb ENGINE=InnoDB;，再手动补全缺失的索引和外键 - 逐批迁移数据：
INSERT INTO your_table_innodb SELECT * FROM your_table ORDER BY id LIMIT 10000 OFFSET 0;，配合应用层暂停写入或双写过渡 - 验证一致性后，原子切换：
RENAME TABLE your_table TO your_table_old, your_table_innodb TO your_table;
如果表有触发器或外键依赖，RENAME后需重新绑定——InnoDB表名变更不会自动同步外键引用，必须手动ALTER TABLE修正。
转换后必须检查什么？
引擎变了，行为也变。最易忽略的是事务与锁机制差异，不是改完就万事大吉。
- 查事务隔离级别：
SELECT @@transaction_isolation;，MyISAM不支持事务，InnoDB默认REPEATABLE-READ，某些业务逻辑（如“读已提交”语义）需显式调整 - 确认自增ID是否连续：InnoDB的
AUTO_INCREMENT在重启后可能跳号，而MyISAM是持久化记录的 - 监控
Innodb_row_lock_time_avg等状态变量，原来MyISAM的表级锁变成行锁，但若查询未走索引，照样升级为表锁，反而更隐蔽 - 检查
innodb_file_per_table设置，关闭时所有InnoDB表共用一个ibdata1，后续无法单独收缩单个表空间
真正麻烦的从来不是那条ALTER TABLE命令，而是它背后暴露的表结构债务和业务假设偏差。
