mysql comment属性仅作纯文本存储，不解析校验版本信息，长度限1024字节且超长静默截断；alter procedure会完全覆盖comment内容，无法累积版本记录；可靠版本管理应依赖源码注释、git版本库及自定义元数据表。
MySQL存储过程的COMMENT属性不支持版本字段
直接在 COMMENT 属性里写「v1.2.0」或「2025-04-01」这类版本标识，MySQL 会原样存入 ROUTINE_COMMENT 字段，但数据库本身**不解析、不校验、不索引**这个字符串——它只是个纯文本描述。你写成 COMMENT 'v2.0 (beta)' 或 COMMENT 'deprecated since 2024-12' 都可以，但 MySQL 不会据此做任何逻辑判断。
COMMENT字段长度限制为1024字节，超长会被截断
MySQL 对 ROUTINE_COMMENT 的定义是 varchar(1024)，超出部分静默丢弃，不报错也不警告。如果你习惯在注释里塞进 changelog、作者、修改时间、影响范围等信息，很容易踩中这个坑。
- 实际可用字符数取决于字符集：UTF8MB4 下一个中文占 4 字节，最多约 256 个汉字
-
SHOW CREATE PROCEDURE显示的是源码里的--注释，和COMMENT是两回事，别混淆 - 查询时用
SELECT ROUTINE_COMMENT FROM information_schema.ROUTINES才能拿到COMMENT值
ALTER PROCEDURE COMMENT 会覆盖整个COMMENT字段
每次执行 ALTER PROCEDURE proc_name COMMENT 'new text'，都会**完全替换**原有内容，不是追加。这意味着你无法靠多次 ALTER 累积版本记录。
- 想保留历史？得自己维护一张
proc_version_log表，手动 INSERT 记录 - CI/CD 流程中若自动生成 COMMENT，注意不要把人工写的说明（如「仅供测试环境使用」）给冲掉
- 空字符串
COMMENT ''是合法操作，效果等同于删除注释
真正可靠的版本管理必须脱离COMMENT字段
把版本号硬塞进 COMMENT 是权宜之计，长期来看容易失真、难追溯、不可审计。更务实的做法是：
- 源码中用
-- @version 1.3.0、-- @since 2025-03-15这类约定格式写在存储过程头部，和逻辑注释一起被SHOW CREATE PROCEDURE暴露出来 - 所有存储过程 DDL 脚本纳入 Git 版本库，分支名、commit hash、tag 就是真实版本依据
- 部署时用脚本读取当前 SQL 文件的 Git commit ID，写入自定义元数据表（比如
sys_proc_deploy），关联 procedure_name + version + deploy_time + operator
COMMENT 字段适合一句话功能摘要，比如 '计算用户月度活跃度，含去重与异常过滤'；版本细节交给外部系统管——这是 MySQL 存储过程元数据设计上就留下的缝隙，绕不开，只能接住。
