string_split在存储过程中必须显式编号才可靠：sql server 2016–2019需用row_number() over(order by (select null))并过滤空值，2022+支持ordinal参数；须trim清洗、避免直接嵌套where中调用以防性能崩。
STRING_SPLIT 能用，但直接塞进存储过程里就出问题——顺序不可靠、空项不处理、嵌套调用性能崩，不是写完就能跑通的。
STRING_SPLIT 在存储过程中必须显式编号才敢用
SQL Server 2016–2019 的 STRING_SPLIT 返回结果无序，哪怕原始字符串是 'a,b,c'，查询结果可能返回 c,a,b。在存储过程中若依赖位置（比如和另一张表按序号 JOIN），不加序号等于埋雷。
- SQL Server 2022+：直接用
STRING_SPLIT(@str, ',', 1)，ordinal列自动带顺序 - SQL Server 2016–2019：必须包装一层
ROW_NUMBER()，且不能写ORDER BY value（那只是按值排序，不是按出现顺序） - 安全写法示例：
SELECT value, ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS pos FROM STRING_SPLIT(@input, ',') WHERE TRIM(value) != ''
注意：(SELECT NULL)是占位写法，真实场景建议先插入临时表再编号，否则并发下仍可能错序
连续分隔符和首尾空格会悄悄破坏逻辑
STRING_SPLIT 是纯机械切分：遇到 'a,,b' 会返回三行 —— 'a'、''、'b'；遇到 ' a , b ' 不会自动 TRIM，value 值就是带空格的字符串。这在 IN 子句或 JOIN 中极易导致意外匹配或漏数据。
- 过滤空值：加
WHERE TRIM(value) != '' - 统一清洗：用
TRIM(value)替换原value字段 - 特别注意：如果后续要转成数字（如
CAST(value AS INT)），空串或空格串会直接报错Conversion failed
在 WHERE 或 JOIN 中直接调用 STRING_SPLIT 是性能杀手
把 STRING_SPLIT 写在 WHERE id IN (SELECT value FROM STRING_SPLIT(@ids, ',')) 这类语句里，SQL Server 很难生成高效执行计划。函数不可内联，优化器无法下推谓词，常退化为嵌套循环 + 表扫描，尤其当 @ids 长度超过几十个值时，响应时间陡增。
- 推荐做法：先把拆分结果存入临时表，再建索引
SELECT TRIM(value) AS val INTO #split_ids FROM STRING_SPLIT(@ids, ',') WHERE TRIM(value) != ''; CREATE INDEX IX_val ON #split_ids(val);
- 更优方案：应用层改用表值参数（TVP），服务端可走索引查找，避免字符串拼接和重复拆分
- 绝对避免：在大表的
WHERE条件中反复调用STRING_SPLIT，尤其是作为子查询嵌套在循环逻辑里
真正麻烦的从来不是“怎么拆”，而是拆完之后怎么保证顺序、怎么防空、怎么不拖慢整条查询链路——这些细节在存储过程里一旦漏掉，上线后很难排查。
