如何减少网络交互带来的性能损耗_存储过程封装与批量操作

批量插入应避免单条语句多次网络往返，须用多值 INSERT、表值参数或原生数组传参，在数据库端一次性展开写入，而非存储过程中循环执行 INSERT。

存储过程里怎么批量插入而不触发 N 次网络往返

单条 INSERT 语句执行一次，客户端就发一次请求——哪怕你循环 100 次，就是 100 次 round-trip。数据库端可能只花 2ms，但网络延迟（尤其跨机房）动辄 10–50ms，瓶颈根本不在 SQL 本身。

真正有效的做法是把多行数据打包进一条语句，或者用存储过程内部循环处理。关键不是“写个存储过程”，而是让数据别出数据库边界。

• 用 INSERT INTO …… VALUES (……), (……), (……) 一次性插多行（注意 MySQL 有 max_allowed_packet 限制，PostgreSQL 无硬上限但要注意事务大小）
• 在存储过程中接收数组或 JSON 字符串（如 PostgreSQL 的 jsonb、SQL Server 的 STRING_SPLIT 或表值参数），再用 UNNEST / CROSS APPLY 展开后批量写入
• 避免在存储过程里写 FOR i IN 1..n LOOP INSERT …… 这种循环——它只是把 100 次网络往返，换成 100 次内部执行，没减少 I/O，还加重了锁竞争

SQL Server 表值参数（TVP）传大批量数据时卡住怎么办

表值参数本意是高效传结构化数据，但实际用起来常卡在客户端序列化或服务端内存分配上，尤其当传几万行、每行字段又多的时候。

问题往往不出在语法，而在两处：客户端构造 TVP 的方式，和服务端是否启用了 SET ARITHABORT ON（某些 ORM 或连接池默认关掉它，导致执行计划缓存失效，反复编译）。

• 客户端侧：用 DataTable 构造 TVP 时，别一行行 Rows.Add()，改用 Load() 配合 SqlDataReader 或数组批量填充，快 3–5 倍
• 服务端侧：确保连接字符串包含 Packet Size=8192（默认够用），且存储过程中第一行加 SET ARITHABORT ON
• 别把 TVP 当通用容器：字段类型必须和用户定义表类型（UDT）严格一致，比如 UDT 定义的是 INT，传 NULL 或 smallint 都可能隐式转换失败，报错信息是 The table-valued parameter "@data" must be declared with a user-defined table type.

MySQL 存储过程里用游标遍历大结果集为什么越来越慢

游标本质是逐行提取 + 逐行处理，底层会维持临时结果集快照，数据量一过万，内存占用飙升，还会阻塞源表的 DML 操作。更麻烦的是，MySQL 游标不支持动态 SQL 绑定，没法提前预编译，每次 fetch 都带解析开销。

除非业务逻辑真需要“逐行判断后决定下一行怎么查”，否则游标是最后的选择。

• 优先用 JOIN + UPDATE …… SELECT 替代“查出来再更新”：比如要给一批用户加积分，直接 UPDATE users u JOIN temp_batch b ON u.id = b.user_id SET u.score = u.score + b.points
• 真要过程式逻辑，把数据导出到临时表（CREATE TEMPORARY TABLE …… SELECT ……），再对临时表做多次聚合 / 更新，比游标快一个数量级
• 如果非用游标不可，务必在声明前加 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE，不然遇到空结果会直接报错中断，而不是安静退出

PostgreSQL 中用 jsonb 传参进存储过程，解析后性能反而下降

jsonb 灵活，但解析成本真实存在。一个含 5000 条记录的 JSON 数组，用 jsonb_array_elements() 展开，比原生数组慢 2–4 倍；若再嵌套对象、还要取多层字段，CPU 就明显吃紧。

这不是 JSON 本身的问题，而是 PostgreSQL 对 JSON 路径解析未做向量化优化，每次调用都是独立解析。

• 能用原生数组就别用 JSON：比如传整数 ID 列表，用 INT[] 类型参数，配合 UNNEST($1)，比 jsonb_array_elements($1::jsonb) 快得多
• 如果前端只能发 JSON，至少在存储过程开头用 jsonb_populate_recordset(NULL::my_table_type, $1) 一次性转成记录集，别在循环里反复调用 ->> 取字段
• 注意 jsonb 字段名大小写敏感，而 PostgreSQL 列名默认小写——data->>'UserId' 和 data->>'userid' 是不同路径，容易漏数据

批量操作的核心从来不是“怎么写存储过程”，而是“数据在哪次被组织、在哪次被拆解”。网络损耗藏在看不见的序列化、参数绑定、执行计划选择里，而不是那行 CALL proc(……) 上。多看执行计划里的 Planning Time 和 Execution Time 分布，比猛写循环实在得多。