MySQL存储过程无法流式处理BLOB，必须整块加载至内存；应由客户端通过PreparedStatement等API实现分块读写，或垂直拆分BLOB至独立表、移至对象存储。
存储过程里读写BLOB会强制加载整块数据到内存
MySQL 存储过程执行时，所有变量都在 server 端内存中分配。一旦你用 SELECT content INTO @blob_var FROM t WHERE id = 1 把一个 LONGBLOB 字段读进用户变量，InnoDB 就必须把整个溢出页链加载进 buffer pool——哪怕你后续只取前 100 字节。这会瞬间挤占缓存、触发大量 innodb_buffer_pool_reads，且无法被其他连接复用。
常见错误现象：SHOW PROCESSLIST 显示状态为 Copying to tmp table 或 Sending data；SHOW ENGINE INNODB STATUS 中看到 Buffer pool hit rate 从 99% 直降到 70% 以下。
- 别在存储过程中做
SELECT * INTO—— 即使目标变量是DECLARE blob_var LONGBLOB，也会触发全量加载 - 如果只是要校验长度或哈希，改用
SELECT LENGTH(content), MD5(LEFT(content, 8192))，避免拉取全部内容 - 想在过程里修改 BLOB？优先用
UPDATE t SET content = ? WHERE id = ?直接传参，而不是先SELECT再拼接再UPDATE
存储过程调用期间无法释放 BLOB 占用的连接资源
MySQL 的用户变量生命周期绑定在连接上，而存储过程默认不自动清理大变量。一个含 5MB BLOB 的 @blob_var 在过程结束后仍驻留内存，直到该连接关闭或显式 SET @blob_var = NULL。高并发下，几十个连接同时持着几 MB 变量，max_allowed_packet 和 sort_buffer_size 都可能被撑爆，出现 2006 MySQL server has gone away 错误。
- 每次用完大变量后立刻执行
SET @blob_var = NULL，不要依赖“过程结束自动释放” - 避免在循环体里反复
SELECT ... INTO @blob_var—— 每次都会叠加内存占用，不是覆盖 - 如果必须批量处理，改用游标 +
FETCH+ 单次小字段读取，绕开 BLOB 列
存储过程无法规避 BLOB 引发的锁竞争和日志膨胀
存储过程本质还是 SQL 执行上下文，它调用 UPDATE 修改含 BLOB 的行时，依然触发 InnoDB 全量行锁 + redo log 记录整个 off-page 块。哪怕过程里只改了 title 字段，只要语句包含 BLOB 列（如 UPDATE t SET title = ?, content = content WHERE id = ?），就会重写整个 BLOB 数据页，导致 innodb_log_writes 暴增、检查点频繁触发。
- 元数据更新和内容更新必须拆成两个独立语句：一个不含 BLOB 列，一个只更新 BLOB 列（且仅当内容真有变化）
- 别在存储过程里写
IF old_content != new_content THEN UPDATE ...—— MySQL 不支持 BLOB 直接比较，!=会隐式转成全量字节比对，更慢 - 对审计类强事务场景，用
COMPRESS()写入前压缩，并确保字段类型是MEDIUMBLOB，避免截断后UNCOMPRESS()返回NULL
真正该做的不是优化存储过程，而是绕开它
存储过程不是 BLOB 问题的解法，而是放大器。它把原本可由应用层控制的加载粒度、内存生命周期、事务边界，全交给了 MySQL server 端——而 server 对大二进制数据没有任何流式处理或分块能力。
最常被忽略的一点：哪怕你把存储过程写得再精巧，只要表结构里还留着 content LONGBLOB，所有客户端（包括应用、备份工具、监控脚本）都可能在不经意间触发全量加载。真正的瓶颈不在代码逻辑，而在那张表的设计本身。
