存储过程本身不提升并发，反而易成瓶颈；需通过缩小锁范围、控制事务粒度和优化执行路径来提升并发能力。
存储过程本身不提升并发，反而容易成为并发瓶颈；真正能提高并发处理能力的，是控制它内部的锁范围、事务粒度和执行路径。
为什么存储过程在高并发下容易卡住
MySQL 存储过程不是“并发友好型”结构——它默认逐语句自动提交（autocommit=1），每条 DML 都是独立小事务；若显式加了 BEGIN/COMMIT，又可能因逻辑过长导致行锁/间隙锁长时间持有。常见卡点包括：
- 游标循环中反复执行
SELECT ... FOR UPDATE或UPDATE，锁逐行累积，其他事务排队等待 - 一个存储过程里包含跨多张表的更新+插入+日志写入，事务边界模糊，锁范围不可控
- 在
REPEATABLE READ隔离级别下做范围查询（如WHERE status = 'pending' AND created_at > NOW() - INTERVAL 1 HOUR），触发间隙锁，阻塞 INSERT
用显式短事务替代隐式长事务
默认 autocommit=1 时，每个语句单独提交，看似“轻”，实则频繁获取/释放锁，反而放大争用。更优做法是：人工划定最小必要事务边界，并确保它足够短。
- 把“查→改→记日志→发通知”这种全链路逻辑拆开：只把“查+改”包进一个
BEGIN/COMMIT，日志和通知挪到应用层异步处理 - 避免在事务中调用
SLEEP()、外部 HTTP 请求或复杂计算——这些会无谓延长锁持有时间 - 对批量操作，按主键 ID 分片提交，例如每次处理 100 行：
WHERE id BETWEEN ? AND ?，而不是一次扫全表
用集合操作代替游标 + 单行处理
游标（DECLARE CURSOR）本质是单线程迭代器，在 MySQL 中无法并行，且在 RR 隔离级别下极易引发间隙锁。只要能用一条 SQL 完成，就别写循环。
- 要给一批用户发状态变更通知？别用游标逐个
UPDATE users SET status = 'active' WHERE id = cur_id，改用：UPDATE users SET status = 'active' WHERE id IN (SELECT id FROM temp_batch) - 要汇总订单并更新用户积分？用
INSERT INTO user_points SELECT user_id, SUM(points) FROM orders ... GROUP BY user_id ON DUPLICATE KEY UPDATE total = total + VALUES(total)，而非先查再循环累加 - 必须用中间结果？优先建带索引的临时表（
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY) ENGINE=MEMORY），别依赖未索引的磁盘临时表
隔离级别与锁行为必须匹配业务容忍度
存储过程跑在什么隔离级别，直接决定它拿什么锁、锁多久。默认 REPEATABLE READ 对并发最不友好。
- 如果该存储过程只做读+写，且业务允许“不可重复读”（比如后台定时任务刷新统计），就在开头加：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED，关闭间隙锁 - 若涉及唯一约束校验（如防重下单），
READ COMMITTED下仍能靠唯一索引保证一致性，不必死守 RR - 千万别在存储过程中动态切换隔离级别后不恢复——会影响后续语句，也难审计
真正难的是判断“哪段逻辑必须锁、锁多久、能不能拆”。很多所谓“高并发优化”，最后都落在：把原本塞进存储过程里的业务规则，移回应用层做轻量判断，只让存储过程干最原子、最可控的一件事——比如“扣库存并记录流水”。否则，越想用存储过程“封装并发”，越容易把它变成锁的放大器。
