rand()在statement模式下主从不一致，因其非确定性导致从库重放时生成不同随机值；必须切row模式并禁止sql中直接调用rand()，应用层应预生成随机值传参。
RAND() 函数本身没有错，错的是它在 STATEMENT 复制模式下参与写操作（INSERT/UPDATE）——主从执行时生成的随机值不同，导致数据不一致。
必须切换到 ROW 模式，并约束应用层用法，否则跳过错误或重建从库都只是临时止血。
为什么 RAND() 在主从同步中会出问题
在 STATEMENT 模式下，MySQL 把整条 SQL（比如 INSERT INTO t VALUES (RAND())）原样记录进 binlog。从库回放时重新执行 RAND()，但两次调用返回值几乎必然不同，主从数据就对不上了。
这种不一致不是延迟问题，是永久性偏差：主库某行插入了 0.723，从库同一行插了 0.198，后续所有基于该字段的查询、索引、JOIN 都可能错。
-
RAND()是非确定性函数，MySQL 官方明确标注“不能用于复制安全上下文” -
UUID()同理，UUID_SHORT()也一样，只要每次调用结果不可预测，就不适合STATEMENT -
ORDER BY RAND()查询本身不影响同步，但若嵌套在子查询里参与INSERT ... SELECT，就会触发风险
立即生效的修复动作：切到 ROW 复制格式
执行以下命令（需确保所有客户端重连，或重启 MySQL）：
SET GLOBAL binlog_format = 'ROW';
验证是否生效：
SELECT @@binlog_format;
注意：ROW 模式下，binlog 记录的是行变更前后的镜像，不再依赖函数重执行，RAND() 就不会造成主从差异。
- 不要只改配置文件后 reload，
SET GLOBAL是即时生效的，且比配置文件优先级高 - 确认从库也运行在
ROW模式（SELECT @@slave_type_conversions不影响此问题，但需检查slave_parallel_type = LOGICAL_CLOCK是否启用） - 已产生的
STATEMENT日志无法逆转，已有不一致必须用pt-table-sync或重建从库修复，不能靠sql_slave_skip_counter
应用层必须规避的写法
即使开了 ROW，仍建议从源头杜绝非确定性函数写入——因为未来如果误切回 STATEMENT，或做逻辑备份/迁移，隐患还在。
- 禁止在
INSERT或UPDATE语句中直接调用RAND()，例如：INSERT INTO log (rand_val) VALUES (RAND()) - 如需随机值，由应用生成后作为参数传入，保证主从执行的是完全相同的字面值，例如：
INSERT INTO log (rand_val) VALUES (?);（? = 0.456789） - 避免
INSERT ... SELECT ... ORDER BY RAND() LIMIT N这类写法；抽样需求改用应用层分页+随机 offset，或加预计算字段（如提前给每行分配一个shard_id） - 测试环境也要禁用
RAND()写入，否则上线后才发现主从 diff，代价远高于早期约束
容易被忽略的兼容性细节
有些旧业务用 RAND(N)（带 seed 参数）试图“稳定”随机结果，但这依然危险：
-
RAND(123)在同一连接内可重复，但主从是两个独立连接，seed 初始化时机不同，结果仍不一致 - MySQL 8.0.30+ 对非确定性函数写入有更严格警告（
ER_BINLOG_UNSAFE_STATEMENT），但默认不中断执行，需开启binlog_error_action = ABORT_SERVER才能强制拦截 - Docker 环境下还要额外检查：主库容器是否绑定了
--bind-address=0.0.0.0，否则从库连得上但无法读取 binlog
真正安全的边界只有一个：写入语句的右侧表达式必须是确定性的——常量、列名、确定性函数（如 UPPER()、DATE_ADD()），RAND() 永远不在其中。
