存储过程频繁执行无INTO的SELECT会显著拖慢速度，因需返回结果集、触发网络传输、增加内存与上下文开销；应改用INTO、临时表或集合操作替代。
存储过程里频繁调用 SELECT 却不加 INTO，会拖慢执行速度
MySQL 存储过程中，如果写了个 SELECT 语句但没用 INTO 把结果存到变量里，MySQL 就得把结果集返回给客户端——哪怕你根本不需要它。这不仅触发网络传输开销，还强制开启结果集缓冲，增加内存占用和上下文切换次数。
常见错误现象：CALL proc_name() 执行慢、SHOW PROCESSLIST 看到状态卡在 Sending data、并发一高就锁表或超时。
- 只查单值（如计数、ID）时，必须用
SELECT ... INTO @var或SELECT ... INTO var_name - 查多行或多列？优先改用临时表 +
INSERT ... SELECT，避免游标遍历 - 调试阶段加了
SELECT看中间值？上线前务必删掉或注释，它们不是“无害打印”
DECLARE CONTINUE HANDLER 捕获异常后没做清理，导致连接状态残留
存储过程里用游标或事务时，常靠 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 捕获错误。但 handler 里只写 SET done = 1 是不够的——游标没关闭、临时表没删、事务没回滚，下次调用可能直接报错或读到脏数据。
使用场景：循环处理订单、批量更新用户状态、ETL 类清洗逻辑。
- handler 中必须显式调用
CLOSE cursor_name（即使不确定是否已打开，加IF EXISTS判断更稳） - 涉及
CREATE TEMPORARY TABLE的，handler 里补上DROP TEMPORARY TABLE IF EXISTS tmp_xxx - 若在事务块内出错，handler 里要
ROLLBACK，且建议设autocommit = 0开头，避免隐式提交干扰
用 CONCAT 拼接 SQL 字符串再 PREPARE，性能不如静态 SQL
动态拼接 SQL 在存储过程中很常见，但每次 PREPARE + EXECUTE 都要走一次 SQL 解析、权限检查、执行计划生成，开销远高于普通语句。尤其当这个逻辑在循环里被反复调用，就成了性能黑洞。
参数差异：CONCAT('SELECT * FROM t WHERE id = ', in_id) 和直接写 SELECT * FROM t WHERE id = in_id，后者能复用执行计划，前者每次都是新语句。
- 能静态写的，绝不动态拼——比如 where 条件字段固定，就用
IF分支，而不是拼字符串 - 真需要动态表名/库名？考虑用 MySQL 8.0+ 的
sys.eval()（需启用），或提前建好视图替代 - 若必须
PREPARE，至少把DEALLOCATE PREPARE放在末尾，避免句柄堆积
游标遍历大结果集时没限制 FETCH 数量，内存和锁持续增长
MySQL 游标本质是服务端结果集缓存，OPEN 后就锁定相关行（可重复读下甚至锁范围），而 FETCH 每次只取一行，意味着锁和内存占用会持续整个遍历周期。几万行数据扫下来，可能拖垮整个实例。
性能影响：慢查询日志里出现长时 Waiting for table metadata lock、innodb_row_lock_time_avg 突增。
- 优先用
INSERT ... SELECT或UPDATE ... JOIN替代游标——集合操作比逐行快一个数量级 - 非用游标不可？加
LIMIT分批处理，例如每次SELECT ... LIMIT 1000 OFFSET n，配合循环控制 - 确保游标
DECLARE时加上READ ONLY和NO SQL属性，让优化器少做检查
最麻烦的不是语法写错，而是那些看起来“能跑通”的写法——比如带 SELECT 不 INTO、游标没关、动态 SQL 没缓存——它们在小数据量下毫无征兆，一到生产环境就成定时炸弹。
