MySQL 8.0 中 mysql.proc 表查不到是因为该表被彻底移除，元数据改存于事务性数据字典表（如 mysql.routines、mysql.parameters），且不可直接访问；查询应使用 SHOW CREATE PROCEDURE 或 INFORMATION_SCHEMA.ROUTINES 视图。
MySQL 8.0 中 mysql.proc 表为什么查不到了
因为 mysql.proc 表在 MySQL 8.0 中被彻底移除，不是“转为不可见”，而是物理删除 —— 所有存储过程、函数的元数据现在统一存进事务性数据字典表（如 mysql.routines、mysql.parameters），且这些表默认不可直接访问。
直接 SELECT mysql.proc 会报错 ERROR 1146
执行 SELECT * FROM mysql.proc; 时，MySQL 返回 ERROR 1146 (42S02): Table 'mysql.proc' doesn't exist。这不是权限或隐藏问题，是表本身已不存在。旧版 dump 或脚本若硬编码引用该表，会立即失败。
如何查存储过程定义和属性
- 用标准接口：
SHOW CREATE PROCEDURE proc_name;或SHOW CREATE FUNCTION func_name; - 查元数据信息：
SELECT ROUTINE_NAME, ROUTINE_TYPE, DEFINER, CREATED FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'db_name'; - 注意：
INFORMATION_SCHEMA.ROUTINES是视图，底层映射到mysql.routines等字典表，但做了权限过滤和字段裁剪，不暴露原始内部结构 - 不要尝试绕过：即使启用
SET SESSION debug='+d,skip_dd_table_access_check'，也查不到mysql.proc—— 它没被保留为隐藏表，只是被替换掉了
迁移脚本或监控工具容易踩的坑
很多 DBA 工具或自定义巡检脚本会扫描 mysql.proc 判断是否有存储过程。升级到 8.0 后这类逻辑必须重写，否则误报“无存储过程”。更隐蔽的问题是：某些 ORM 或备份工具依赖 mysqldump --routines 的输出格式，而 8.0 的导出内容虽兼容，但内部解析路径已变，若自行解析 dump 文件中的 CREATE PROCEDURE 块，要注意 DEFINER 字段现在强制包含主机名（如 DEFINER=`user`@`%`），旧版可能只写 `user`。
真正关键的不是“看不见”，而是“换了一套存储机制”——所有元数据现在都走 InnoDB 事务保护，mysql.proc 这种 MyISAM 表早已不合架构目标。如果你还在找它，说明底层假设还停留在 5.7 时代。
