MySQL存储过程需用mysqldump加--routines导出，配合--no-create-info、--no-data及-B指定库名；不支持ALTER PROCEDURE，须DROP IF EXISTS后重建；脚本需统一sql_mode、校验库名、避免硬编码与隐式依赖，并规范DELIMITER用法。
MySQL存储过程怎么导出成可版本管理的SQL文件
直接用 mysqldump 默认不导出存储过程，得加参数显式开启，否则你 git commit 的只是空壳。
常见错误是只 dump 表结构，结果上线发现 CALL proc_name() 报错：「PROCEDURE not exists」——其实代码根本没进库。
- 必须加上
--routines（导出函数和存储过程） - 推荐同时加
--no-create-info --no-data，避免把表结构或数据混进来干扰变更追踪 - 如果过程依赖特定数据库，记得用
-B database_name指定库名，否则导出的CREATE PROCEDURE语句可能缺IF NOT EXISTS或默认库上下文
示例命令：mysqldump -u root -p --routines --no-create-info --no-data -B myapp > procedures.sql
ALTER PROCEDURE 能不能直接更新已存在过程
不能。MySQL 不支持 ALTER PROCEDURE 修改逻辑体，只能删了重建 —— 这就是脚本化部署最常翻车的地方。
你写了个新版本 CREATE PROCEDURE p1，但线上已有同名过程，直接执行会报错：ERROR 1304 (42000): PROCEDURE p1 already exists。
- 必须前置加
DROP PROCEDURE IF EXISTS p1，再跟CREATE PROCEDURE p1 - 注意：DROP 会清掉权限绑定，如果过程被其他账号
GRANT EXECUTE过，重装后要重新授权 - 不要用
CREATE OR REPLACE PROCEDURE—— MySQL 目前（8.0 仍不支持），写了就语法错误
如何让存储过程脚本在不同环境安全执行（dev/staging/prod）
核心是避免「本地改完直接 mysql -e 执行」这种操作。没有事务包装、无法回滚、缺乏环境校验。
真实踩坑场景：开发机上跑通的 CREATE PROCEDURE，到生产库因 SQL_MODE 差异（比如 strict mode）直接失败，且无提示。
- 所有部署脚本开头加
SET sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';，统一行为 - 用
SELECT DATABASE()或变量检查当前库名，非预期库名时主动EXIT（可用 shell 包一层判断） - 过程里慎用
INSERT INTO t SELECT ...这类隐式依赖表结构的语句——字段增减会导致脚本在旧环境挂住
示例片段：SELECT IF(DATABASE() != 'myapp_prod', 'ABORT: wrong DB', 'OK'); 配合客户端判断退出
Git 提交存储过程脚本要注意哪些细节
不是把 .sql 文件丢进去就完事。过程体里有硬编码库名、时间戳、测试数据，合并分支时极易冲突且难以 resolve。
典型问题：两个分支各自改了同一过程，git merge 后出现重复 CREATE PROCEDURE，或者 DELIMITER 错位导致语法错误。
- 所有
DELIMITER必须独立成行，前后不留空格，避免编辑器自动 trim 破坏结构 - 过程名、库名尽量用变量占位（如
${DB_NAME}），靠 CI 环境注入，而不是写死在 SQL 里 - 禁止在过程体中写
SELECT NOW()或INSERT ... VALUES (1, '2024-01-01')这类带具体值的语句——它们会让 diff 失去意义
最易忽略的一点：DELIMITER $$ 和 DELIMITER ; 必须成对出现，且中间不能夹杂注释行（MySQL 解析器会卡住）
