pt-online-schema-change在mysql 5.7中可安全在线转换存储引擎，但仅在rename table阶段持极短元数据锁，其余时间原表读写不受影响；需满足主键/唯一索引、无外键或指定外键处理方式、禁用复制过滤、innodb_file_per_table=on四大前提，并必须使用--execute、--max-lag=5、--chunk-time=0.5等关键参数保障稳定性。
pt-online-schema-change 在 MySQL 5.7 中能安全地在线转换存储引擎，但必须清楚：它不是“真正无锁”，而是在极短时间内持有元数据锁（RENAME TABLE 阶段），其余全程原表可读写。
pt-online-schema-change 转换引擎前必须确认的 4 个前提
- 原表必须有主键或唯一非空索引，否则工具直接退出并报错：
This table has no primary key or unique index - 表不能有外键约束，或需显式加
--alter-foreign-keys-method=auto让工具自动处理（会重建外键） - 从库不能启用复制过滤（如
replicate-ignore-db），否则--check-replication-filters默认阻止执行 - 确保
innodb_file_per_table=ON（MySQL 5.7 默认开启），否则新表无法生成独立.ibd文件，导致失败
ENGINE=InnoDB 这条 ALTER 语句为什么能用 pt-osc 执行
ENGINE=InnoDB 看似是 DDL，但在 pt-online-schema-change 中被当作结构变更操作处理：
- 它会在影子表上执行
ALTER TABLE ... ENGINE=InnoDB，而非原表 - 如果原表已是 InnoDB，该操作等效于
OPTIMIZE TABLE（重建表、整理碎片） - 工具会自动跳过无实质变更的字段/索引定义，但引擎切换总会触发重建
注意：MyISAM → InnoDB 是最典型场景，但反向（InnoDB → MyISAM）不推荐，且需确认 MySQL 实例未禁用 MyISAM 引擎。
生产环境执行时最关键的 3 个参数组合
-
--execute：必须显式带上，否则只是预演（--dry-run模式只建影子表、不启触发器、不拷数据） -
--max-lag=5：当从库延迟超过 5 秒，工具自动暂停拷贝，避免拖垮复制链路 -
--chunk-time=0.5：控制每批拷贝耗时上限为 0.5 秒，防止单次查询太久阻塞线上查询
其他实用参数：
-
--critical-load="Threads_running=50"：活跃线程超 50 就暂停，防雪崩 -
--set-vars="innodb_lock_wait_timeout=1"：让 pt-osc 在锁冲突中主动让出，不卡住业务事务
切换完成后的残留和验证要点
RENAME TABLE 原子操作完成后，旧表会被重命名为 _tablename_old，默认 90 秒后自动删除。但生产环境建议：
- 手动检查是否存在
_xxx_old表，确认无业务误查后才删 - 查
information_schema.tables验证新表ENGINE字段是否已更新 - 检查触发器是否已清理干净：
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table';应返回空
最容易被忽略的是：如果中途被 kill 或网络中断，触发器可能残留，下次执行会报错 Trigger already exists，此时需手动 DROP TRIGGER 再重试。
