需先执行SHOW VARIABLES LIKE 'log_bin'确认ON，再检查binlog_format是否为STATEMENT/MIXED、log_bin_trust_function_creators是否为ON，并用mysqlbinlog解析后人工搜索CREATE/ALTER PROCEDURE等关键词；MySQL 8.0+因元数据存于数据字典且不生成Query_event，Binlog基本无法捕获存储过程修改，应依赖performance_schema、general_log或审计插件。
如何确认 Binlog 是否开启并记录 DDL
MySQL 默认不记录存储过程的创建或修改语句（CREATE PROCEDURE、ALTER PROCEDURE）到 Binlog，除非显式启用 log_bin_trust_function_creators=ON 且 Binlog 格式为 STATEMENT 或 MIXED。更关键的是：从 MySQL 5.7.6 起，即使 Binlog 开启，ALTER PROCEDURE 等 DDL 语句默认也不会写入 Binlog —— 因为它们不经过存储引擎层，而是直接操作 mysql.proc 表（在 8.0+ 中已移除该表，改用数据字典）。
所以第一步必须验证：
- 执行
SHOW VARIABLES LIKE 'log_bin';，确认值为ON - 执行
SHOW VARIABLES LIKE 'binlog_format';，若为ROW，基本无法捕获存储过程修改（ROW 模式只记录行变更，不记录 DDL） - 执行
SHOW VARIABLES LIKE 'log_bin_trust_function_creators';，若为OFF，带函数/过程的操作可能被拒绝，更不会记 Binlog - 检查是否启用
binlog_ddl_ignore_if_not_exists=OFF（MySQL 8.0.23+），否则某些CREATE OR REPLACE PROCEDURE可能被跳过记录
用 mysqlbinlog 解析并过滤 DDL 事件
即使 Binlog 开启且格式为 STATEMENT，存储过程修改语句也只作为普通 Query_event 出现，没有专属 event type。需人工筛查：
- 先定位大致时间范围，用
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-05-20 10:00:00" --stop-datetime="2024-05-20 12:00:00" /var/lib/mysql/binlog.000001导出可读内容 - 在输出中搜索关键词：
CREATE PROCEDURE、ALTER PROCEDURE、DROP PROCEDURE、CREATE OR REPLACE PROCEDURE - 注意每个事件开头的
# at XXXX和#<code>server id行，它包含执行该语句的线程 ID 和用户（如#<code>user@host: app_user[app_user] @ [10.0.1.23]） - 如果看到
SET @@session.sql_log_bin=0;出现在附近，说明该操作被主动绕过了 Binlog 记录，查不到是正常的
为什么 8.0+ 环境下 Binlog 更难追溯存储过程修改
MySQL 8.0 彻底移除了 mysql.proc 表，所有存储过程元数据存于隐藏的数据字典表（如 mysql.component、mysql.routines），这些表的变更走的是内部事务路径，不生成标准 Query_event，也不触发 Binlog 写入 —— 即使 binlog_format=STATEMENT 也无济于事。
此时真正有效的线索只剩：
-
performance_schema.events_statements_history_long（需提前开启consumers并设置足够大的performance_schema_events_statements_history_long_size） - 通用查询日志（
general_log=ON），但性能开销大，且默认不记录用户信息全貌（需配合log_output='TABLE'查mysql.general_log表） - 审计插件（如
mysql_enterprise_audit或开源audit_log），这是唯一能稳定捕获 DDL 执行者、时间、IP 的方式
替代方案：从 information_schema.routines 查最后修改时间
information_schema.routines 表里有 CREATED 和 LAST_ALTERED 字段，但它不记录谁改的，只反映“最后一次被 ALTER 的时间”。这个时间点可以反向缩小 Binlog 检查窗口，但要注意：
-
LAST_ALTERED在 8.0.28+ 才真正可靠；早期版本可能因复制、导入等操作被错误更新 - 该字段不区分是本地执行还是从主库同步来的变更
- 如果过程是通过
CREATE OR REPLACE修改的，CREATED和LAST_ALTERED都会更新，无法判断是新建还是覆盖 - 执行
SELECT ROUTINE_NAME, LAST_ALTERED, DEFINER FROM information_schema.routines WHERE ROUTINE_SCHEMA = 'your_db' AND ROUTINE_NAME = 'your_proc';是最快捷的初步排查动作
真正想锁定“谁在什么时候改了哪一行逻辑”，仅靠 Binlog 几乎不可行 —— 它不是审计日志，设计上就不保证 DDL 行为的完整可追溯性。生产环境需要审计插件或应用层操作留痕机制。
