直接执行alter table engine=innodb对大表必然失败，因其强制copy算法导致mdl写锁、磁盘空间翻倍、主从延迟飙升；小表（≤500mb）且无fulltext、有主键、磁盘充足时可谨慎尝试；大表必须用pt-online-schema-change无锁迁移。
直接执行 ALTER TABLE table_name ENGINE = InnoDB 对大表必然失败——不是语法错，是操作风险失控：全程 MDL 写锁、磁盘空间翻倍、主从延迟飙升。小表（≤500MB）且满足全部兼容条件时才可尝试；大表必须用 pt-online-schema-change。
确认当前引擎和三个硬性兼容点
别跳过这步。MyISAM 表若含 FULLTEXT 索引，ALTER TABLE ... ENGINE=InnoDB 会直接报错退出；若无主键或唯一非空索引，InnoDB 会静默创建隐藏 ROW_ID，后续排查难定位；AUTO_INCREMENT 列没建索引也会触发 ERROR 1075。
- 查引擎：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name'; - 查全文索引：
SHOW INDEX FROM your_table WHERE Key_name = 'FULLTEXT'; - 查主键/唯一索引：
SHOW KEYS FROM your_table WHERE Non_unique = 0 AND Seq_in_index = 1; - 确认
innodb_file_per_table已启用（MySQL 5.6+ 默认开），否则新表无法生成独立.ibd文件
小表（≤500MB）直接 ALTER 的实操边界
仅限同时满足：无 FULLTEXT、有主键、磁盘剩余 ≥ 原表 .MYD 大小 × 2.2、业务允许写入中断。过程中表被加 MDL 写锁，所有 INSERT/UPDATE/DELETE 阻塞，部分隔离级别下 SELECT 也可能卡住。
- 执行：
ALTER TABLE your_table ENGINE = InnoDB; - 监控进度：
SHOW PROCESSLIST;看是否长期停留在copy to tmp table - 完成后验证：
SHOW TABLE STATUS LIKE 'your_table';查Engine字段是否为InnoDB
大表必须用 pt-online-schema-change
原生 ALTER 在大表上强制走 COPY 算法，无法在线。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 -
--chunk-size=1000控制每批迁移行数（默认 1000） -
--max-lag=1防止从库延迟超 1 秒自动暂停 -
--check-interval=5每 5 秒检查一次延迟状态 - 迁移后旧的
.MYD和.MYI文件不会自动删除，需人工清理（先确认新表数据一致再删）
转换后必须调参，否则性能可能更差
InnoDB 和 MyISAM 行为差异极大，不调参等于白转。引擎改完立刻验证两件事：COUNT(*) 结果是否与原表一致；业务 SQL 是否仍能正常执行（尤其涉及 MATCH AGAINST 的全文查询）。关键配置项必须调整：
-
innodb_buffer_pool_size设为物理内存的 50%–75% -
key_buffer_size从几百 MB 降到 32M 左右（MyISAM 专用缓存） -
innodb_flush_log_at_trx_commit非金融场景可设为2（牺牲少量持久性换性能）
最常被忽略的是：default_storage_engine = InnoDB 只影响之后新建的表，已有 MyISAM 表一个都不会变——别以为配了就万事大吉。
