mysql可通过information_schema.routines表查存储过程的created和last_altered时间，但last_altered仅在执行alter procedure时更新，drop+create不会刷新该字段；routine_definition字段常为null，因安全策略限制。
查存储过程最后修改时间：用 information_schema.ROUTINES
MySQL 不像 PostgreSQL 那样直接暴露 last_altered 字段给所有用户，但 5.5+ 版本起，information_schema.ROUTINES 表中确实有 LAST_ALTERED 和 CREATED 两列——前提是你的账户有访问 information_schema 的权限（通常有），且该过程不是由 DEFINER 权限受限的账户创建的（否则可能显示为 0000-00-00 00:00:00）。
执行以下语句即可查指定过程的修改时间：
SELECT ROUTINE_NAME, CREATED, LAST_ALTERED FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_database_name' AND ROUTINE_NAME = 'your_procedure_name' AND ROUTINE_TYPE = 'PROCEDURE';
-
ROUTINE_SCHEMA必须精确匹配数据库名，区分大小写（取决于系统变量lower_case_table_names） - 如果
LAST_ALTERED和CREATED相同，说明该过程自创建后未被ALTER PROCEDURE或重建过 - 注意：MySQL 不会因
DROP+CREATE而更新LAST_ALTERED—— 它只响应ALTER PROCEDURE语句；若你用的是DROP+CREATE，那LAST_ALTERED实际上就是新的CREATED时间
看存储过程源码：用 SHOW CREATE PROCEDURE
这是最直接、最可靠的方式，不需要权限查 information_schema 的 ROUTINE_DEFINITION 字段（该字段在某些配置下会被设为 NULL，比如 log_bin_trust_function_creators=OFF 且过程含非确定性操作）。
运行：
SHOW CREATE PROCEDURE your_database_name.your_procedure_name;
- 必须带数据库名前缀（如
mydb.my_proc），否则报错ERROR 1305 (42000): PROCEDURE my_proc does not exist - 返回结果中第二列为
Create Procedure，第三列为完整定义（含DELIMITER、注释、空格等原始格式） - 如果提示
Access denied，说明当前用户缺少SELECT权限（对mysql.proc表）或EXECUTE权限（部分旧版本要求）；此时需 DBA 授权：GRANT SELECT ON mysql.proc TO 'user'@'host';
为什么 information_schema.ROUTINES.ROUTINE_DEFINITION 经常是 NULL？
这不是 bug，而是 MySQL 的安全策略：当过程定义包含非确定性函数（如 NOW()、UUID()）、或启用二进制日志且 log_bin_trust_function_creators=OFF 时，MySQL 会主动清空 ROUTINE_DEFINITION 字段以避免复制不一致风险。
所以别依赖它查源码——即使字段有值，也可能被截断（默认长度 64KB，超长即截断）。
- 想确认是否被截断？对比
CHAR_LENGTH(ROUTINE_DEFINITION)和实际代码行数 - 若必须从
information_schema取定义，且你确定环境安全，可临时设SET log_bin_trust_function_creators = 1;（需 SUPER 权限）再查，但生产环境不建议长期开启
小技巧：快速导出多个过程定义到文件
命令行下用 mysqldump 最省事：
mysqldump --no-create-info --no-data --routines --skip-triggers your_database_name > procedures.sql
-
--routines包含存储过程和函数；加--no-create-info和--no-data确保只导出定义 - 输出里每个过程都带
DELIMITER $$和CREATE PROCEDURE ... $$，可直接 source 回库 - 注意：该命令不会导出
LAST_ALTERED时间，如需审计，请配合前面的information_schema查询做补全
时间戳和源码本身不联动更新，尤其在手动 DROP/CREATE 场景下，容易误判“最新修改”——得盯住操作记录或 binlog 才能真正还原变更时序。
