mysql存储过程语法错误的根本原因是默认分号结束符与过程体内分号冲突，必须用delimiter //临时切换结束符，以end //结束过程，并用delimiter ;恢复，默认分隔符。
MySQL 存储过程不是“写完就能用”的语法糖，它依赖正确的分隔符切换、参数绑定方式和执行上下文。直接用 DELIMITER ; 后跟 CREATE PROCEDURE 会报错 —— 这是最常卡住新手的第一步。
为什么 CREATE PROCEDURE 总提示语法错误？
根本原因是 MySQL 默认以 ; 为语句结束符，而存储过程体内部必然包含多个 ;（比如 SET @x = 1;、SELECT ...;）。不改分隔符，MySQL 会在第一个分号就终止解析，把 BEGIN 后面的内容当成无效语句。
- 必须在
CREATE PROCEDURE前用DELIMITER //（或$$等）临时替换结束符 -
END //中的//是你新设的结束符，不是注释 - 定义完必须用
DELIMITER ;恢复默认，否则后续所有语句都会失效 - 常见错误：
DELIMITER//（没空格）、END;（漏了新结束符）、DELIMITER ;写成DELIMITER;（少空格）
IN / OUT / INOUT 参数怎么传值才有效？
存储过程不支持直接传字面量给 OUT 或 INOUT 参数。比如 CALL proc(123, @out) 合法，但 CALL proc(123, 456) 会报错 —— 因为 456 是常量，无法接收返回值。
-
IN参数：可传变量或字面量，如CALL p1(100)或CALL p1(@id) -
OUT参数：必须传用户变量（以@开头），如CALL p1(@result)，之后用SELECT @result取值 -
INOUT参数：同样必须是用户变量，调用前需先赋值，过程内可读可写 - 容易忽略：
OUT变量在调用前无需初始化，但调用后若未被赋值，结果为NULL
存储过程里怎么调试中间结果？
MySQL 没有断点调试器，SELECT 是最直接的调试手段，但它会改变输出结构 —— 如果过程本该只返回一个结果集，加了调试 SELECT 就会多出额外结果集，应用层可能解析失败。
- 开发阶段：在关键位置插入
SELECT 'debug step 1', @var1, @var2;查看变量状态 - 上线前务必删掉或注释掉所有调试
SELECT，否则影响调用方逻辑 - 替代方案：用
INSERT INTO debug_log记日志表（需提前建表），比SELECT更隐蔽 - 注意：
SHOW PROCEDURE STATUS只显示元信息，不反映运行时变量值
事务控制和错误处理容易被绕过的坑
存储过程默认不开启事务，START TRANSACTION 和 COMMIT/ROLLBACK 必须显式写，且不能依赖外部事务自动传播 —— 应用层开启的事务，进不到存储过程里。
- 多语句操作（如扣库存+写订单）必须手动加
START TRANSACTION，否则某条失败会导致数据不一致 -
DECLARE EXIT HANDLER FOR SQLEXCEPTION是唯一可靠的错误捕获方式，IF @@error_count > 0无效 - 不要假设
autocommit=1下的单条语句“天然原子”，存储过程中多条语句仍需包裹事务 - 游标循环中出错时，
ROLLBACK会回滚整个事务，不只是当前循环迭代
真正难的不是写出能跑的存储过程，而是让它的行为在高并发、异常中断、跨会话调用下依然可预期 —— 分隔符、变量作用域、事务边界、错误传播路径，每一处都得亲手验证，不能靠“应该没问题”蒙混过关。
