主从复制中触发器无法实现从库仅见脱敏内容，因其修改会写入binlog并同步到从库；BLACKHOLE引擎不能字段级过滤；ROW格式下应通过从库生成列或拆表+复制过滤实现安全脱敏。
主从复制中用触发器做数据脱敏会同步过去吗
不会——触发器在从库执行时，只对从库本地操作生效；但主库上的触发器产生的修改（比如 UPDATE 表字段为 NULL 或加密值），会原样写入 binlog 并同步到从库。也就是说：主库触发器改了什么，从库就收到什么，它不帮你“过滤”，反而可能把脱敏逻辑污染从库数据。
常见错误现象：BEFORE UPDATE 触发器在主库把 phone 字段替换成 CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))，结果从库也存了这个脱敏值，而不是原始值。
- 真正需要的是“主库保留明文、从库只看到脱敏后内容”，触发器做不到这点
- 如果硬要用触发器，只能在从库单独建一个同名触发器，且必须设为
SQL_LOG_BIN = 0，否则会循环写入 binlog 导致异常 - MySQL 8.0+ 支持
replica_sql_thread_skip_counter跳过某些事件，但不可靠，不推荐用于脱敏场景
黑洞引擎（BLACKHOLE）能用来过滤敏感字段吗
不能直接过滤字段，但可以配合 binlog_format = ROW 和从库的 replicate-wild-ignore-table 实现“逻辑丢弃”。BLACKHOLE 表本身不存数据，但它接收写入后仍会生成 binlog 事件——关键在于：这些事件是否进入 relay log，取决于主库 binlog 的内容和从库的复制过滤规则。
使用场景：你想让从库完全不接收某张表（如 user_profile）的变更，或只接收部分列（但 MySQL 不支持列级复制过滤）。
- 主库建
BLACKHOLE表只是个“假接收器”，真正起作用的是从库配置：replicate-wild-ignore-table = db_name.user_profile - BLACKHOLE 表无法控制字段级行为；想只过滤
id_card字段？得换方案 - 注意兼容性：
BLACKHOLE在 MySQL 5.7+ 稳定，但 Percona Server 或 MariaDB 对它的 binlog 行为有细微差异
ROW 格式下如何安全地做从库字段级脱敏
唯一可靠的方式是：主库保持原始数据 + 从库用 GENERATED COLUMN 或视图隐藏敏感字段，并配合复制过滤跳过真实敏感表。不要试图篡改 binlog 流或依赖存储引擎特性做脱敏。
实操建议：
- 主库表保留完整字段（
phone,email），但从库建一张结构一致的表，其中敏感字段定义为STORED生成列，例如：phone_masked VARCHAR(20) AS (CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))) STORED - 从库停掉 SQL thread，用
mysqldump --where="1=1"导出主库数据，导入时替换字段值，再启动复制 - 更稳妥的做法是：主库拆出敏感字段到独立表（如
user_sensitive），然后在从库配置replicate-ignore-table = db_name.user_sensitive - 务必确认
binlog_row_image = FULL（默认），否则部分更新可能丢失字段上下文，导致脱敏逻辑误判
为什么 mysqlbinlog 工具不适合在线脱敏
因为 mysqlbinlog 是离线解析工具，不能实时拦截或改写正在写入的 binlog 文件。你无法用它实现“主库写入时自动抹掉身份证号”这种效果。
容易踩的坑：
- 有人尝试用
mysqlbinlog --base64-output=DECODE-ROWS解析后 sed 替换再重放，这会导致 GTID 冲突、主键冲突、事务中断，且无法处理大事务流式写入 -
mysqlbinlog输出的 SQL 是伪 SQL，含@1 := ...变量赋值，直接执行极易报错：Unknown system variable '1' - 即使成功重放，也会破坏主从一致性校验（如 pt-table-checksum），后续无法做数据比对
真要处理 binlog 内容，得用基于 event 的中间件（如 Maxwell、Debezium），但那是另一套架构，不是 MySQL 原生复制能解决的事。
