大表从myisam转innodb必须用pt-online-schema-change避开锁表，因alter table engine=innodb在所有mysql版本中强制copy算法、全程mdl写锁、不支持algorithm=inplace；pt-osc通过影子表+触发器双写实现无锁迁移，但要求表有主键或唯一非空索引、仅主库执行、innodb_file_per_table=on，并需人工校验数据一致性后清理旧文件。
大表从 MyISAM 转 InnoDB 无法“减少锁表时间”，只能彻底避开锁表——因为 ALTER TABLE ENGINE=InnoDB 在任何 MySQL 版本（包括 8.0）中对 MyISAM 表都强制走 COPY 算法，全程 MDL 写锁不可绕过。
为什么 ALTER TABLE ENGINE=InnoDB 必然锁死大表
这不是执行慢的问题，而是设计层面的硬限制：MyISAM → InnoDB 的引擎变更不支持 ALGORITHM=INPLACE，MySQL 只能新建一个 InnoDB 表结构，逐行拷贝数据，最后原子替换。这个过程带来三个不可妥协的副作用：
-
MDL写锁持续整个拷贝周期，INSERT/UPDATE/DELETE全部阻塞，SELECT在 RR 隔离级别下也可能卡住 - 磁盘空间需 ≥ 原表
.MYD大小 × 2.2（含.MYI、新.ibd、redo log 临时增长） - 主库锁表期间 binlog 积压，从库回放时同样要等锁释放，
Seconds_Behind_Master可能跳到数千秒
一个 5GB 表，在 HDD 上常耗时 20–60 分钟；哪怕 SSD，也很难压到 5 分钟以内——这已超出绝大多数业务低峰窗口容忍范围。
pt-online-schema-change 是唯一可行的无锁方案
它不依赖 MySQL 原生 DDL，而是用“影子表 + 触发器双写”实现平滑迁移，原表全程可读写。但必须满足几个硬性前提，否则会中途失败：
- 目标表必须有
PRIMARY KEY或UNIQUE NOT NULL索引，否则pt-osc无法分块同步，报错This table has no primary key or unique index - 不能在从库运行，只允许在主库执行；执行期间禁止手动
DROP/ALTER原表，否则触发器失效导致数据不一致 - 默认
--chunk-time=0.5太激进，大表建议设为--chunk-time=1.0并配--max-lag=1，避免因主从延迟触发自动退出 - 确认
innodb_file_per_table=ON（5.6+ 默认开启），否则所有表挤进ibdata1，后续无法收缩空间
典型命令：pt-online-schema-change --alter "ENGINE=InnoDB" D=your_db,t=your_table --execute
哪些表可以勉强用 ALTER TABLE 直接转
仅当同时满足以下全部条件时，才考虑直接 ALTER TABLE：
- 表大小 ≤ 500MB（SSD 上实测转换时间通常 ≤ 3 分钟）
- 业务允许该表在转换窗口内完全不可写（例如非核心配置表、只读字典表）
- 确认无
FULLTEXT索引（否则ALTER会直接报错退出） - 已有显式主键或唯一非空索引（避免 InnoDB 静默创建不可控的隐藏
ROW_ID） -
df -h /var/lib/mysql显示剩余空间 ≥ 原表.MYD大小 × 2.2
执行前务必先在从库验证：SHOW PROCESSLIST 观察是否长期卡在 copy to tmp table；别在主库盲试。
真正容易被忽略的点是：转换后行为会变“严谨”。InnoDB 的事务、行锁、崩溃恢复机制会让原来在 MyISAM 上跑得通的 SQL 暴露问题——比如未加 WHERE 条件的 UPDATE 在 MyISAM 上只是慢，在 InnoDB 上可能锁全表并触发死锁检测；又比如没索引的 DELETE 会升级为间隙锁。迁移完必须做真实流量验证，不能只看 ENGINE 字段改了就认为完成。
