直接执行ALTER TABLE t ENGINE=InnoDB不是平滑切换，而是全表锁死、磁盘翻倍、主从延迟飙升的高危操作；MySQL 8.0中MyISAM→InnoDB仍强制走COPY算法，不支持ALGORITHM=INPLACE，必须用pt-online-schema-change实现无锁迁移，并同步调优innodb_buffer_pool_size等参数。
直接执行 ALTER TABLE t ENGINE=InnoDB 不是平滑切换，而是全表锁死、磁盘翻倍、主从延迟飙升的高危操作——哪怕在 MySQL 8.0 中，MyISAM → InnoDB 仍强制走 COPY 算法，不支持 ALGORITHM=INPLACE。
为什么 ALTER TABLE ENGINE=InnoDB 在生产环境会卡住业务
这不是“慢”，而是阻塞链式反应：原表被加 MDL 写锁后，所有 INSERT/UPDATE/DELETE 立即排队等待；SELECT 在可重复读（RR）隔离级别下也可能因一致性读视图依赖而卡住；SHOW PROCESSLIST 里长期显示 copy to tmp table，说明真正在搬数据，不是元数据切换。
- 10GB 表通常需预留 ≥22GB 磁盘空间（原 .MYD + .MYI + 新 .ibd + redo/undo 临时增长）
- 主库锁表期间 binlog 积压，从库回放时同样要等锁释放，
Seconds_Behind_Master可能跳到数千秒 - 即使加
LOCK=NONE，MySQL 也会自动降级为LOCK=EXCLUSIVE，因为引擎变更本身不支持无锁
哪些表可以谨慎用 ALTER TABLE 直接转
仅当同时满足以下全部条件时，才考虑直接 ALTER：
- 表大小 ≤ 500MB（SSD 上实测转换时间通常 ≤3 分钟）
- 业务允许该表在转换窗口内完全不可写（例如非核心配置表、只读字典表）
- 确认无
FULLTEXT索引（否则ALTER会直接报错退出） - 已有显式主键或唯一非空索引（避免 InnoDB 静默创建不可控的隐藏
ROW_ID） -
df -h /var/lib/mysql显示剩余空间 ≥ 原表.MYD大小 × 2.2
执行前务必先在从库验证：跑一遍 ALTER 观察耗时与锁表现象，别在主库盲试。
大表必须用 pt-online-schema-change 实现无锁迁移
这是目前唯一能在生产环境落地的“平滑”方案。它不依赖 MySQL 原生 DDL，而是靠影子表 + 触发器双写同步，业务几乎无感。
- 前提：目标表必须有主键或唯一非空索引（否则
pt-osc报错This table has no primary key or unique index） - 命令示例：
pt-online-schema-change --alter "ENGINE=InnoDB" D=your_db,t=big_table --execute - 迁移后不会自动删旧的
.MYD/.MYI文件，需人工确认数据一致（比对CHECKSUM TABLE）后再清理 - 不支持
FULLTEXT索引场景，需先DROP INDEX，迁完再重建（InnoDB 5.6+ 支持）
迁移后必须调的几个关键参数
切完引擎只是第一步，InnoDB 的行为和资源模型和 MyISAM 完全不同，不调参等于白迁：
-
innodb_buffer_pool_size应设为物理内存的 50%–75%，不能沿用 MyISAM 时代的key_buffer_size值 -
key_buffer_size可大幅降低（MyISAM 已不用），腾出内存给 InnoDB - 若能接受最多 1 秒事务丢失，把
innodb_flush_log_at_trx_commit从 1 改为 2，写性能提升明显 - 确认
innodb_file_per_table=ON（MySQL 5.6+ 默认开启），否则新表无法生成独立.ibd
真正容易被忽略的是 FULLTEXT 语法兼容性：MyISAM 的 MATCH ... AGAINST 在 InnoDB 中分词器行为不同，且不支持布尔模式下的某些修饰符——上线前必须用真实语句回归测试。
