不能,pt-online-schema-change 默认拒绝操作 MyISAM 表,因其依赖 InnoDB 支持的行级触发器实现在线 DDL,而 MyISAM 仅支持不可靠的语句级触发器;必须先手动将表转为 InnoDB,再使用该工具。
不能,pt-online-schema-change 默认拒绝操作 MyISAM 表——它会直接报错:Cannot operate on MyISAM table `db`.`tbl`。这不是 bug,而是设计限制:该工具依赖触发器(TRIGGER)实时同步变更,而 MyISAM 不支持行级触发器(仅支持语句级,且 pt-osc 无法安全使用)。必须先手动把表转成 InnoDB,再用 pt-online-schema-change 做后续 DDL。
别用 ALTER TABLE tbl ENGINE=InnoDB 直接在线执行——MyISAM 的 ALTER 是全表锁,业务高峰期可能锁表数分钟甚至更久。推荐分两步走:
CREATE TABLE tbl_new LIKE tbl 复制表结构(含索引、注释),再 ALTER TABLE tbl_new ENGINE=InnoDB
INSERT INTO tbl_new SELECT * FROM tbl 迁移数据;若数据量大,加 WHERE 分批(如按主键范围),并控制每批 10000 行以内RENAME TABLE tbl TO tbl_old, tbl_new TO tbl 原子切换(注意:MyISAM 表名大小写敏感,确保库名和表名拼写完全一致)DROP TABLE tbl_old
关键点:整个过程仍需停写窗口(RENAME 是瞬时的,但 INSERT ... SELECT 期间新数据会丢失,所以得在业务低峰期暂停写入,或用 FLUSH TABLES WITH READ LOCK 短暂锁表补漏)。
此时表已是 InnoDB,pt-online-schema-change 才能正常工作,但仍有几个坑要绕开:
--alter "ENGINE=InnoDB"(即使已经是 InnoDB),否则工具可能跳过引擎检查,导致后续失败FULLTEXT),InnoDB 的全文索引行为不同(如最小词长、停用词),迁移后需验证搜索逻辑是否受影响pt-osc 默认在从库上检查复制延迟,若原 MyISAM 表没主键,切换后可能因 INSERT DELAYED 或自增冲突引发复制错误,务必确保新表有显式主键SHOW PROCESSLIST 中的 pt-osc 操作线程,避免其被 max_statement_time 或 innodb_lock_wait_timeout 中断目前没有成熟工具能真正“在线”转换 MyISAM 引擎——mysqldump 导出导入必然停服;MySQL 8.0+ 的 ALTER TABLE ... ALGORITHM=INSTANT 仅支持列增删等极小改动,不支持引擎变更;Percona 自家的 pt-table-sync 也不能跨引擎同步。本质是 MyISAM 的架构缺陷:无事务、无行锁、无 MVCC,所有“在线”方案都得靠外部双写或停写窗口兜底。实际中,与其花时间找绕过方案,不如把这次转换当成推动业务弃用 MyISAM 的契机。