CALL proc_name() 在 Slave 上找不到过程，是因为主从复制默认不复制存储过程创建语句，除非 log_bin 开启且 log_bin_trust_function_creators=ON，否则 CREATE PROCEDURE 不写入 binlog，Slave 无该对象导致报错。
因为存储过程在主从之间不是直接复制代码，而是复制调用行为或执行结果，且默认不记录到 binlog 中——除非显式启用 log_bin_trust_function_creators 并满足安全限制，否则 Slave 上根本不存在该存储过程，执行时自然报错 ERROR 1305 (42000): PROCEDURE db_name.procedure_name does not exist。
为什么 CALL proc_name() 在 Slave 上找不到过程？
MySQL 主从复制默认只同步 DML/DDL 语句，而存储过程本身属于数据库对象，创建语句（CREATE PROCEDURE）是否被记录进 binlog，取决于两个关键配置：
-
log_bin必须开启（否则无 binlog 可复制） -
log_bin_trust_function_creators必须设为ON，否则带DETERMINISTIC、NO SQL或READS SQL DATA以外特性的过程，即使你写了CREATE PROCEDURE，MySQL 也会拒绝写入 binlog
如果主库上是手动执行 CREATE PROCEDURE 但未触发 binlog 记录（比如因权限不足或该变量为 OFF），Slave 就永远不会知道这个过程的存在。后续一执行 CALL，就直接报错。
SHOW SLAVE STATUS\G 显示 Last_SQL_Error 是 “PROCEDURE does not exist” 怎么办？
这不是数据不一致问题，是对象缺失问题。别跳过错误，先确认主库的创建语句是否真进了 binlog：
- 在主库查：
SHOW BINLOG EVENTS IN 'mysql-bin.0000xx' FROM N LIMIT 10，找是否有Create_db或Query类型事件包含CREATE PROCEDURE - 如果没有，说明过程没被复制；有，再检查 Slave 是否执行失败（比如同名过程已存在但定义不同）
- 临时修复：在 Slave 上手动执行相同的
CREATE PROCEDURE语句（注意校验参数、DEFINER、SQL SECURITY等细节必须一致）
注意：DEFINER='user@host' 若指向主库不存在的账号，Slave 执行会失败；建议统一用 SQL SECURITY INVOKER 避免依赖 definer 权限。
为什么有些存储过程在 Slave 上报 ERROR 1418？
这是经典提示：This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration。它发生在主库启用了 log_bin 但未设置 log_bin_trust_function_creators=1 时——主库允许创建，但拒绝将该过程写入 binlog，导致 Slave 缺失对象，同时 CALL 被当作普通语句尝试重放，触发校验失败。
- 根本解法：主库执行
SET GLOBAL log_bin_trust_function_creators = 1，并写入my.cnf持久化 - 补救动作：对已存在的过程，先
DROP PROCEDURE，再用带完整特性声明（如DETERMINISTIC）和SQL SECURITY INVOKER的语句重建 - 验证：在主库执行
SHOW CREATE PROCEDURE proc_name，确认输出中包含明确的特性声明
最易被忽略的一点：存储过程的复制行为与 binlog_format 无关（STATEMENT/ROW/MIXED 都不影响过程对象本身是否被同步），只取决于创建语句有没有进 binlog。只要过程没在 Slave 上真实存在，任何 CALL 都会失败——这不是延迟问题，是结构性缺失。
