主从复制中SQL执行流程本质未变，但执行主体变为重放binlog事件：ROW模式直接行应用，跳过解析/优化；STATEMENT模式才执行原始SQL，存在非确定性风险。

主从复制中 SQL 执行流程本质没变，但执行主体和上下文完全不同

MySQL 主库上执行 INSERT、UPDATE 等语句时，会走完整的解析 → 优化 → 执行 → 写 binlog 流程；而从库不是“重新执行原始 SQL”，而是**重放主库生成的 binl

og 事件**。这意味着：从库不走 SQL 解析器（parser），不触发查询重写（query rewrite），也不经过查询缓存（已弃用）或权限校验环节。

从库执行的是 Relay Log 中的 Events，不是原始 SQL 字符串

主库 binlog 记录的是逻辑变更事件（如 Write_rows_event、Update_rows_event）或语句事件（Query_event），取决于 binlog_format 设置。从库的 SQL Thread 读取 relay log 后：

• 若为 ROW 格式：直接按行应用变更，跳过所有 SQL 层逻辑，不依赖表结构一致性（但要求列数/类型兼容）
• 若为 STATEMENT 格式：才真正“执行”文本 SQL，此时会走完整 SQL 流程 —— 但风险高（如含 NOW()、UUID()、用户变量等非确定性函数）
• MIXED 格式由 MySQL 自动切换，对用户透明，但难以预测哪条走哪种路径

常见问题都源于“执行上下文错位”，不是流程本身出错

以下现象常被误认为“SQL 执行流程变了”，实际是主从环境差异导致：

• Duplicate entry 错误：从库已有数据，但主库 binlog 里没带 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE
• Table doesn't exist：主库删表后又建同名表，但从库 relay log 应用顺序被打断（比如中途 stop slave + reset slave）
• 时间函数结果不一致：STATEMENT 模式下 SYS_DATE() 在从库执行时取的是从库系统时间
• 自增 ID 跳变：主库批量插入触发 auto_increment 预分配，但 binlog 只记录最终值，从库无法还原中间状态

验证执行路径最直接的方式是看 SHOW PROCESSLIST 和日志

在从库执行：

SHOW PROCESSLIST;

你会看到两个关键线程：

• IO Thread：负责拉取主库 binlog，写入本地 relay log
• SQL Thread：负责读 relay log 并应用 —— 它的状态显示为 Reading event from the relay log 或 Executing event，而非 executing 原始 SQL

开启 log_slave_updates 后，再查从库的 SHOW BINLOG EVENTS，能看到 relay log 被转写成本地 binlog 的过程，进一步确认它不是“二次解析原始 SQL”，而是基于事件的转换。

真正容易被忽略的是：即使你用的是 ROW 格式，如果从库表结构缺失索引、或没有主键，UPDATE/DELETE 可能退化为全表扫描匹配 —— 这不是执行流程变了，是底层引擎在无索引约束下的自然行为。