CDC必须用ROW格式且binlog_row_image=FULL，因STATEMENT模式记录SQL语句，遇NOW()、UUID()等非确定性函数会导致主从不一致；MIXED模式降级不可预测，使Debezium/Flink CDC解析断裂；而ROW+FULL才能保障变更事件完整可靠。
必须设为 ROW，且 binlog_row_image 必须为 FULL，否则 CDC 会丢变更或解析失败。
为什么不能用 STATEMENT 或 MIXED 格式？
STATEMENT 模式只记录原始 SQL，遇到 NOW()、UUID()、自增主键冲突、非确定性函数时，从库重放结果和主库不一致；MIXED 虽自动降级，但 CDC 工具（如 Debezium、Flink CDC）无法可靠预测哪条语句被转成 ROW，导致解析逻辑断裂。CDC 场景下，binlog_format=STATEMENT 或 MIXED 直接等同于数据同步不可靠。
怎么确认和设置 binlog_format 和 binlog_row_image？
先查当前值：
SHOW VARIABLES LIKE 'binlog_format';<br>SHOW VARIABLES LIKE 'binlog_row_image';
若不满足要求，需在配置文件中强制设定（仅靠 SET GLOBAL 不持久，重启即失效）：
-
binlog_format=ROW—— 必须写在[mysqld]下，大小写不敏感但推荐全大写 -
binlog_row_image=FULL—— 注意不是full或Full，MySQL 严格匹配字符串 - 若 MySQL 版本 ≥5.6.5，建议同时开启
gtid_mode=ON和enforce_gtid_consistency=ON，避免主从切换时位点错乱
常见错误现象与排查点
即使 log_bin=ON，CDC 连接仍报错或收不到 UPDATE/DELETE 事件，大概率是以下原因：
-
binlog_row_image是默认的MINIMAL：UPDATE 只记变更字段，DELETE 没有旧值，Flink CDC / Debezium 无法构造完整变更事件 - 用户缺少
REPLICATION SLAVE权限：连接时提示Access denied; you need (at least one of) the SUPER, REPLICATION SLAVE privilege(s) -
server-id未配置或为 0：MySQL 启动时会静默禁用 binlog，SHOW VARIABLES LIKE 'log_bin'仍显示 ON，但实际不写日志 - 配置了
binlog_ignore_db或binlog_do_db却没覆盖目标库：日志直接被过滤，下游完全看不到变更
配置后必须验证的三件事
改完配置、重启 MySQL 后，别急着起 CDC 任务，先手动验证：
- 执行
SHOW MASTER STATUS;—— 确保有非空的File和Position，且File名以你配置的log-bin前缀开头 - 执行一条
UPDATE，再查SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10;—— 看事件类型是否含Write_rows_v2/Update_rows_v2/Delete_rows_v2 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 5 -B 5 "your_table_name"—— 确认输出里有明确的### UPDATE ... ### WHERE或### DELETE FROM结构
只要其中任意一步失败，CDC 就不可能稳定工作——日志格式只是起点，但它是整个链路最不可妥协的硬门槛。
