Navicat同步大表时binlog暴涨，不能靠SET SQL_LOG_BIN=0解决，因其是全局变量且对DDL、触发器等无效；应改用TRUNCATE TABLE清空目标表，并禁用Navicat的DDL同步。
navicat 同步大表时 binlog 暴涨，不能靠会话级关闭 binlog 来解决——mysql 不允许在会话级别禁用 binlog。
SET SQL_LOG_BIN = 0 在 Navicat 里根本不起作用
很多人看到“同步大表”+“binlog 疯涨”，第一反应是：在 Navicat 当前连接里执行 SET SQL_LOG_BIN = 0，等同步完再 SET SQL_LOG_BIN = 1。但这是徒劳的：
-
SQL_LOG_BIN是全局变量，只对 SUPER 权限用户生效，且即使有权限，也仅影响当前会话后续的 DML/DDL，不改变已开启的事务行为 - Navicat 的“数据同步”功能底层不是单条 SQL 执行，而是自动生成批量 INSERT/UPDATE/DELETE + 事务封装，很多操作（如 DROP/CREATE 表）本身就会强制写 binlog，
SQL_LOG_BIN对其无效 - 更关键的是：Navicat 同步过程可能跨多个连接、自动重连、或使用内部临时表，会话级设置无法覆盖全程
真正可控的入口只有 TRUNCATE 而非 DELETE
Navicat 的“清空表”按钮实际执行的是 DELETE FROM table_name，这才是 binlog 爆炸的主因；而“截断表”才是你该点的那个选项：
-
TRUNCATE TABLE是 DDL，不逐行记录，不生成行级 binlog 事件，日志体积几乎为零 - 它会重置自增 ID，释放数据页，执行快、锁表时间短，适合同步前清理目标表
- 注意：
TRUNCATE不能回滚，且要求表无外键被引用（InnoDB 下若被其他表 ON DELETE CASCADE 引用，则允许）
同步前必须做三件事，否则光关 binlog 也没用
即便你真有 SUPER 权限并成功设了 SQL_LOG_BIN = 0，Navicat 同步仍可能触发 binlog，因为：
- 同步逻辑中若包含
DROP TABLE+CREATE TABLE，这类 DDL 默认强制记 binlog，不受SQL_LOG_BIN控制 - 目标表若启用了触发器（TRIGGER），触发器内部的 INSERT/UPDATE 仍会被记录
- 如果 Navicat 使用“INSERT IGNORE”或“REPLACE INTO”，这些语句本身就会产生完整 binlog 事件
所以正确做法是：
- 手动用
TRUNCATE TABLE target_table清空目标表（不是点“清空表”） - 确认源表和目标表结构一致，避免 Navicat 自动加 ALTER 语句
- 在 Navicat 同步设置里勾选「跳过 DDL 同步」，只同步数据
长期方案：别依赖 Navicat 做大表同步
图形化工具不是为百万级以上数据迁移设计的。真正稳定的做法是绕过它：
- 用
mysqldump --no-create-info --skip-triggers --single-transaction导出数据，配合--set-gtid-purged=OFF（如不用 GTID） - 导入时先
SET SESSION sql_log_bin = 0（需 SUPER 权限），再 source 文件 —— 这个才真正有效 - 或者改用
mysqlpump（MySQL 5.7+）或mydumper（支持并发导出），它们能更好控制 binlog 生成粒度
最后提醒一句：SQL_LOG_BIN 是高危开关，线上环境除非绝对必要且有回滚预案，否则不要轻易设为 0 —— 它不仅影响 binlog，还会让主从复制断裂、GTID 丢失、甚至导致备份不可用。
