高并发下存储过程应避免SELECT...INTO、DECLARE CONTINUE HANDLER包裹大逻辑、游标遍历及未声明参数方向；推荐子查询赋值、临时表、显式异常处理、集合操作和明确参数修饰。
存储过程里别用 SELECT ... INTO 做中间赋值
高并发下，SELECT ... INTO 会隐式加表级锁（尤其在 READ-COMMITTED 以下隔离级别），且无法利用查询缓存。更糟的是，它强制 MySQL 执行完整结果集扫描再赋值，哪怕只取一行。
实操建议：
- 改用
SET @var = (SELECT col FROM t WHERE pk = ? LIMIT 1)—— 子查询带LIMIT 1可提前终止，优化器也更可能走索引 - 若需多字段赋值，优先用临时表
CREATE TEMPORARY TABLE tmp AS SELECT ...，再从临时表读，避免反复扫描原表 - 确认
sql_mode中不含STRICT_TRANS_TABLES时，SELECT ... INTO遇空结果会报错，而子查询赋值返回NULL更可控
DECLARE CONTINUE HANDLER 别包整个业务逻辑块
把大段 SQL 包进 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 里，会导致事务上下文被污染：MySQL 在异常发生后不会自动回滚已执行语句，但后续语句仍可能继续执行，造成数据不一致。
实操建议：
- 只在真正需要捕获并处理的原子操作周围加 handler，比如单条
INSERT IGNORE或UPDATE ... ON DUPLICATE KEY UPDATE - 高并发写场景下，优先用应用层重试 + 幂等 key，而非靠存储过程兜底
- 若必须用 handler，结尾务必显式
ROLLBACK或LEAVE，避免“静默失败后继续往下跑”
游标（DECLARE CURSOR）在并发下极易成为性能瓶颈
MySQL 游标本质是单行遍历 + 每次 fetch 触发一次内部查询，无批量能力；且游标打开期间会持有表/行锁（取决于隔离级别和访问模式），并发一上来就排队堵死。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
实操建议：
- 能用集合操作替代的，一律不用游标：比如用
INSERT ... SELECT替代循环INSERT，用UPDATE t1 JOIN t2替代逐行更新 - 真要遍历，先
CREATE TEMPORARY TABLE缓存 ID 列表，再用JOIN批量处理，比游标快 5–20 倍（视数据量） - 避免在游标循环内调用其他存储过程或触发器，嵌套开销呈指数增长
参数传入没加 IN/OUT 明确修饰，引发隐式拷贝与类型转换
MySQL 存储过程中未声明参数方向（如 CREATE PROCEDURE p(p_id INT)），默认按 IN 处理，但某些客户端驱动会误判为 INOUT，导致参数值被复制进存储过程作用域再传出，额外消耗内存和 CPU。
实操建议：
- 所有参数必须显式标注
IN、OUT或INOUT，尤其是大数据类型（TEXT、JSON） - 避免用
JSON类型参数传复杂结构——解析开销大，且无法利用索引；改用多个IN参数或预建临时表 - 整数类参数统一用
INT SIGNED或BIGINT UNSIGNED，避免因隐式转换触发全表扫描（例如传字符串'123'匹配INT字段）
真正卡住高并发存储过程的，往往不是语法有多复杂，而是锁粒度、隐式类型转换、以及把关系型思维硬套到过程式代码里。上线前用 SHOW PROFILE 抓几个并发调用的耗时分布，重点看 Copying to tmp table 和 Waiting for table metadata lock 这两项——它们暴露的问题，比慢查询日志更直接。
