必须设binlog_format=ROW且binlog_row_image=MINIMAL，sync_binlog和innodb_flush_log_at_trx_commit均需为1，禁用binlog-do-db，GTID下CHANGE MASTER必须启用MASTER_AUTO_POSITION=1。
binlog_format=ROW 是主从复制的底线配置
不设为 ROW，后续所有调优都可能白做。STATEMENT 模式在遇到 NOW()、UUID()、临时表、存储函数等场景下，从库执行结果与主库不一致，MySQL 会悄悄降级为全表扫描或直接报错；MIXED 模式行为不可控，实际日志格式由 MySQL 内部判断，无法预期。必须在主库和从库的 my.cnf 中显式写死：binlog-format = ROW，并确认 SELECT @@binlog_format; 返回 ROW。
只改 binlog_format 不够，必须配 binlog_row_image=MINIMAL
默认 binlog_row_image=FULL 会让每条 UPDATE 记录整行变更前后的全部字段，宽表（比如 50+ 列）一次更新就产生几 KB 日志，IO 和网络压力陡增。改成 MINIMAL 后，仅记录 WHERE 条件涉及的列（前镜像）和真正被修改的列（后镜像），日志体积通常下降 60%–90%。
- 生效前提：MySQL ≥ 5.6，且从库
slave_parallel_type = LOGICAL_CLOCK - 设置方式：
SET GLOBAL binlog_row_image = 'MINIMAL';（无需重启，但需 SUPER 权限） - 验证命令：
SELECT @@binlog_row_image;，返回值必须是MINIMAL
为什么 sync_binlog 和 innodb_flush_log_at_trx_commit 要设为 1？
这两个参数不是“性能优化项”，而是防止主库崩溃后丢失已提交事务的关键防线。如果设为 0 或 2，主库宕机可能丢掉最后一批事务，导致从库永远追不上——这种“延迟”根本不是慢，是数据永久缺失。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
-
sync_binlog = 1：每个事务提交时强制刷 binlog 到磁盘 -
innodb_flush_log_at_trx_commit = 1：每个事务提交时强制刷 redo log 到磁盘 - 二者配合，才能保证 crash-safe 复制；若真要换性能，应优先考虑硬件（如 NVMe SSD）或架构（拆分大事务），而非关掉它们
容易被忽略的陷阱：binlog-do-db 和 replicate-wild-do-table 的误用
很多人以为加了 binlog-do-db = mydb 就能减少日志量，实际它只过滤基于 USE mydb 的语句，对跨库操作（如 INSERT INTO db2.t SELECT * FROM mydb.t）完全无效，还可能导致主从不一致。更糟的是，它在 GTID 模式下已被弃用。
- 真正安全的过滤方式是：
replicate-wild-do-table = mydb.% - 不要在主库用
binlog-do-db做“减负”，它不减少日志生成量，只影响哪些库的变更被记入 binlog；而日志体积主要由binlog_row_image和变更行数决定 - GTID 模式下，
CHANGE MASTER TO必须带MASTER_AUTO_POSITION = 1，否则binlog-do-db类参数会失效
真正影响主从复制性能的，从来不是“要不要开 binlog”，而是“每条变更到底记多少字节”。binlog_format 和 binlog_row_image 的组合，决定了日志膨胀系数；而 sync_binlog 和 innodb_flush_log_at_trx_commit 的取值，决定了你愿不愿意拿一致性换速度——后者一旦选错，问题就不再是“慢”，而是“不同”。
