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 ;
<p>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参数；临时调试才用
@变量，且用完即弃。**
