ALTER TABLE t ENGINE=InnoDB 切换引擎会锁表，MyISAM↔InnoDB 不支持原地DDL，需重建表并持MDL与写锁，导致读写阻塞；推荐mysqldump导出再重建以精确控锁、保一致、易回滚。
ALTER TABLE 用 ENGINE= 切换存储引擎会锁表
mysql 5.6 及之后版本执行 alter table t engine=innodb 默认走“原地 ddl”，但 myisam ↔ innodb 切换不支持原地，必须重建表。这意味着整个过程会加 mdl（元数据锁）+ 表级写锁，期间所有读写都被阻塞。
常见错误现象：SHOW PROCESSLIST 里看到大量 Waiting for table metadata lock；业务查询超时、连接堆积。
- 线上大表（比如 >10GB）切引擎前务必在低峰期操作，且先用
SELECT COUNT(*)验证表是否可访问（避免隐式锁等待） - MyISAM 转 InnoDB 后，
AUTO_INCREMENT行为变化：InnoDB 的自增值是事务安全的，重启后可能跳号（MyISAM 是持久化到磁盘的） - 如果表有全文索引，MyISAM 支持，InnoDB 从 5.6 才支持，且语法细节不同（如停用词配置路径不同）
mysqldump + DROP + 导入 是更可控的切换方式
比起直接 ALTER TABLE，导出再重建能明确控制锁窗口、校验数据一致性，也方便回滚。
使用场景：主从架构中需保持从库同步、或表结构含特殊字符/注释易被 ALTER 误处理时。
- 导出时不加
--no-create-info，保留CREATE TABLE语句，手动把ENGINE=MyISAM替成ENGINE=InnoDB - 导入前先
DROP TABLE，否则CREATE TABLE IF NOT EXISTS不会改引擎 - 注意
mysqldump --single-transaction对 MyISAM 无效（它不支持事务），必须用--lock-tables或停写保障一致性
InnoDB 和 MyISAM 的关键行为差异直接影响切换决策
不是所有表都适合随便换引擎。有些字段类型或 SQL 模式下，强行切换会导致建表失败或语义改变。
典型问题：
-
TINYTEXT/TEXT在 MyISAM 中允许全文索引，在 InnoDB 中要求至少 3 字符长度才能建全文索引（否则报错ERROR 1071 (42000): Specified key was too long） - MyISAM 支持
CHECKSUM=1表选项，InnoDB 不识别，导入时会被忽略，但不会报错——容易误以为校验功能还在 - InnoDB 默认
innodb_file_per_table=ON，每个表一个.ibd文件；MyISAM 是三个文件（.frm+.MYD+.MYI），切换后原.MYD/.MYI不会自动清理，得手动删
查看当前引擎和确认切换结果不能只看 SHOW CREATE TABLE
SHOW CREATE TABLE 显示的是建表语句里的声明，但实际引擎可能因配置或权限限制没生效。比如 sql_mode 含 NO_ENGINE_SUBSTITUTION 时，指定不支持的引擎会报错；不含时则静默替换成默认引擎（通常是 InnoDB）。
- 验证是否真切换成功，优先查
information_schema.TABLES：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t';
- 如果发现引擎没变，检查 MySQL 错误日志，常见提示是
Unknown storage engine 'InnoDB'（说明服务没启用 InnoDB）或Table upgrade required（旧表格式不兼容） - 切换后务必跑一次
ANALYZE TABLE t，尤其 MyISAM → InnoDB，统计信息不继承，可能导致后续查询执行计划劣化
ROW_FORMAT（如 FIXED）在 InnoDB 中无对应概念，切换后自动转为 COMPACT 或 DYNAMIC，而这个转换会影响行溢出处理和空间占用，大字段多的表要提前评估磁盘增长。
