information_schema 不记录存储过程的磁盘占用大小，ROUTINES 表仅存定义文本（ROUTINE_DEFINITION），其 LENGTH 值仅为字符数，不反映实际字节占用；MySQL 未提供 routine_size 或 data_length 等字段，因存储过程本质是文本对象，编译后无独立物理存储结构。
information_schema 里没有存储过程的大小字段
直接查 information_schema.ROUTINES 或 information_schema.PROCEDURES，你会发现根本没有 data_length、routine_size 这类字段。MySQL 不在元数据表中记录存储过程的磁盘占用 —— 它们本质是文本对象，编译后不生成独立的数据页或索引结构，也不像表那样有 DATA_LENGTH 和 INDEX_LENGTH 的物理映射。
ROUTINES 表只存定义文本长度，不是实际磁盘占用
information_schema.ROUTINES 中的 ROUTINE_DEFINITION 是 longtext 类型，但你不能靠 LENGTH(ROUTINE_DEFINITION) 推算磁盘开销，原因包括：
-
ROUTINE_DEFINITION在 MySQL 内部可能被压缩存储（尤其启用了innodb_file_per_table=OFF时） - 存储过程的代码实际混存在系统表空间（如
ibdata1）或数据字典表中，无法按行隔离计量 - 该字段值还受 SQL 模式（如
SQL_MODE='NO_BACKSLASH_ESCAPES'）影响，返回长度不稳定
示例：查某个存储过程的定义长度
SELECT LENGTH(ROUTINE_DEFINITION) AS def_len FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'mydb' AND ROUTINE_NAME = 'proc_test';
这个 def_len 只反映字符数，和磁盘上真正占多少字节毫无关系。
想粗略估算，只能看 .frm（已弃用）或数据字典 I_S 表 + 文件系统
MySQL 8.0+ 已移除 .frm 文件，所有对象元数据统一存入数据字典表（mysql.component、mysql.routines 等），但这些表本身不暴露大小字段。目前唯一可操作的路径是：
- 确认 MySQL 版本是否 ≥ 8.0：运行
SELECT VERSION(); - 检查数据字典是否启用：
SELECT * FROM performance_schema.data_locks LIMIT 1;（非空即启用） - 用系统命令查看 ibdata1 或 undo 表空间增长趋势：
du -sh /var/lib/mysql/ibdata1，再对比创建大量存储过程前后的差值（极不精确，仅作趋势参考）
注意：不要用 SHOW CREATE PROCEDURE 后手动计算字符串长度——这忽略注释格式、换行符归一化、内部 AST 编码开销等真实因素。
真正影响空间的是调用产生的临时表和日志，不是过程本身
一个 1KB 的存储过程，如果它每次执行都 CREATE TEMPORARY TABLE 并写入百万行，那实际磁盘压力来自临时表和 binlog，跟过程体大小无关。排查空间问题时应优先关注：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;- binlog 文件大小：
ls -lh /var/lib/mysql/mysql-bin.*
存储过程本身几乎不“占空间”，它的代价在运行时；而 information_schema 也压根没设计用来回答这个问题。
