statement模式下自定义函数必然导致主从不一致，因其非确定性行为在从库重放时结果不同；根本解法是改用row模式或确保函数显式声明deterministic且无非确定逻辑。
自定义函数在STATEMENT模式下必然导致主从不一致
MySQL主从复制中，CREATE FUNCTION本身不写入binlog，但调用它的SQL语句在binlog_format = STATEMENT模式下会被原样重放——而自定义函数在从库执行时，若依赖非确定性逻辑（如访问系统时间、临时表、用户变量、外部文件或数据库状态），结果大概率与主库不同。这不是bug，是STATEMENT模式的固有缺陷。
常见错误现象包括：
- 主库
SELECT my_func(1)返回100，从库返回NULL或0 - 从库SQL线程报错
ERROR 1418 (HY000)：函数未声明DETERMINISTIC、NO SQL或READS SQL DATA - 主库插入成功，从库因函数返回值变化触发唯一键冲突或校验失败
根本解法不是“修函数”，而是切断非确定性传播路径：
- 强制将
binlog_format设为ROW（5.7+默认，但老实例常仍为STATEMENT） - 若必须用STATEMENT（如审计合规要求），则所有自定义函数必须显式声明
DETERMINISTIC且内部不调用NOW()、RAND()、UUID()、USER()等非确定函数 - 禁用
log_bin_trust_function_creators = 0（默认值），否则从库无法创建同名函数，导致调用时报错
为什么不能只在从库创建同名函数就完事？
即使主从都存在my_calc()，只要它没声明DETERMINISTIC，MySQL在STATEMENT模式下会拒绝记录含该函数的语句到binlog（报错ERROR 1418）。而如果强行设log_bin_trust_function_creators = 1绕过检查，函数在从库执行时仍可能因环境差异（如时区、字符集、临时表残留）返回不同结果。
更隐蔽的风险：
- 函数内使用
SELECT ... INTO赋值，主库查到1行，从库因数据延迟查到0行，变量为NULL，后续逻辑崩坏 - 函数调用存储过程或触发器，而这些对象在从库未启用
read_only = OFF时可能被误改 - 函数读取的表在从库被
replicate-ignore-db过滤，直接报表不存在
所以“函数存在”不等于“行为一致”。生产环境应默认假设所有自定义函数都是非确定性的，除非你能白纸黑字证明它满足DETERMINISTIC全部条件。
pt-table-checksum能发现函数引发的不一致吗？
能，但仅限于最终数据层面。例如主库用UPDATE t SET c = my_func(id)批量更新，pt-table-checksum会在主从分别计算t表校验和，若函数结果不同，checksum自然不匹配。
但它无法定位到是哪个函数、哪一行、哪次调用出的问题。你只会看到“表t不一致”，然后得人工比对样本行，再逆向排查SQL里是否用了函数。
真正有效的预防方式是：
- 上线前用
mysqldump --no-data导出所有函数定义，在测试环境模拟主从执行，对比输出 - 在主库开启
general_log，捕获含函数调用的DML语句，人工审查其确定性 - 禁止在从库执行
SET sql_log_bin = 0后调用函数写数据——这种操作不会进binlog，从库永远不知道自己“被污染”了
替代方案：把函数逻辑移到应用层或使用生成列
最彻底的解法是减少数据库层的不确定性。比如原函数gen_order_no()拼接时间戳+随机数，完全可以由应用生成后再INSERT；又如calc_discount(price, level)这类纯计算逻辑，改用MySQL 5.7+的GENERATED COLUMN（虚拟列）实现：
ALTER TABLE orders ADD COLUMN order_no VARCHAR(32) GENERATED ALWAYS AS (CONCAT(DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(FLOOR(RAND()*10000), 4, '0'))) STORED;
注意：STORED列会真实写入，且ROW模式下binlog记录的是最终值而非表达式，完全规避函数执行环境差异。但需确认该列不参与主键或索引设计冲突。
复杂业务逻辑仍建议收口到应用层——数据库只负责存和取，不负责“算”。这既是为一致性，也是为可测试性和灰度发布留余地。
函数本身没问题，问题在于你把它放在了复制链路里还假装它不会变异。真要保一致，就得要么让它绝对确定，要么让它彻底退出复制舞台。
