Navicat 本身不支持生成灰度脚本或零停机变更，其同步功能仅为对比生成一次性DDL，直接执行会锁表；真正实现需依赖pt-online-schema-change等外部工具，Navicat仅作辅助操作界面。
Navicat 本身不支持生成灰度脚本或零停机变更
navicat 是一个数据库客户端工具，不是结构变更管理平台。它没有内置的在线 ddl 分析、sql 拆分、影子表调度或灰度执行能力。你看到的“同步”功能（tools → data sync 或 structure sync）本质是对比 + 生成一次性 ddl，直接执行会锁表、中断业务。
真正实现零停机结构变更，必须依赖外部策略和工具配合，Navicat 只能作为辅助操作界面。
用 pt-online-schema-change 配合 Navicat 手动触发灰度流程
Percona Toolkit 的 pt-online-schema-change 是 MySQL 生产环境最成熟的在线 DDL 工具，它通过影子表 + 触发器 + 增量拷贝实现无锁变更。Navicat 可用于查看进度、验证数据、手动补漏，但不能替代其执行。
- 先在终端运行变更命令，例如：
pt-online-schema-change --alter "ADD COLUMN status TINYINT DEFAULT 0" D=your_db,t=orders --execute
- Navicat 中可连上库，查
information_schema.PROCESSLIST看是否有长事务阻塞，或查_orders_new影子表是否存在来确认启动成功 - 变更期间，用 Navicat 对比原表和影子表的行数（
SELECT COUNT(*) FROM ordersvsSELECT COUNT(*) FROM _orders_new），判断同步是否滞后 - 不要在 Navicat 里手动
DROP TABLE _orders_old——pt-online-schema-change会在切换完成后自动清理；提前删会破坏原子性
Navicat 的 Structure Sync 仅适合非生产环境预演
如果你用 Structure Sync 对比两个测试库生成 DDL，它输出的 SQL 往往含 ALTER TABLE ... MODIFY COLUMN 这类高危语句。这类语句在 MySQL 5.7+ 默认为 inplace，但遇到某些类型变更（如 TEXT 列加索引、CHAR 变 VARCHAR 超过 255）仍会退化为 copy-alter，导致锁表。
- 务必勾选
Compare options → Ignore column order和Ignore comments，避免误判 - 生成的 SQL 必须人工审查：剔除
DROP INDEX、RENAME COLUMN等不支持 online 的操作 - 对主键变更、外键调整等敏感操作，
Structure Sync不会提示风险，但pt-online-schema-change会直接拒绝执行 - 导出的脚本只能当参考，不能直接扔进生产 —— 它没有回滚逻辑、无超时控制、无进度反馈
真正的灰度脚本需要拆解为三阶段 SQL 手动编写
所谓“灰度脚本”，是指把一次结构变更拆成可验证、可中断、可回滚的多个步骤，比如给大表加字段并默认值，需分三步走：
-
第一阶段（兼容写入）：只加字段，不设默认值，应用层兼容空值
ALTER TABLE orders ADD COLUMN is_archived TINYINT;
-
第二阶段（渐进填充）：用小批量 UPDATE 分批写入默认值，避免长事务
UPDATE orders SET is_archived = 0 WHERE id BETWEEN 10000 AND 19999 AND is_archived IS NULL LIMIT 1000;
-
第三阶段（收口）：改列为 NOT NULL + 设默认值，此时全表已无 NULL
ALTER TABLE orders MODIFY COLUMN is_archived TINYINT NOT NULL DEFAULT 0;
Navicat 可用来执行这些分段 SQL、监控慢查询日志、查 performance_schema.table_io_waits_summary_by_table 看 I/O 压力，但它不会帮你设计这三步 —— 这得靠你对 MySQL DDL 行为和业务流量节奏的理解。
最容易被忽略的是第二阶段的填充节奏：UPDATE 太猛会拖慢主库，太慢又延长灰度窗口。没有自动化的 sleep 控制或失败重试机制，全靠人工盯控。
