MySQL 存储过程是预编译、存于服务器端的 SQL 代码块，用于封装多步事务性操作（如扣库存 + 写订单 + 记日志），支持 IN/OUT/INOUT 参数、局部变量及逻辑控制，需用 DELIMITER 临时改分隔符以避免语法错误。
MySQL 存储过程 是一段 预编译、存于数据库服务器端的 SQL 代码块，不是视图、不是函数、也不是触发器——它是一套可被反复调用、带逻辑控制、能接收参数并操作数据的“数据库级程序”。
它最核心的定位是：把应用层常写的多步 SQL（比如查→判→插→更新）封装进数据库内部，由 CALL 一句话触发执行。
为什么 非得用 CREATE PROCEDURE？不直接写 SQL？
不是所有场景都需要存储过程，但以下情况它几乎不可替代：
- 需要在数据库内完成「事务性批量操作」，比如「扣库存 + 写订单 + 记日志」必须全成功或全回滚，且不能暴露中间状态给应用层
- 频繁调用同一组复杂查询逻辑（含
IF、WHILE、游标遍历），每次拼 SQL 网络开销大、易出错 - 想限制开发 / 运维对表的直接
UPDATE/DELETE权限，只开放EXECUTE权限调用指定过程 - 历史系统中已有大量业务逻辑沉淀在存储过程里，迁移成本高，需继续维护
反过来说：如果只是单条 SELECT * FROM user WHERE id = ?，硬套存储过程反而增加解析和权限检查开销，纯属画蛇添足。
DELIMITER 不设会报错？到底怎么用？
这是新手踩坑最多的地方：MySQL 默认以分号 ; 为语句结束符，但存储过程中每行 SQL 都要加分号（比如 SET @x = 1;、INSERT ……;）。如果不改分隔符，MySQL 会把 CREATE PROCEDURE …… BEGIN …… END; 在第一个 ; 就截断，报语法错误。
正确做法是临时切换分隔符（常用 // 或 $$）：
DELIMITER // CREATE PROCEDURE get_user_by_status(IN status VARCHAR(20)) BEGIN SELECT id, name, created_at FROM users WHERE user_status = status; END // DELIMITER ;注意三点：
-
DELIMITER后面 ** 不能有空格 **（DELIMITER//❌，DELIMITER //✅） -
DELIMITER ;必须写，否则后续所有语句都会被当成存储过程体的一部分 - Navicat / DBeaver 等 GUI 工具 可能自动处理分隔符，但命令行或脚本部署时必须显式声明
参数类型 IN/OUT/INOUT 怎么选？
参数方向决定数据流向，选错会导致调用后拿不到结果或意外覆盖输入值：
-
IN（默认）：只进不出，适合传条件值，如user_id、start_date -
OUT：只出不进，用于返回单个计算结果，如「统计总数」「生成唯一 编码」 -
INOUT：双向，输入值可被过程修改后返回，慎用——容易引发副作用，调试困难
示例：返回用户数
DELIMITER // CREATE PROCEDURE count_active_users(OUT total INT) BEGIN SELECT COUNT(*) INTO total FROM users WHERE status = 'active'; END // DELIMITER ; CALL count_active_users(@n); SELECT @n;
关键点：SELECT …… INTO 是给 OUT 参数赋值的唯一可靠方式；用 SET 赋值仅适用于局部变量或用户变量，对 OUT 参数无效。
局部变量、用户变量、系统变量，三者混用会出什么问题？
它们 作用域、生命周期、声明方式完全不同，混用极易导致「值为空」「取到旧值」「并发冲突」：
-
局部变量：用DECLARE var_name INT DEFAULT 0;声明，仅在BEGIN……END块内有效，必须声明才能用 -
用户变量：以@var_name形式存在，作用域是当前连接（session），不声明可直接用，但跨存储过程调用时行为不可靠（如CALL p1(); CALL p2();中@x可能被覆盖） -
系统变量：如@@sql_mode，全局或会话级，一般不建议在存储过程中修改，除非明确知道影响范围
真实踩坑案例：
写了个循环插入过程，用 @i := @i + 1 控制计数，结果并发调用时两个连接共用同一个 @i，数据错乱。改成 DECLARE i INT DEFAULT 1; + SET i = i + 1; 就稳定了。
记住：** 存储过程内优先用局部变量；跨过程传值走 OUT 参数；临时调试才用 @ 变量，且用完即弃。**
