mysql 5.7及更早版本的mysql.proc表无真实创建时间，created/modified字段恒为'0000-00-00 00:00:00'；应查information_schema.routines的last_altered（5.5+可靠），或mysql 8.0+的created字段。
mysql.proc 表里没有创建时间字段
MySQL 5.7 及更早版本的 mysql.proc 表**根本不存储创建时间或修改时间**，它的 created 和 modified 字段是固定值（如 '0000-00-00 00:00:00'），不可信。这是最常被误用的点——直接查 mysql.proc 拿不到真实时间。
原因在于：这些字段在早期 MySQL 中仅作占位，未被实际写入；官方文档也明确说明其值“不可靠”。所以别再 SELECT created FROM mysql.proc WHERE name = 'xxx' 了。
真正可用的方法：从 information_schema.routines 查看 last_altered
information_schema.routines 是 MySQL 5.5+ 提供的标准化视图，其中 LAST_ALTERED 字段记录的是**最后一次 DDL 修改时间**（包括 CREATE、ALTER），对多数场景已足够接近“创建时间”——尤其当过程创建后从未被 ALTER 过。
执行以下查询即可：
SELECT ROUTINE_NAME, CREATED, LAST_ALTERED, ROUTINE_DEFINITION FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db_name' AND ROUTINE_NAME = 'your_proc_name';
-
CREATED字段在 MySQL 8.0+ 才开始真实记录首次创建时间；5.7 及以前仍为0000-00-00 00:00:00 -
LAST_ALTERED在 5.5+ 全版本可靠，只要没被 ALTER 过，它就等于创建时间 - 注意
ROUTINE_SCHEMA必须显式指定库名，不能依赖当前 USE 的库（视图不感知上下文）
MySQL 8.0+ 可用 performance_schema（但需提前开启）
如果启用了 performance_schema 并且打开了 events_ddl_history_long 或 events_ddl_history_short 表（默认关闭），可通过 DDL 历史事件反查：
SELECT EVENT_TIME, OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, OPERATION FROM performance_schema.events_ddl_history_long WHERE OBJECT_SCHEMA = 'your_db_name' AND OBJECT_NAME = 'your_proc_name' AND OBJECT_TYPE = 'PROCEDURE' ORDER BY EVENT_TIME DESC LIMIT 1;
- 该方法能拿到精确到微秒的创建/修改时间，但前提是：
performance_schema已启用，且对应 history 表未被截断 - 默认配置下这些表为空，需手动设置
performance_schema_events_ddl_history_long_size等参数并重启 - 生产环境极少开启此功能，属于“有备无患但通常不用”的方案
没有元数据怎么办？只能靠外部记录或 binlog 解析
如果 MySQL 版本 ≤ 5.6，又没开 performance_schema，且 information_schema.routines.LAST_ALTERED 因权限或 bug 不可见（极少数情况），那就真没内置办法了。
- 检查备份 SQL 文件里的
CREATE PROCEDURE时间戳（如果有定期导出习惯） - 查 MySQL 错误日志或通用查询日志（如果开启过
general_log，且日志里保留了建过程的语句） - 解析 binlog：用
mysqlbinlog --base64-output=DECODE-ROWS -v找到对应CREATE PROCEDURE事件的时间（要求 binlog_format = STATEMENT 且未过期）
这类兜底方式都依赖外部条件，不是数据库自身可查的元数据——意味着一旦没留痕，创建时间就永远丢失了。
