MySQL存储过程是什么以及是否应该使用

MySQL存储过程应在固定高频跨应用且需强一致性的场景使用，如多表联合更新、财务流水生成等；慎用于简单查询，须正确设置DELIMITER、参数类型，并重视其调试难、版本管理难和高并发性能问题。

MySQL 存储过程不是“要不要用”的二选一问题，而是“在什么场景下值得用、在什么条件下必须慎用”。

它本质是数据库端预编译的一组 SQL + 控制逻辑，封装成可复用的命名单元，通过 CALL 调用。不是语法糖，也不是银弹——用对了省事提效；用错了反而锁死架构、拖慢迭代。

---

什么时候该写 CREATE PROCEDURE？

核心判断标准：逻辑是否「固定、高频、跨应用、需强一致性」。

1. 业务中反复出现的多表联合更新（比如订单创建时扣库存 + 写日志 + 更新用户积分），且多个服务（Java/Python/Node）都要做同样动作
2. 数据敏感操作必须走统一路径（如财务流水生成），不允许应用层拼 SQL 或绕过校验
3. 网络带宽受限（如边缘设备或跨公网调用），需要把多轮 round-trip 压缩成一次 CALL
4. 某些原子性要求极高的操作，必须和事务绑定（例如“转账”不能只扣 A 不加 B），而应用层事务管理成本高或不可靠

反例：只是简单 SELECT * FROM users WHERE id = ?，完全没必要封装——ORM 或预编译语句更轻、更易测、更易迁移。

---

DELIMITER 不设对，整个存储过程就建不成功

这是新手踩坑最多的地方。MySQL 默认以分号 ; 结束语句，但存储过程体内部大量使用分号（比如 SELECT、SET、IF 后都带分号），不改分隔符会导致解析提前终止。

1. 必须在 CREATE PROCEDURE 前执行 DELIMITER //（或其他非分号符号）
2. END 后紧跟 //，再用 DELIMITER ; 恢复默认
3. MySQL Workbench 等图形工具可能自动处理，但命令行或 CI 脚本里漏掉这一行，CREATE 就会报错：ERROR 1064 (42000)，提示 near END 附近语法错误
4. 不要用 g 或空格替代，只有 DELIMITER 指令生效

---

参数类型选错，OUT 变量根本拿不到值

IN、OUT、INOUT 不是可有可无的修饰词，直接影响调用方能否读取返回值。

1. IN：只进不出，适合传条件（如 user_id）
2. OUT：只出不进，适合返回单个结果（如统计数、状态码），调用前必须先声明变量：SET @result = '';，再 CALL proc(@result); SELECT @result;
3. INOUT：既进又出，适合需要原地修改的场景（如字符串拼接）
4. 所有 OUT/INOUT 参数，必须用用户变量（@var）传递，不能直接传字面量（CALL proc('abc') 对 OUT 参数非法）
5. 类型要严格匹配：OUT p_count INT 就不能用 @count VARCHAR(10) 接收，否则值为 NULL

---

调试难、版本难、上线后难改，这三点最容易被低估

存储过程一旦上线，修改成本远高于应用代码。

1. 没有断点调试能力，SELECT 中间结果或 SELECT 'debug: ', xxx 是主要手段
2. 无法纳入 Git 版本控制（除非手动导出 SHOW CREATE PROCEDURE 到文件），多人协作时容易覆盖或遗漏变更
3. 修改存储过程需 DROP 再 CREATE，若线上正在执行，可能触发锁或中断调用（MySQL 8.0+ 支持 CREATE OR REPLACE PROCEDURE，但仍有风险）
4. 高并发下，复杂逻辑（尤其是嵌套循环、大结果集 SELECT INTO）会显著抬高数据库 CPU 和连接占用，比应用层异步处理更难横向扩展

真正关键的不是“能不能写”，而是“谁负责维护、怎么灰度验证、出问题如何回滚”。这些细节没想清楚，就别急着把业务逻辑塞进数据库。