不能直接用COUNT(*)统计存储过程的“总行数”，因为information_schema.routines仅存储routine_definition完整文本，不解析结构、不提供行数字段，需在应用层按换行符分割计数。
不能直接用 COUNT(*) 统计存储过程的“总行数”——因为 MySQL 不把存储过程体按源码行数存，而是以完整 CREATE PROCEDURE 语句字符串形式存在 routines 表中。
为什么 information_schema.routines 没有行数字段
information_schema.routines 只提供 routine_definition（整个定义的完整文本）、created、last_altered 等元信息，不拆解或预计算源码行数。MySQL 不解析、不存储过程体的格式化结构，所以没有现成的 line_count 列。
常见错误现象：
– 直接 SELECT COUNT(*) FROM information_schema.routines WHERE routine_schema = 'db'：这只是查出有多少个存储过程/函数，不是代码行数
– 误以为 routine_definition 是 JSON 或可展开结构：它就是一整段长文本，含换行符但无行号索引
从 routine_definition 提取真实代码行数（需客户端处理）
必须在应用层或命令行中对 routine_definition 字段做字符串分割计数，MySQL 本身不提供内置行数统计函数。关键点：
-
routine_definition字段类型是longtext，可能被截断（取决于max_allowed_packet和客户端设置） - 换行符可能是
\n（Linux/macOS）或\r\n（Windows），需统一处理 - 空行、注释行（
--、/* */）是否计入，取决于你的统计口径 - 示例（Python 脚本片段）：
import pymysql conn = pymysql.connect(...) cursor = conn.cursor() cursor.execute("SELECT routine_name, routine_definition FROM information_schema.routines WHERE routine_schema = %s AND routine_type = 'PROCEDURE'", ('your_db',)) for name, defn in cursor.fetchall(): if defn: lines = defn.strip().split('\n') print(f"{name}: {len(lines)} lines")
用 SQL 模拟“近似行数”（仅限简单场景）
MySQL 8.0+ 支持 JSON_LENGTH 和字符串函数，但无法可靠替代换行计数。以下方法仅作参考，**不推荐用于精确统计**：
-
CHAR_LENGTH(routine_definition) - CHAR_LENGTH(REPLACE(routine_definition, '\n', '')) + 1：粗略估算换行数加一，但会漏掉末尾无换行的情况，且\r\n会被算作两行 - 若
routine_definition含大量嵌套注释或字符串字面量（如'SELECT * FROM t WHERE x = "\n"'），该算法会严重失真 - 性能影响：全表扫描
routines+ 大字段计算，对含上百个过程的库明显变慢
真正需要“过程代码行数”时，该怎么做
如果你在做代码审计、合规检查或 CI/CD 质量门禁，依赖数据库元数据永远不够。正确路径是：
- 把存储过程 DDL 导出为文件：
mysqldump --no-create-info --no-data --routines your_db > routines.sql - 用标准工具统计（如
wc -l routines.sql或 IDE 的行数统计） - 若需区分过程体 vs 包裹语句，用正则提取
CREATE PROCEDURE.*?BEGIN和END\s*;之间的内容再计数 - 注意：
mysqldump输出含DELIMITER、注释、空行，原始 SQL 文件比routines.routine_definition更接近人工编写的形态
最易被忽略的一点：MySQL 服务端根本不知道你写的存储过程有多少“逻辑行”——它只认语法正确的块。所谓“行数”，本质是开发侧的文本度量，不在数据库职责范围内。
