用 mysqldump --no-create-info --no-data --routines --skip-triggers --set-gtid-purged=OFF --databases your_db > routines.sql 导出，手动删 CREATE DEFINER，按过程拆分为单文件，迁移脚本统一用 DROP PROCEDURE IF EXISTS + CREATE PROCEDURE + DELIMITER $$。
MySQL 存储过程怎么导出为可 Git 管理的 SQL 文件
直接用 mysqldump --routines 能导出，但默认会把所有 routine（含函数、存储过程）混在一起，且带 CREATE DEFINER，导致在不同环境还原失败。关键不是“能不能导”，而是“导出来的能不能干净地进 Git、能被团队复现”。
实操建议：
- 用
mysqldump -u root -p --no-create-info --no-data --routines --skip-triggers --databases your_db > routines.sql，去掉表结构和数据，只留 routine 定义 - 必须加
--set-gtid-purged=OFF（如果启用了 GTID），否则可能报错或插入无意义语句 - 导出后手动删掉每段开头的
CREATE DEFINER=`xxx`@`%` PROCEDURE，替换成CREATE PROCEDURE——Git 里不该存具体账号，DEFINER 应由部署时根据环境注入 - 每个存储过程单独成文件更利于 diff 和权限控制，可用脚本配合
mysql -e "SHOW PROCEDURE STATUS WHERE Db='your_db'"+mysqldump --no-create-info --no-data --routines --databases your_db --tables proc_name拆分
如何让存储过程变更走 Git 提交 → 自动执行迁移
routine 没有像 Flyway 那样原生支持的 migration 工具，硬套会踩坑：比如重复创建报 ERROR 1304 (42000): PROCEDURE xxx already exists，或者 ALTER 不支持直接改 body，只能 DROP + CREATE。
实操建议：
- 迁移脚本里统一用
DROP PROCEDURE IF EXISTS <code>proc_name+CREATE PROCEDURE <code>proc_name模式，避免冲突 - 不要依赖
ALTER PROCEDURE做逻辑更新——它不接受修改 routine body，只支持改 COMMENT 或 SQL SECURITY，实际等于没用 - 写迁移脚本时，用
DELIMITER $$包裹整个CREATE PROCEDURE，否则 MySQL 客户端会在第一个分号就截断 - Git 提交前跑一次
mysql -u dev -p your_db 验证语法，比等 CI 报错快得多
多个环境（dev/staging/prod）下 routine 权限与 DEFINER 怎么处理
本地开发用 root@localhost，测试环境是 app_user@10.%.%.%，生产又是 app_ro@10.10.%.% ——如果 SQL 文件里固化了 DEFINER，一模一样提交到 Git，上线就挂。
实操建议：
- Git 中所有 routine 文件**不写 DEFINER**，靠部署工具或初始化脚本动态注入。例如 Ansible 模板中用
CREATE DEFINER={{ db_user }}@{{ db_host }} PROCEDURE ... - MySQL 8.0+ 可设
SET sql_log_bin = OFF+CREATE PROCEDURE绕过 binlog 记录 DEFINER，但仅限临时调试，不可进 Git - 检查 routine 执行权限：
SELECT * FROM mysql.procs_priv WHERE Routine_name = 'xxx';，权限不是靠 DEFINER 决定的，而是调用者是否有EXECUTE权限，这点常被混淆 - 上线前务必确认目标库已授权：
GRANT EXECUTE ON PROCEDURE your_db.proc_name TO 'app_user'@'%';
routine 修改后如何做语义化版本与回滚
routine 没有内置版本号，Git commit hash 是唯一可信标识，但人眼难读。不能靠“v1.2.3”这种 tag 直接对应某个 proc，因为一个 release 可能含多个 routine 变更。
实操建议：
- 每个 routine 文件名带上小写蛇形命名 + 版本标记，如
calculate_revenue_v2.sql，v2 表示该 proc 的第 2 个兼容性破坏版（非全局版本） - 回滚不是“执行上一个 CREATE”，而是执行对应的
DROP PROCEDURE IF EXISTS <code>proc_name，再执行上一版的CREATE——所以每次变更都得保留前一版文件 - 禁止在 routine body 里写
SELECT VERSION()或类似“自报版本”的逻辑，那只是运行时信息，对 Git 管理无意义 - 如果 routine 依赖特定表结构，把它和对应 DDL 放进同一 commit，并在 commit message 里写明：“affects: revenue_summary table, requires column `tax_rate`”
最麻烦的不是导出或执行，而是当 routine 被其他 routine、事件、触发器隐式调用时，Git 里看不出依赖关系——这类耦合只能靠文档和命名约定硬扛。
