binlog-ignore-db必须配在主库[mysqld]段，仅主库生效且影响binlog写入；从库不识别该参数，误配无报错但show master status中Binlog_Ignore_DB为空；它与replication-ignore-db作用阶段不同，前者在日志生成前过滤，后者在从库重放时跳过。
binlog-ignore-db 必须配在主库的 [mysqld] 段里
这个参数只对主库生效，且仅影响 binlog 写入——从库完全不认它。如果误配到从库配置文件里，mysqld 启动时不会报错，但 show master status 里 Binlog_Ignore_DB 字段始终为空，说明没生效。
常见错误是把 binlog-ignore-db 和从库的 replication-ignore-db 混用。后者是复制层过滤，两者作用阶段完全不同：前者在日志生成前就丢弃操作，后者是在从库重放时跳过。优先用 binlog-ignore-db，更节省主库 I/O 和网络带宽。
- 配置位置必须是主库的
my.cnf或my.ini中的[mysqld]段 - 不能写在
[client]或其他节下 - 每行只写一个库名，重复写多行才能忽略多个库
- 库名区分大小写，
test和TEST是两个不同库
多个库要忽略，得写多行 binlog-ignore-db
MySQL 不支持逗号分隔或通配符写法。比如想忽略 mysql、sys、monitor_db，必须这样写：
[mysqld] binlog-ignore-db=mysql binlog-ignore-db=sys binlog-ignore-db=monitor_db
如果写成 binlog-ignore-db=mysql,sys，MySQL 会把它当成一个叫 mysql,sys 的库名去匹配，实际毫无效果。
注意：binlog-ignore-db 和 binlog-do-db 互斥，不能同时存在。若两者都配置，MySQL 启动时可能拒绝加载，日志里出现类似 Unknown system variable 'binlog-do-db' 的错误（尤其在 8.0+ 版本中更严格）。
事务跨库时，binlog-ignore-db 会整条事务丢弃
这是最容易踩坑的地方。假设你设置了 binlog-ignore-db=test，然后执行：
BEGIN;
INSERT INTO test.t1 VALUES (1);
INSERT INTO app_db.users VALUES ('alice');
COMMIT;
整个事务都不会写入 binlog——哪怕 app_db.users 是你真正想同步的表。因为 MySQL 判断事务是否该记录，依据的是当前 session 的 USE 数据库，而不是语句里显式写的库名。
所以实际使用中：
- 避免在事务里混用被忽略库和业务库
- 不要依赖
USE test后再操作其他库来“绕过”过滤 - 如果业务必须跨库事务，要么取消忽略，要么改用从库侧的
replication-wild-ignore-table过滤
binlog-ignore-db 对 ROW 格式和 STATEMENT 格式行为一致
早期文档提过格式差异，但在 5.7 及之后版本中，binlog-ignore-db 的判断逻辑已统一：只看当前 session 的默认数据库（即 USE 的库），不解析 SQL 里的库名前缀。无论 binlog_format 设为 ROW 还是 STATEMENT，效果完全一样。
验证方式很简单：
- 先确认
binlog_format值：SELECT @@binlog_format; - 执行
USE ignored_db; INSERT INTO other_db.t VALUES(1); - 查
SHOW BINLOG EVENTS IN 'xxx-bin.000001' LIMIT 10;，看这条 INSERT 是否出现
只要 USE 的是被忽略的库，INSERT 就不会进 binlog，跟格式无关。
真正容易被忽略的是：配置修改后必须重启 mysqld 才生效，SIGHUP 或 FLUSH LOGS 都不行；而且重启失败时，一定要看 /var/log/mysqld.log 最后 30 行，而不是只盯终端报错。
