STATEMENT模式下自定义函数必然导致主从不一致，因其非确定性行为（如调用NOW()、RAND()、依赖临时表等）在从库重放时结果不同；根本解法是改用ROW模式或确保函数显式声明DETERMINISTIC且无非确定逻辑。
STATEMENT模式下自定义函数必然导致主从不一致
只要 binlog_format = STATEMENT，所有未显式声明确定性的自定义函数都会引发主从数据偏差——这不是配置疏漏，而是 MySQL 的设计行为。主库记录的是调用语句（如 UPDATE t SET x = my_func(id)），从库重放时重新执行该函数，但函数内部若依赖 NOW()、RAND()、USER()、临时表或未提交的事务状态，结果几乎必然不同。
常见错误现象包括：主库返回非 NULL 值，从库返回 NULL；主库插入成功，从库因函数输出变化触发唯一键冲突；SQL 线程直接报错 ERROR 1418 (HY000)，提示函数未声明 DETERMINISTIC 或缺少权限。
- 即使主从都创建了同名函数，只要没加
DETERMINISTIC，MySQL 在 STATEMENT 模式下会拒绝写入 binlog（除非你设了log_bin_trust_function_creators = 1，但这只是绕过检查，不解决执行结果差异） - 函数内用
SELECT ... INTO @var读取数据时，主库查到一行，从库因复制延迟查不到，变量为NULL，后续逻辑全崩 - 函数访问的表被
replicate-ignore-db过滤，从库直接报Table doesn't exist
必须切换到ROW模式或严格声明DETERMINISTIC
根本解法只有两个，且互斥：要么放弃 STATEMENT，改用 binlog_format = ROW；要么坚持 STATEMENT，但每个函数必须满足 MySQL 对 DETERMINISTIC 的全部要求——即输入相同、环境一致时，输出绝对相同，且不读写任何外部状态。
ROW 模式下，函数只在主库执行一次，binlog 记录的是最终变更的行数据，从库跳过函数执行，直接应用变更。这是最稳妥的选择，5.7+ 默认已是 ROW，但很多老实例仍维持 STATEMENT。
- 确认当前模式：
SELECT @@binlog_format;，不是靠配置文件，而是运行时值 - 切 ROW 后，还需检查
binlog_row_image = FULL（避免部分字段更新丢失上下文） - 若必须用 STATEMENT，则函数定义必须显式包含
DETERMINISTIC，且内部禁用所有非确定性操作：不能调用NOW()、UUID()、CONNECTION_ID()，不能读用户变量、临时表、系统表，也不能执行 DML - 创建函数前确保
log_bin_trust_function_creators = 1，否则从库无法创建同名函数，导致调用失败
pt-table-checksum 能发现但无法定位函数问题
pt-table-checksum 可以暴露由自定义函数引发的数据不一致，但它只告诉你“哪张表不一致”，不会指出是哪个函数、哪条语句、哪一行出了问题。
例如主库执行 UPDATE orders SET status = calc_status(order_id)，如果 calc_status() 在从库返回不同值，checksum 就会失败。但工具输出里只有表名和 chunk 偏移，你需要人工抽样比对几行，再逆向查 SQL 日志，才能锁定函数。
- 运行前确保从库
read_only = ON，否则校验期间写入会导致误报 - 首次运行可加
--no-check-binlog-format跳过格式检查，但前提是已确认 binlog 是 ROW - 发现不一致后，不要直接用
pt-table-sync修复——它生成的 SQL 不含函数上下文，可能掩盖真正根源 - 更有效的做法是：抓出不一致的样本行 → 查主库 binlog 找出对应 UPDATE 语句 → 提取函数调用 → 在从库手动执行函数看输出差异
最容易被忽略的隐性风险点
很多人以为只要函数存在、语法合法、能跑通，就“安全”了。实际上，最危险的是一些看似无害的细节：
- 函数内调用另一个存储过程，而该过程用了
SELECT ... INTO—— 主库有数据，从库因延迟还没同步到依赖表，结果为空 - 函数读取的表启用了
innodb_stats_persistent = OFF，主从统计信息不同，导致优化器选错索引，查询结果集顺序不同，进而影响LIMIT 1类逻辑 - 函数中用了
CONVERT_TZ(NOW(), '+00:00', @@session.time_zone)，但主从服务器时区设置不一致，或会话时区被连接池复用污染 - 函数定义里写了
READS SQL DATA，但实际还写了日志表——这种声明不实，MySQL 不校验，但复制时可能因权限或上下文缺失失败
生产环境应默认假设所有自定义函数都是非确定性的，除非你能逐行代码证明它满足 DETERMINISTIC 的全部条件，并在主从相同环境下做过至少 24 小时的持续比对验证。
