sql server传“数组”推荐用表值参数（tvp）或string_split函数：tvp类型安全、性能好，需预定义type且只读；string_split轻量但仅限sql server 2016+，需显式类型转换且有性能与顺序限制。
SQL Server 本身不支持数组类型参数，但你可以用两种主流方式安全、高效地传入“数组”语义的数据：表值参数（TVP）和 STRING_SPLIT 函数。前者是官方推荐、类型安全、性能好；后者简单轻量，但只适用于字符串格式且需注意 SQL Server 版本兼容性。
用表值参数（TVP）传入结构化列表
这是最接近原生数组的方式，适合传入多列、多行、强类型数据（比如 ID + 名称 + 时间），且能被查询优化器正确估算执行计划。
-
CREATE TYPE必须提前在数据库中定义，不能在存储过程中动态创建 - 调用方（如 C#、Python）需构造对应类型的 DataTable 或 SqlParameter，并设置
SqlDbType.Structured - TVP 是只读的，存储过程内不能修改其内容（
INSERT/UPDATE/DELETE到 TVP 变量会报错） - 如果传空表，
SELECT * FROM @tvp返回零行，不会报错，但要注意后续逻辑是否容忍空输入
示例：定义一个整数列表类型并使用
CREATE TYPE IntList AS TABLE (Value INT);<br>GO<br>CREATE PROCEDURE GetUsersByIds @Ids IntList READONLY<br>AS<br>BEGIN<br> SELECT u.* FROM Users u<br> INNER JOIN @Ids i ON u.Id = i.Value;<br>END
用 STRING_SPLIT 处理逗号分隔字符串
适合简单场景（如传一串 ID 字符串），代码写起来快，但本质是字符串解析，有隐式转换风险，且依赖 SQL Server 2016+。
-
STRING_SPLIT返回的value列是NVARCHAR(4000)，必须显式CAST或CONVERT成目标类型，否则JOIN或WHERE IN可能因类型不匹配走不了索引 - 输入字符串末尾或中间带空格（如
'1, 2 ,3'）会导致转换失败，建议先TRIM每个value - 不保证返回顺序，
ORDER BY在STRING_SPLIT结果上无效；如需序号，得用ROW_NUMBER()重排 - 最大长度受限于
VARCHAR(MAX)，但实际拆分性能随字符串长度指数下降，超 500 个值时建议改用 TVP
安全用法示例：
CREATE PROCEDURE GetOrdersByCodes @codes VARCHAR(MAX)<br>AS<br>BEGIN<br> SELECT o.* FROM Orders o<br> INNER JOIN STRING_SPLIT(@codes, ',') s<br> ON o.Code = LTRIM(RTRIM(s.value))<br> WHERE ISNUMERIC(LTRIM(RTRIM(s.value))) = 1;<br>END
别踩字符串拼接 IN 的坑
直接把参数拼进 SQL 字符串再 EXEC（比如 'IN (' + @ids + ')'）看似省事，但属于严重安全隐患，且无法复用执行计划。
- 极易触发 SQL 注入——哪怕你“确定前端已校验”，只要某处漏掉
REPLACE(@s, '''', '''''')就可能崩 - 每次传不同长度的字符串，SQL Server 都当作新查询编译，缓存爆炸，CPU 升高
- 无法利用参数化查询的统计信息，优化器常误估行数，选错索引甚至走全表扫描
- SQL Server 不允许在
IN子句里直接用变量，WHERE id IN @ids语法非法
真正麻烦的不是“怎么传”，而是传完之后怎么查得又快又稳。TVP 和 STRING_SPLIT 看似只是传参手段差异，实则决定了后续 JOIN 性能、错误防御能力和长期可维护性。尤其当列表超过几十项时，类型安全与执行计划稳定性会立刻成为瓶颈点。
