必须改用row复制模式，因statement模式下rand()在主从重放时生成不同随机值，导致数据不一致；存量不一致需用pt-table-sync修复或重建从库。
因为会直接破坏主从数据一致性，且 MySQL 无法在 STATEMENT 复制模式下保证主库和从库执行出相同结果。
触发器里用 RAND() 会导致主从不一致
MySQL 触发器中调用 RAND() 时，主库执行一次得到一个随机数，但从库重放 binlog 时会再算一次——两次结果大概率不同。这在 STATEMENT 格式下是致命的，因为 binlog 只记录 SQL 语句，不记录函数实际返回值。
常见错误现象：
- 主库插入一行，
RAND()返回 0.72；从库重放时返回 0.38，导致字段值不同 -
INSERT INTO logs (id, rand_val) VALUES (1, RAND());在主从上生成完全不同的rand_val
解决路径很明确：把 binlog_format 切到 ROW（SET GLOBAL binlog_format = 'ROW';），并确保所有连接重连生效。但注意，存量 STATEMENT 日志已造成的数据偏差，不能靠跳过事件修复，得用 pt-table-sync 或重建从库。
SQL Server 中 RAND() 在触发器里可能根本跑不起来
SQL Server 对函数副作用更严格：RAND() 被归类为“带副作用的运算符”，在用户定义函数（UDF）中直接调用会报错 Msg 443：“在函数内对带副作用的运算符 'rand' 的使用无效”。虽然触发器本身允许用 RAND()，但一旦你试图封装成函数再被触发器调用，就立刻失败。
替代思路（不推荐但可行）：
- 改用
GETDATE()的毫秒部分做伪随机：DATEPART(ms, GETDATE()) % 6 + 5（生成 5~10 的整数） - 或用
NEWID()配合CHECKSUM()：ABS(CHECKSUM(NEWID())) % 6 + 5 - 但要注意：这些仍是非确定性函数，无法用于索引视图或计算列
性能和可维护性双重代价远超预期
哪怕绕过了复制和语法限制，RAND() 在触发器中仍带来隐性成本：
- 每次 INSERT/UPDATE 都调用一次，批量写入 10 万行 = 10 万次随机数生成，CPU 开销陡增
- 触发器逻辑变得不可预测，调试时无法复现某次“随机”行为
- 审计或迁移时，没人能从 SQL 里看出某字段值是“当时随机生成的”，还是“应用层传入的”
真正需要随机值的场景（比如抽奖、测试数据填充），应该由应用层生成后作为参数传入，让数据库只做确定性写入——这是最轻量、最可控、最容易验证的方式。
