是，存储过程调用失败可能由max_allowed_packet引发，但仅当其内部DML操作（如动态SQL拼接、大字段SELECT INTO、JSON拼接等）生成超长语句或数据包时；过程本身不走网络传输，不直接受限。
存储过程调用失败，真是max_allowed_packet惹的祸？
不是所有“调用失败”都该怪max_allowed_packet。存储过程本身不直接受该参数限制——它不走网络包传输，而是服务端内存内执行。真正触发Packets larger than max_allowed_packet are not allowed错误的，往往是过程里隐含的DML操作：比如INSERT INTO ... SELECT从大表拉数据、UPDATE中用JSON_SET()拼接超长JSON字段、或SELECT ... INTO OUTFILE生成大结果集。先确认错误是否真出现在过程体内部，而不是调用语句（如CALL proc_name()）本身。
为什么CALL语句会报“packet too large”？
因为CALL不是原子黑盒——MySQL会把整个过程定义（含嵌套SQL、变量赋值、临时结果组装）在解析和执行阶段反复拆解、缓存、拼接。以下场景极易突破max_allowed_packet：
- 过程里用
CONCAT()或GROUP_CONCAT()拼出超长字符串，再作为参数传给PREPARE动态SQL -
SELECT ... INTO @var加载了数MB的TEXT/BLOB字段，后续又被用于构建INSERT语句 - 过程内执行
INSERT INTO t VALUES (...)，其中某行VALUES列表展开后字节远超当前@@session.max_allowed_packet - 过程调用链深（A→B→C），每层都累积字符串变量，最终在某次SQL拼接时爆包
怎么查清到底是哪一行SQL卡住的？
别只看错误日志里的“packet too large”，要定位到具体语句：
- 在过程开头加
SELECT CONCAT('DEBUG: ', LENGTH(@debug_str)) AS packet_size;，对关键拼接变量做长度快照 - 把过程里所有动态SQL（
SET @sql = ...）后面立刻跟一句SELECT LENGTH(@sql) AS sql_len; - 在报错位置前插入
SELECT @@session.max_allowed_packet AS current_limit;，确认会话值没被ORM或连接池悄悄覆盖 - 用
OCTET_LENGTH()而非LENGTH()算字节数（尤其含中文/emoji时），避免字符集误导
如果发现某条@sql长度是820万字节，而@@session.max_allowed_packet返回4194304（即4MB），那就坐实了。
改配置前，先砍掉冗余拼接逻辑
盲目调大max_allowed_packet可能掩盖更严重的设计问题，且有OOM风险：
- 把
GROUP_CONCAT()换成游标分批处理，避免单次拼出上百万字符 - 用
JSON_ARRAY_APPEND()替代反复CONCAT(JSON_EXTRACT(...), ...)，减少中间字符串复制 - 大结果集不要
SELECT ... INTO @var，改用临时表+主键分页处理 - 检查过程是否在循环里不断
SET @str = CONCAT(@str, ...)——这会指数级吃内存，应改用INSERT INTO tmp VALUES (...)
真正难缠的从来不是配置数字，而是那些在sp_head::main_mem_root里赖着不走的拼接副本——它们既推高内存，又悄悄撑爆packet边界。
