存储过程能减少重复SQL，前提是逻辑封装合理且数据库侧可闭环；例如用户积分更新与日志记录封装为原子操作，调用方仅传参数即可自动完成校验、更新、事务控制与错误处理。
能简化，但得看你怎么写——不加事务、不处理错误、硬编码表名的存储过程，反而会让线上问题更难排查。
存储过程真能减少重复SQL吗？
能，前提是逻辑封装合理。比如用户积分更新+日志记录这种固定组合，每次都在应用层写两段 SQL + 事务控制，就容易漏掉 rollback 或写错 WHERE 条件。用 CREATE PROCEDURE 把它包成一个原子操作，调用方只传 userId 和 pointsToAdd，底层自动做校验、更新、插入日志、提交或回滚。
- 重复逻辑必须是「数据库侧可闭环」的：不依赖外部 API、不涉及文件读写、不调用其他服务
- 别把本该在应用层做的参数校验（如手机号格式）塞进存储过程，徒增维护成本
- 如果业务规则常变（比如积分算法每月一调），优先考虑配置表+通用过程，而不是改 N 个
IF...ELSE
IN / OUT / INOUT 参数怎么选才不踩坑？
参数类型直接决定调用方式和调试难度。IN 最安全，OUT 必须配合用户变量使用，INOUT 容易引发意外交互。
-
CALL UpdateUserPointsAndLog(123, 50, @newTotal)中的@newTotal是会话级变量，不能在不同连接间共享 - 多个
OUT参数时，调用后必须用SELECT @var1, @var2一次性取值，分两次查可能拿到旧值 - 别用
INOUT去“偷懒传参”，例如把表名当INOUT字符串拼进 SQL —— 这属于动态 SQL，MySQL 不允许直接执行，得用PREPARE+EXECUTE，极易 SQL 注入
为什么加了事务还是出现数据不一致？
因为默认自动提交开着，或者没显式声明 DECLARE EXIT HANDLER。存储过程里 UPDATE 失败不会自动 rollback，除非你主动写。
- 开头加
START TRANSACTION，结尾配COMMIT，中间任何一步出错都得ROLLBACK - 用
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获错误，里面写ROLLBACK和日志记录 - 避免在事务中调用另一个未提交的存储过程——嵌套事务在 MySQL 里实际是保存点（savepoint），不是真正嵌套，容易误判一致性边界
- 注意
autocommit=1时，单条语句自带事务，但过程内多语句必须显式控制
去重、批量更新这类操作，存储过程比脚本强在哪？
强在原子性和权限收敛。比如按 email 去重，用临时表 + DELETE ... LEFT JOIN 封装成 RemoveDuplicateUsers()，DBA 只需授权这一个过程，不用开放 DROP TABLE 或 DELETE 全表权限。
- 过程内可加
SELECT COUNT(*)统计影响行数，再决定是否继续，避免一次删光生产数据 - 大表去重务必加
LIMIT分批，否则锁表时间过长；MySQL 8.0+ 支持窗口函数，可用ROW_NUMBER() OVER (PARTITION BY email ORDER BY id)替代临时表，更轻量 - 别在过程里写
TRUNCATE TABLE—— 它无法回滚，且会重置自增主键，跟业务预期常有偏差
最常被忽略的一点：存储过程没有版本管理。上线新逻辑前，得先 DROP PROCEDURE IF EXISTS，否则 CREATE 会报错；而旧过程一旦被删，正在运行的定时任务可能瞬间失败。上线节奏比应用代码更敏感。
