STRING_SPLIT在SQL Server 2016+中必须清洗再用：输入' 123,, 456 , '会拆出含空格、空串的四行，须用TRIM和WHERE过滤；2016–2019版需ROW_NUMBER()保序；禁止在WHERE中直接嵌套调用，应先存临时表并建索引。
STRING_SPLIT 在 SQL Server 2016+ 中必须清洗再用
直接 SELECT value FROM STRING_SPLIT(@ids, ',') 拿来就插，大概率出错——空串、首尾空格、顺序错乱全都会进表。尤其当输入是 ' 123,, 456 , ' 时，会拆出四行：' 123 '、''、''、' '。
正确做法是立刻清洗并落临时表：
SELECT TRIM(value) AS val INTO #split_ids FROM STRING_SPLIT(@ids, ',') WHERE TRIM(value) != '';
这一步不能省，否则后续 CAST(val AS INT) 会直接报 Conversion failed。
SQL Server 2016–2019 必须显式编号保序
STRING_SPLIT 在这些版本里不保证返回顺序，哪怕你传入 'a,b,c'，查询结果也可能是 c,a,b。如果后续逻辑依赖“第2个值是部门ID”，不加序号等于写了个定时 bug。
别用 ORDER BY value，那是按字母排，不是按原始位置排。稳妥写法是：
SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS rn, TRIM(value) AS val INTO #split_with_order FROM STRING_SPLIT(@ids, ',') WHERE TRIM(value) != '';
注意：(SELECT NULL) 是占位写法，SQL Server 2016–2019 就靠它维持输入顺序；并发场景下仍建议先存临时表再编号，比在子查询里套 ROW_NUMBER() 更稳。
千万别在 WHERE 中嵌套 STRING_SPLIT 做 IN 过滤
写成 WHERE id IN (SELECT value FROM STRING_SPLIT(@ids, ',')) 看似简洁，实际执行计划常退化为 Nested Loop + 表扫描，@ids 超过 50 个值时性能断崖下跌。
真正可落地的替代方案只有两个：
- 先把拆分结果存进带索引的临时表：
CREATE INDEX IX_val ON #split_ids(val)，再用JOIN或EXISTS - 更优解：让应用层改用表值参数（TVP），服务端能走索引查找，彻底绕开字符串解析开销
老系统若无法改调用方式，至少把 STRING_SPLIT 的结果物化到临时表，别让它活在子查询里反复计算。
SQL Server 2008/2012 只能手写 CHARINDEX 循环，边界必须双检
WHILE + CHARINDEX 不是不能用，但漏掉任一边界检查就会丢数据或插空串。常见坑点：
- 循环前没判断
@m = CHARINDEX(',', @str)是否 > 0，导致整个循环跳过 - 截末段时没补
SUBSTRING(@str, @n, LEN(@str) - @n + 1)，最后一条永远丢 - 插入前没
IF LEN(@id) > 0，空字符串污染下游逻辑
示例关键片段：
SET @n = 1;
SET @m = CHARINDEX(',', @str);
WHILE @m > 0
BEGIN
SET @id = LTRIM(RTRIM(SUBSTRING(@str, @n, @m - @n)));
IF LEN(@id) > 0 INSERT INTO #result(id) VALUES (@id);
SET @n = @m + 1;
SET @m = CHARINDEX(',', @str, @n);
END;
-- 补最后一段
IF @n 0 INSERT INTO #result(id) VALUES (@id);
END;
顺序和空值处理，在任何版本里都不是“顺手加上”的事，而是每一步都得盯住的硬约束。
