ALTER TABLE ... ENGINE=InnoDB 会加全表 DML 锁，阻塞 INSERT/UPDATE/DELETE，SELECT 默认不受影响；MySQL 5.6+ 部分支持 ALGORITHM=INPLACE，但多数仍走 COPY 算法，状态为 “copy to tmp table” 即正在拷贝。
ALTER TABLE ... ENGINE=InnoDB 会锁表吗
会，而且是**全表 DML 锁**（写锁），在执行过程中，所有 INSERT/UPDATE/DELETE 都会被阻塞，SELECT 默认不受影响（除非用了 FOR UPDATE 或 LOCK IN SHARE MODE）。这是最常被低估的风险——线上小表改引擎可能秒级完成，但一张千万级订单表可能卡住十分钟，连带压垮下游应用。
- MySQL 5.6+ 支持
ALGORITHM=INPLACE，但仅限某些存储引擎转换（如 MyISAM → InnoDB 在部分条件下可原地升级）；实际中多数情况仍走COPY算法，即重建表 - 确认方式：执行前加
SHOW PROCESSLIST，看到状态为copy to tmp table就说明正在拷贝数据 - 如果用的是阿里云 RDS 或腾讯云 CDB，它们的在线 DDL 工具（如
pt-online-schema-change）能绕过锁表，但需额外部署和权限
mysqldump 导出再导入比 ALTER TABLE 更安全吗
更可控，但不是“更安全”，而是**把不可控的锁表时间，换成了可计划的数据迁移窗口**。导出时源表照常读写，导入时目标表新建、数据灌入、原子切换，风险点转移到了切换那一刻。
- 导出命令建议加
--single-transaction（仅对 InnoDB 有效），避免导出中途被大事务拖慢或失败 - 导入前务必检查目标库的
innodb_file_per_table是否开启，否则所有表数据会挤进共享表空间ibdata1，后续难以回收磁盘空间 - 导入后别忘了重建索引：如果导出没带
--skip-opt，mysqldump默认会把DROP TABLE和CREATE INDEX一起写进去；但如果手动删表重导，索引得自己补
修改引擎后为什么查询变慢了
大概率是 **InnoDB 的默认配置太保守**，尤其是 innodb_buffer_pool_size 没调，或者表里有大量 TEXT/BLOB 字段触发了行溢出（off-page storage），导致每次查都要多一次磁盘 IO。
- 检查当前缓冲池大小：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'；生产环境建议设为物理内存的 50%–75% - 确认是否发生行溢出：
SELECT DATA_LENGTH, MAX_DATA_LENGTH FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'your_table'；若DATA_LENGTH远大于行数 × 平均行宽，就值得怀疑 - InnoDB 不支持全文索引（5.6+ 虽支持但性能弱于 MyISAM），如果原表靠
MATCH ... AGAINST查询，改完引擎后必须重建FULLTEXT索引，且要确认 MySQL 版本是否真正支持
如何验证 InnoDB 表结构和数据一致性
不能只看 SHOW CREATE TABLE 或 SELECT COUNT(*) —— 引擎改完后，主键是否隐式创建、外键约束是否生效、自增值是否连续，都得单独验。
- 查引擎和行格式：
SELECT ENGINE, ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'your_table'；推荐用ROW_FORMAT=DYNAMIC，避免大字段截断 - 检查自增值是否丢失：
SHOW TABLE STATUS LIKE 'your_table'中的Auto_increment值，应 ≥ 原表最大 ID；若小了，说明重建过程丢过自增偏移 - 外键依赖的表必须先改子表再改父表，否则
ALTER TABLE会报错ERROR 1025 (HY000)；可用SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'parent_table'快速定位依赖链
真正麻烦的不是改引擎这一步，而是改完之后发现某个凌晨三点的定时任务突然开始超时——因为没意识到 InnoDB 的间隙锁会让 SELECT ... FOR UPDATE 在范围查询时锁住更多行。
