MySQL存储过程适合封装多步数据库操作，但不适合替代应用层逻辑；它在事务边界清晰、高频重复调用且不依赖外部服务的场景下才真正有用。
MySQL存储过程适合封装多步数据库操作，但不适合替代应用层逻辑；它在事务边界清晰、高频重复调用且不依赖外部服务的场景下才真正有用。
什么时候该写存储过程而不是在应用里拼SQL？
判断依据不是“逻辑复杂”，而是数据流转是否完全闭环于数据库内：
- 需要跨多张表更新+校验+日志写入，且所有表都在同一实例中
- 定时任务（如每日结算）要求强一致性，不能容忍应用中途崩溃导致状态不一致
- 多个应用（PHP/Java/Python）共用同一套核心规则，且规则变更频率低、DBA可控
- 网络延迟敏感（比如高频小额记账），避免多次往返传输中间结果
反例：涉及HTTP调用、文件读写、加密解密、或需访问其他数据库实例的操作——这些强行塞进存储过程只会让调试和监控变得不可控。
DECLARE变量声明和INTO赋值的常见陷阱
MySQL存储过程中变量作用域和赋值行为与多数语言不同，容易引发静默错误：
-
DECLARE必须在BEGIN后立即声明，且不能在IF/LOOP块内重复声明同名变量 -
SELECT ... INTO遇到0行返回时，目标变量会被设为NULL，而非保持原值——这常导致后续WHERE col = @var永远不匹配 - 未初始化的
INT变量默认为NULL，参与算术运算（如SET @sum = @sum + 1）结果仍是NULL - 字符串比较注意
COLLATION：若表字段是utf8mb4_0900_as_cs而变量未显式声明字符集，=可能意外失败
建议始终显式初始化：DECLARE v_total DECIMAL(10,2) DEFAULT 0.00;
用START TRANSACTION包裹存储过程体的风险
存储过程本身不开启事务，START TRANSACTION必须由调用方控制，否则会破坏上层事务一致性：
- 如果存储过程内部执行
START TRANSACTION，而调用它的应用代码也开启了事务，会导致嵌套事务（MySQL不支持）或隐式提交 -
COMMIT或ROLLBACK在存储过程中应仅用于自治事务（autonomous transaction）场景，且必须配合SAVEPOINT和异常处理器 - 更安全的做法是：存储过程只做DML，由应用层统一控制事务边界；必要时用
DECLARE EXIT HANDLER FOR SQLEXCEPTION做局部回滚并抛出错误
例如：DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END; —— 这样既清理了当前上下文，又把错误透传给调用方。
INOUT参数和游标性能的真实代价
游标（DECLARE cursor_name CURSOR FOR SELECT...）在MySQL中是逐行提取，没有批量优化，容易成为性能瓶颈：
- 每
FETCH一次触发一次查询执行计划解析，10万行循环可能比单条UPDATE ... JOIN慢两个数量级 -
INOUT参数传递大文本或JSON时，实际是复制值而非引用，对内存和CPU都有额外开销 - 若业务逻辑能改写为集合操作（如用
INSERT ... SELECT替代循环INSERT），优先这么做 - 真需游标时，务必加
WHERE条件缩小结果集，并在OPEN前用SELECT COUNT(*)预判规模，超阈值直接SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Too many rows';
复杂业务逻辑的边界往往不在“能不能写进存储过程”，而在于“有没有必要让它承担状态协调责任”——多数时候，把校验和组装留在应用层，只让存储过程干好原子更新这一件事，反而更稳。
