alter table 修改存储引擎卡住或失败主因是外键约束、全文索引、分区表或长事务阻塞mdl锁；myisam转innodb需注意主键缺失、缓冲池配置及analyze table更新统计信息。
ALTER TABLE 修改存储引擎时为什么会卡住或失败
常见现象是执行 ALTER TABLE t ENGINE=InnoDB 后长时间无响应，或者报错 ERROR 1025 (HY000)、ERROR 1217 (SQLSTATE: 23000)。根本原因不是语法错，而是外键约束、全文索引、分区表或正在运行的长事务在阻塞元数据锁（MDL）。
实操建议：
- 先查是否有活跃事务：
SELECT * FROM information_schema.INNODB_TRX; - 检查外键依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 't'; - MyISAM 表含全文索引时不能直接转 InnoDB（老版本 MySQL 5.6 之前），需先
DROP FULLTEXT INDEX - 大表转换会锁表且生成临时表，建议在低峰期操作，并确认
tmpdir有足够空间
INFORMATION_SCHEMA.TABLES 里 ENGINE 值没变但实际已生效
这是缓存或查询时机问题。MySQL 的 INFORMATION_SCHEMA 是只读视图，部分字段（如 ENGINE）可能延迟更新，尤其在并发 DDL 操作后。
实操建议：
- 别只信
SELECT ENGINE FROM INFORMATION_SCHEMA.TABLES，用SHOW CREATE TABLE t看建表语句里的ENGINE=字段更可靠 - 也可查
SELECT TABLE_NAME, ENGINE FROM performance_schema.table_handles WHERE OBJECT_SCHEMA='db_name' AND OBJECT_NAME='t';（需开启 performance_schema） - 如果应用层缓存了表结构（如某些 ORM），记得清空连接或重启服务
MyISAM 转 InnoDB 后查询变慢的三个典型原因
不是引擎本身变慢，而是默认行为差异被忽略。InnoDB 的事务、行锁、聚簇索引机制和 MyISAM 的堆表+表锁完全不同。
实操建议：
- 主键缺失：MyISAM 允许无主键，InnoDB 强制要求；若原表没主键，InnoDB 会隐式创建
ROW_ID，导致二级索引变大、范围扫描效率下降 —— 务必显式添加合适主键 - 自增字段未设为 PRIMARY KEY 或 UNIQUE NOT NULL：否则
INSERT可能触发全表扫来校验唯一性 - 未调整
innodb_buffer_pool_size：MyISAM 主要靠 OS 缓存，InnoDB 严重依赖该参数；生产环境建议设为物理内存的 50%–75%
跨版本迁移时 ENGINE 参数兼容性陷阱
MySQL 5.7 默认引擎是 InnoDB，8.0 移除了 MyISAM 的全文解析器插件支持；而 MariaDB 对 ENGINE=ARIA 或 ENGINE=Maria 有额外行为。看似一样的语法，实际效果可能不同。
实操建议：
- 升级前用
SELECT VERSION(), @@default_storage_engine;确认当前默认值 - 导出 SQL 时注意 mysqldump 默认不带
--skip-create-options，会把 ENGINE 写死；还原到目标库前先 grep 替换或用--compatible=mysql40 - 云数据库（如阿里云 RDS、AWS RDS）可能禁用 MyISAM，执行
ALTER TABLE ... ENGINE=MyISAM会直接报错ERROR 1286 (42000): Unknown storage engine 'MyISAM'
最常被跳过的一步：改完引擎后没跑 ANALYZE TABLE，导致优化器统计信息还是旧的，执行计划失真。尤其对大表，这比改引擎本身影响更隐蔽。
