Mixed模式适合高一致性与兼容性兼顾场景，MySQL自动在SBR和RBR间切换：对非确定性函数、JOIN、触发器等降级为RBR，保障安全；但大事务、SQL过滤或CDC解析时不宜使用。
Mixed 模式适合对数据一致性要求高、又希望兼顾复制效率和兼容性的场景。它在语句级（SBR）和行级（RBR）之间自动切换，由 MySQL 自己判断哪种更安全可靠，既避免了纯 SBR 在非确定性函数或临时表下的复制风险，也减少了纯 RBR 的日志体积和主从延迟压力。
适合 Mixed 模式的典型场景
• 存在大量 INSERT ... SELECT、UPDATE ... JOIN 或含 NOW()/UUID()/USER() 等非确定性函数的 SQL：Mixed 会自动对这类语句降级为 RBR，防止主从数据不一致。
• 业务混合了 OLTP 和轻量 OLAP 查询：比如日常增删改用 SBR 更高效，而批量更新或报表类操作由 RBR 保障准确。
• 升级老系统时需平滑过渡：原用 Statement 模式但已发现复制异常，切到 Mixed 可快速规避问题，无需重写所有 SQL 或重构应用逻辑。
• 使用了触发器、存储过程或自定义函数（且未显式声明 DETERMINISTIC）：Mixed 默认对这类操作启用 RBR，降低因特性识别不准导致的复制中断风险。
Mixed 不适合的场景
• 写入以大事务、大批量 UPDATE/DELETE 为主（如夜间数据清洗）：RBR 阶段会产生巨量 binlog，加重网络传输与从库回放压力，此时纯 RBR 配合 batch 配置反而更可控。
• 从库需要做基于 SQL 的灵活过滤（如 replicate-do-table）：Mixed 中部分语句是 RBR，无法按库/表名精确过滤，容易漏掉或误拦。
• 对 binlog 解析有强依赖（如用 Canal/Flink CDC 做实时同步）：Mixed 日志格式混杂，解析逻辑复杂度上升，建议统一用 RBR 更稳定。
模式选择实用建议
• 新项目直接选 ROW：语义清晰、行为可预测、调试方便，配合 binlog_row_image=FULL 和 slave_parallel_workers > 0 能很好支撑高并发写入。
• 已有 SBR 系统但偶发数据不一致：优先尝试 Mixed，观察一周内 Seconds_Behind_Master 波动和 SHOW SLAVE STATUS 中的警告项，无异常再考虑长期保留。
• 主从版本跨代（如 MySQL 5.7 主 + 8.0 从）：Mixed 兼容性比纯 SBR 更好，尤其涉及 JSON 函数或窗口函数时，RBR 分支能绕过语法解析差异。
• 不确定时，用 SELECT @@binlog_format 和 SHOW BINLOG EVENTS LIMIT 10 实际看几条日志格式，比文档更真实。
不复杂但容易忽略：Mixed 的“自动判断”依赖 MySQL 内部规则，不是 AI 智能选择，某些边缘 case（如含子查询的 REPLACE INTO）仍可能走 SBR 并出错。上线前务必在测试环境模拟真实流量验证。
