MySQL不支持复制掩码功能，仅提供基于库/表的粗粒度过滤（如replicate-do-table），无法对字段值脱敏或改写；字段级掩码须前置至应用层、中间件或使用企业版脱敏插件（仅影响查询输出）。
MySQL 本身不支持“复制掩码（Replication Masking）”这一功能，也没有名为 Replication Masking 的内置机制或配置项。这是个常见误解，通常源于将其他数据库（如 PostgreSQL 的逻辑复制策略）或第三方工具（如 Debezium、Maxwell）的概念误套到 MySQL 上。
MySQL 的复制过滤能力非常有限，且仅作用于二进制日志事件的分发阶段（即在从库 I/O 线程接收后、SQL 线程执行前），不能对字段值做脱敏、掩码或动态改写。
MySQL 复制中能做什么：基于库/表的黑白名单过滤
MySQL 支持通过以下参数在从库端跳过某些库或表的重放，属于粗粒度过滤：
-
replicate-do-db/replicate-ignore-db：按USE db_name切换的默认库生效，不推荐使用（行为易混淆，跨库语句可能失效） -
replicate-do-table/replicate-ignore-table：精确到db_name.table_name，较可靠 -
replicate-wild-do-table/replicate-wild-ignore-table：支持通配符，例如myapp.usr_%，实用性强
这些参数只控制「是否执行」，不修改数据内容。比如你设置了 replicate-ignore-table=finance.credit_card，那整张表的变更都不会应用到从库——但主库上该表的数据依然明文存在、照常写入 binlog。
为什么不能在复制流里做字段级掩码？
MySQL 的复制协议（基于 binlog event）不提供钩子（hook）或插件接口来拦截、解析、修改单个列值。即使你用 ROW 格式记录变更，Rows_log_event 中的字段值是序列化后的原始字节，没有运行时重写能力。
- binlog 是只读日志，不可篡改；修改它会导致校验失败、复制中断
- MySQL Server 层不暴露列值修改 API 给复制线程
- 官方不提供类似
BEFORE REPLICATION UPDATE的触发器机制
试图用 UPDATE ... SET card_number = CONCAT('****', SUBSTR(card_number, -4)) 在从库上“补救”，不仅滞后、还破坏主从一致性，属于反模式。
真正可行的替代方案有哪些？
若业务确实需要敏感字段在从库不可见，必须把掩码逻辑前置到应用层或引入中间层：
-
应用写入时脱敏：主库写入前就加密或掩码，例如用
AES_ENCRYPT()或应用代码处理card_number，从库自然同步密文 -
专用同步工具：用
Debezium + Kafka + KSQL或Flink CDC拦截 binlog，对特定字段做MAP转换后再写入目标库 -
视图+权限隔离：从库上建不含敏感字段的视图，并用
GRANT SELECT ON view_name限制用户访问原始表 -
MySQL 8.0+ 数据脱敏插件（仅限企业版）：
mysql_secrets插件可隐藏列值，但仅影响查询输出，不影响复制内容本身
注意：SELECT 层面的脱敏（如 HIDDEN COLUMN）不会改变 binlog 内容，从库接收到的仍是原始值。
容易被忽略的关键点
很多团队花时间调试 replicate-* 参数却仍看到不该出现的数据，原因往往是：
- 用了
replicate-ignore-db，但主库语句没带USE或用了跨库语法（如UPDATE user_db.users SET ... FROM finance_db.transactions ...） - 过滤规则大小写不匹配（Linux 下表名区分大小写，
mydb.UserTable≠mydb.usertable） - 启用了 GTID 后又手动
SET GLOBAL sql_slave_skip_counter，导致 GTID 不连续、后续复制异常 - 误以为
binlog_format=STATEMENT可以规避某些过滤，其实反而让replicate-wild-*更不可靠
真正安全的字段级控制，只能发生在写入主库之前，或者在复制链路之外的独立消费环节。MySQL 复制本身，就是一条“原样传递”的管道。
