MySQL存储过程应在固定高频跨应用且需强一致性的场景使用，如多表联合更新、财务流水生成等；慎用于简单查询，须正确设置DELIMITER、参数类型，并重视其调试难、版本管理难和高并发性能问题。
MySQL 存储过程不是“要不要用”的二选一问题，而是“在什么场景下值得用、在什么条件下必须慎用”。
它本质是数据库端预编译的一组 SQL + 控制逻辑，封装成可复用的命名单元，通过 CALL 调用。不是语法糖，也不是银弹——用对了省事提效；用错了反而锁死架构、拖慢迭代。
什么时候该写 CREATE PROCEDURE？
核心判断标准：逻辑是否「固定、高频、跨应用、需强一致性」。
- 业务中反复出现的多表联合更新（比如订单创建时扣库存 + 写日志 + 更新用户积分），且多个服务（Java/Python/Node）都要做同样动作
- 数据敏感操作必须走统一路径（如财务流水生成），不允许应用层拼 SQL 或绕过校验
- 网络带宽受限（如边缘设备或跨公网调用），需要把多轮 round-trip 压缩成一次
CALL - 某些原子性要求极高的操作，必须和事务绑定（例如“转账”不能只扣 A 不加 B），而应用层事务管理成本高或不可靠
反例：只是简单 SELECT * FROM users WHERE id = ?，完全没必要封装——ORM 或预编译语句更轻、更易测、更易迁移。
DELIMITER 不设对，整个存储过程就建不成功
这是新手踩坑最多的地方。MySQL 默认以分号 ; 结束语句，但存储过程体内部大量使用分号（比如 SELECT、SET、IF 后都带分号），不改分隔符会导致解析提前终止。
- 必须在
CREATE PROCEDURE前执行DELIMITER //（或其他非分号符号） -
END后紧跟//，再用DELIMITER ;恢复默认 - MySQL Workbench 等图形工具可能自动处理，但命令行或 CI 脚本里漏掉这一行，
CREATE就会报错：ERROR 1064 (42000)，提示 nearEND附近语法错误 - 不要用
\g或空格替代，只有DELIMITER指令生效
参数类型选错，OUT 变量根本拿不到值
IN、OUT、INOUT 不是可有可无的修饰词，直接影响调用方能否读取返回值。
-
IN：只进不出，适合传条件（如user_id） -
OUT：只出不进，适合返回单个结果（如统计数、状态码），调用前必须先声明变量：SET @result = '';，再CALL proc(@result); SELECT @result; -
INOUT：既进又出，适合需要原地修改的场景（如字符串拼接） - 所有
OUT/INOUT参数，必须用用户变量（@var）传递，不能直接传字面量（CALL proc('abc')对OUT参数非法） - 类型要严格匹配：
OUT p_count INT就不能用@count VARCHAR(10)接收，否则值为NULL
调试难、版本难、上线后难改，这三点最容易被低估
存储过程一旦上线，修改成本远高于应用代码。
- 没有断点调试能力，
SELECT中间结果或SELECT 'debug: ', xxx是主要手段 - 无法纳入 Git 版本控制（除非手动导出
SHOW CREATE PROCEDURE到文件），多人协作时容易覆盖或遗漏变更 - 修改存储过程需
DROP再CREATE，若线上正在执行，可能触发锁或中断调用（MySQL 8.0+ 支持CREATE OR REPLACE PROCEDURE，但仍有风险） - 高并发下，复杂逻辑（尤其是嵌套循环、大结果集
SELECT INTO）会显著抬高数据库 CPU 和连接占用，比应用层异步处理更难横向扩展
真正关键的不是“能不能写”，而是“谁负责维护、怎么灰度验证、出问题如何回滚”。这些细节没想清楚，就别急着把业务逻辑塞进数据库。
