SET SQL_LOG_BIN=0仅对当前会话生效，关闭后该连接的DML/DDL操作不写入binlog，但其他连接照常记录；需SUPER权限，重启或断连后自动恢复为1，GTID模式下该设置被强制忽略。
临时关闭 binlog 只对当前会话生效，不能停掉其他连接或全局日志写入，别误以为它能“暂停整个 MySQL 的 binlog”。
SET SQL_LOG_BIN=0 只影响当前会话
执行 SET SQL_LOG_BIN=0 后，你在这个连接里执行的 INSERT/UPDATE/DELETE/CREATE 等写操作，不会被记入 binlog。但其他已存在或新建立的连接照常记录。
- 该设置不持久，连接断开或 MySQL 重启后自动恢复为 1
- 必须有 SUPER 权限才能执行，普通账号会报错
ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER privilege(s) for this operation - DDL（如
ALTER TABLE）和 DML 都受控，但某些管理语句（如GRANT、FLUSH）本身就不进 binlog，设不设都一样
为什么 SET SQL_LOG_BIN=0 有时像没起作用？
常见误解是“关了就全不记”，其实容易踩这几个坑：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 你在 A 连接执行了
SET SQL_LOG_BIN=0，但在 B 连接里查SHOW BINARY LOGS或做主从同步，依然能看到日志在增长——因为 B 连接没关 - 用客户端工具（如 Navicat、DBeaver）执行后没注意是否复用了旧连接，可能实际还在另一个 session 里操作
- 开启了 GTID 模式（
gtid_mode=ON）时，SET SQL_LOG_BIN=0会被强制忽略，MySQL 直接报错ERROR 1787 (HY000): When @@GLOBAL.GTID_MODE = ON, @@SESSION.SQL_LOG_BIN cannot be set to OFF.
检查和验证是否生效
不要只信自己敲了命令，现场确认最可靠：
- 执行
SELECT @@SQL_LOG_BIN;—— 返回 0 表示当前会话已关闭 - 执行一条写语句（如
INSERT INTO t1 VALUES (1);），再立刻执行SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10;，看最后几条有没有刚插的那条事件 - 注意：如果 binlog 文件刚切走（比如刚
FLUSH LOGS过），新事件会落在mysql-bin.000002里，别只盯一个文件
替代方案：哪些场景下不该依赖 SET SQL_LOG_BIN=0
这个命令只是“会话级静音”，不是系统级关停。真要规避 binlog 写入，得看具体目标：
- 想清空已有 binlog？用
RESET MASTER;（慎用，会清空所有 binlog 并重置序列）或PURGE BINARY LOGS - 想长期省空间或禁用复制？必须改配置文件注释掉
log-bin，再重启 MySQL - 只想跳过某类操作（比如导入测试数据）？配合
SET SQL_LOG_BIN=0+ 显式事务控制更稳妥，但记得结束后手动SET SQL_LOG_BIN=1
真正难处理的是 GTID 环境下的临时屏蔽——它根本不允许关，这时候要么换非 GTID 实例操作，要么接受日志必然产生，再靠 expire_logs_days 控制保留周期。
