真正可持续的做法是用结构化参数替代扁平参数列表，因XML/JSON可规避2100参数限制、防止SQL注入、支持强类型校验与高效解析，且需严格校验格式并防御空值。
SQL Server 存储过程参数超 2100 个时，不是“加个参数”或“拆成多个调用”就能解决的——那是把维护负担从数据库推给了应用层，反而放大耦合和出错面。真正可持续的做法是用结构化参数替代扁平参数列表。
为什么 XML/JSON 传参比拼接字符串或拆批更可靠
直接拼接 SQL 字符串（如 EXEC('SELECT * FROM t WHERE id IN (' + @ids + ')')）会绕过参数化机制，触发 SQL 注入风险，且执行计划无法复用；而按 1000 个一批拆调用，意味着应用层要写重试、事务边界、结果合并逻辑，错误定位也分散在 N 次调用里。
XML 或 JSON 是 SQL Server 原生支持的结构化类型，它们：
- 在协议层只占 1 个参数槽位，彻底避开 2100 限制
- 支持强类型解析（如
CAST(@data AS XML)或ISJSON(@data) = 1），校验失败可立刻报错，不等到JSON_VALUE才崩 - 允许在存储过程中用
.nodes()或OPENJSON()展开为临时结果集，后续可 JOIN、WHERE、GROUP BY，语义清晰
SQL Server 中用 XML 传参的实际写法
客户端把数组转成 XML 后，作为单个 @payload 参数传入。存储过程内必须做三件事：校验格式、提取数据、防空处理。
示例片段：
CREATE PROCEDURE usp_process_orders
@payload XML
AS
BEGIN
IF @payload IS NULL OR NOT @payload.exist('/root') = 1
THROW 50001, 'Invalid XML payload: missing root', 1;
<p>-- 提取到临时表，避免多次 .nodes() 调用开销
SELECT
T.c.value('(OrderId)[1]', 'CHAR(16)') AS order_id,
T.c.value('(Status)[1]', 'CHAR(2)') AS status
INTO #orders
FROM @payload.nodes('/root/Order') AS T(c);</p><p>-- 后续逻辑直接查 #orders，可建索引、统计、关联主表
SELECT o.*, c.customer_name
FROM #orders o
JOIN customers c ON c.order_id = o.order_id;
END注意：.value() 的第二个参数必须明确指定长度（如 'CHAR(16)'），否则默认为 VARCHAR(50)，可能截断或隐式转换失败。
SQL Server 2016+ 推荐优先用 JSON
JSON 比 XML 更轻量、可读性更好，且 OPENJSON() 支持 Schema 映射，无需手写 XPath 表达式。
关键实操点：
- 传入前务必用
ISJSON(@json) = 1校验，否则OPENJSON()报错堆栈不带参数名，难定位源头 - 用
WITH子句显式声明字段类型和路径，例如：status CHAR(2) '$.status'，避免返回NVARCHAR(MAX)引发隐式转换 - 不要依赖
SELECT * FROM OPENJSON(@json)——它返回键值对，丢失结构语义，后续 WHERE 条件得写WHERE [key] = 'status' AND value = 'SH'，可读性差且性能低
错误示例：SELECT * FROM OPENJSON(@json) WHERE value = 'SH'；正确写法：SELECT status FROM OPENJSON(@json) WITH (status CHAR(2)) WHERE status = 'SH'。
容易被忽略的兼容性与性能陷阱
XML 在所有 SQL Server 版本都可用，但 .exist() 和 .nodes() 在大数据量下解析开销明显；JSON 仅限 SQL Server 2016 及以上，且 OPENJSON() 默认不走内存优化，大 payload（>1MB）建议先存入 #temp 表再处理。
更隐蔽的问题是类型契约断裂：
- 客户端传
"status": "sh"（小写），而数据库期望'SH'，函数里不做UPPER()就匹配失败——这不该由存储过程兜底，应在 JSON Schema 层或应用层标准化 - XML 中用
<Item>123</Item>表示 ID，但某次误传成<ItemId>123</ItemId>，.value('(ItemId)[1]')返回 NULL，若没判空就直接 INSERT，会导致脏数据
所以，无论选 XML 还是 JSON，第一行必须是校验，最后一行必须有空值防御——结构化不等于免检，它只是把校验点从“每个参数”收敛到了“一个载荷”。
