必须用pt-online-schema-change而非直接ALTER TABLE，因后者在MySQL 5.7中强制COPY算法，全程MDL锁、10GB表可能锁表半小时以上；pt-osc通过影子表+触发器实现无锁迁移，但需满足主键/无触发器/权限/外键处理四大前提。

直接改引擎必须用 pt-online-schema-change，原生 ALTER TABLE ... ENGINE=InnoDB 在 MySQL 5.7 中仍会全表拷贝并锁死 DML，10GB 表可能卡住半小时以上。

为什么不能只写 ALTER TABLE t1 ENGINE=InnoDB？

因为 pt-online-schema-change 的 --alter 参数只要求填「变更内容」，不是完整 SQL。写成 --alter "ALTER TABLE t1 ENGINE=InnoDB" 会报语法错误；正确写法是 --alter "ENGINE=InnoDB"。

常见错误现象：

• 命令执行直接退出，提示 Syntax error: unknown keyword 'ALTER'
• 误以为工具不支持改引擎，其实是参数格式错了

执行前必须满足的四个硬性条件

漏掉任一，工具会拒绝启动或中途失败：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 原表必须有主键或唯一非空索引，否则报错：Cannot chunk table `db`.`t`: no primary key or unique not-null index
• 原表不能已有任何触发器，否则提示：Triggers exist on the table
• 操作用户需显式拥有：TRIGGER、REPLICATION SLAVE、PROCESS 权限（仅 SELECT/INSERT/UPDATE/DELETE 不够）
• 若该表被其他表外键引用，必须指定 --alter-foreign-keys-method=auto，否则 RENAME 阶段失败

--chunk-time 和 --max-lag 怎么设才稳？

默认参数只适合测试库，生产环境必须调。重点不是快，而是不让从库延迟飙升、不让主库连接池打满：

• --chunk-time=0.4：控制每批拷贝耗时上限（秒），值越小对 IO/CPU 冲击越小；10GB 表建议 0.3～0.5，别碰 --chunk-size——它由 --chunk-time 动态反推
• --max-lag=1：从库延迟超 1 秒就暂停拷贝，防止复制中断；MySQL 5.7 默认监控 Seconds_Behind_Master
• --max-load="Threads_running=25"：主库活跃线程超 25 就暂停，避免连接雪崩
• --critical-load="Threads_running=50"：达到即中止，防止 DB 彻底卡死

执行完最容易被忽略的收尾动作

很多线上事故不是出在执行过程，而是收尾没做干净：

• 异常中断后，原表上可能残留 pt_osc_db_t1_del / pt_osc_db_t1_ins / pt_osc_db_t1_upd 触发器，必须手动清理：DROP TRIGGER IF EXISTS pt_osc_db_t1_del（把 db 和 t1 替换成实际值）
• 替换完成后，工具虽自动 RENAME 并删旧表，但必须人工核对：SHOW CREATE TABLE t1 确认字符集、索引、字段顺序是否正确；再用 pt-table-checksum 校验数据一致性——COUNT(*) 不可靠，触发器同步期间可能有极少量延迟