为什么SQL中非确定性聚合结果会导致主从同步风险

rand()和uuid()在statement复制下必然导致主从不一致，因其每次执行返回值不同，而statement仅记录sql文本、不记录实际生成值，致使主从库插入同一行时code等字段值必然不同。

为什么sql中非确定性聚合结果会导致主从同步风险_注意rand或uuid的使用

为什么`RAND()`和`UUID()`在STATEMENT复制下必然导致主从不一致

RAND()和UUID()这类函数每次执行返回值都不同，而STATEMENT格式复制只记录SQL文本，不记录实际生成的值。主库执行INSERT INTO t(id, code) VALUES (1, UUID())时生成了'a1b2c3d4-...' ，从库重放这条语句时会重新调用UUID()，得到另一个完全不同的值——结果就是同一行在主从库中code字段值永远不等。

这种不一致不是“偶尔出错”，而是只要用了、又没切ROW格式，就一定发生。尤其容易被忽略的是隐式使用场景，比如触发器里调用RAND()生成默认排序权重，或存储过程中用UUID()作临时键。

常见错误现象包括：

主从表校验工具（如pt-table-checksum）持续报某几列差异
SHOW SLAVE STATUS\G中Slave_SQL_Running为Yes，但数据肉眼可见不一致
业务侧发现“刚插入的记录查不到”——其实是读了从库，而该记录的UUID在从库被替换成另一个值，WHERE条件失效

如何快速识别当前是否正在用STATEMENT格式且含非确定性函数

先确认复制格式：SELECT @@binlog_format; —— 若返回'STATEMENT'，就得立刻检查SQL。

再扫描高风险语句：SELECT * FROM information_schema.PROCESSLIST WHERE INFO LIKE '%RAND()%' OR INFO LIKE '%UUID()%';
（注意：这只能捕获当前活跃连接中的语句，历史慢日志或应用拼接SQL需额外排查）

更稳妥的做法是开启通用日志（general_log = ON）并抓取一段时间内的写入SQL，用脚本过滤含RAND、UUID、NOW()、SYSDATE()、USER()等关键词的INSERT/UPDATE语句。

修复方案不是“改写SQL”，而是切换复制格式+约束写法

RAND()和UUID()本身没有错，错的是让它们在STATEMENT模式下参与DML。解决路径很明确：

立即把主从binlog格式切到ROW：SET GLOBAL binlog_format = 'ROW';（需重启生效或确保所有会话重新连接）
对存量STATEMENT日志引发的不一致，不能靠跳过解决——因为跳过只是掩盖，数据已歪；要用pt-table-sync反向修复从库，或重建从库
应用层避免在INSERT/UPDATE中直接调用UUID()；如必须用，改由应用生成后传入参数，保证主从执行的是相同字面值
若用RAND()做排序抽样（如ORDER BY RAND() LIMIT 1），务必改用其他方式，例如先查总数再用应用层随机选offset，或加预计算字段