STRING_SPLIT不能直接在WHERE中嵌套使用，否则SQL Server 2016–2019会生成低效执行计划（Nested Loop+表扫描），@ids超50个值时性能断崖下跌；且若参数来自外部，易报“无法绑定多部分标识符”错误；必须用CROSS APPLY替代，并配合TRIM清洗、临时表编号保序（2016–2019）或启用ordinal参数（2022+），同时确保数据库兼容级别≥130。
STRING_SPLIT 不能直接在 WHERE 中当子查询用
写成 WHERE id IN (SELECT value FROM STRING_SPLIT(@ids, ',')) 看似简洁，但 SQL Server 2016–2019 会把它编译成 Nested Loop + 表扫描，@ids 超过 50 个值时性能断崖下跌。更糟的是，如果 @ids 来自外部参数（比如存储过程输入），还可能报错“无法绑定多部分标识符”。
必须用 CROSS APPLY 包一层，让它变成真正的表连接行为：
SELECT t.id, t.name FROM products t CROSS APPLY STRING_SPLIT(t.tags, ',') s WHERE TRIM(s.value) = 'urgent';
-
CROSS APPLY让每行的字符串被独立拆分，上下文清晰 - 不支持
OUTER APPLY场景下空字符串返回 NULL——它只对非空输入生效 - 若字段本身可能为 NULL，得先加
WHERE t.tags IS NOT NULL，否则STRING_SPLIT(NULL, ',')返回空结果集，CROSS APPLY会把整行过滤掉
拆出来全是空格和空串？必须立刻清洗
输入是 ' 123,, 456 , '，STRING_SPLIT 会吐出四行：' 123 '、''、''、' '。后续 CAST(val AS INT) 直接报 Conversion failed。
清洗不能省，且必须在物化前完成：
SELECT TRIM(value) AS val INTO #split_ids FROM STRING_SPLIT(@ids, ',') WHERE TRIM(value) != '';
-
TRIM()是 SQL Server 2016+ 的函数，兼容性好；LEN(TRIM(value)) > 0效果一样，但多一次计算 - 别用
WHERE value != ''——它放过带空格的字符串，比如' ' - 清洗后务必建索引：
CREATE INDEX IX_val ON #split_ids(val)，JOIN 或 EXISTS 才能走查找
顺序乱了怎么办？2016–2019 版本没 enable_ordinal
哪怕你传入 'a,b,c'，STRING_SPLIT 在 SQL Server 2016–2019 中也不保证返回顺序。依赖“第 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()，并发场景下可能错乱；先落临时表再编号更稳 - SQL Server 2022+ 可直接用
STRING_SPLIT(@ids, ',', 1)，返回value和ordinal两列，不用额外编号
数据库兼容级别低于 130？STRING_SPLIT 就不存在
执行 SELECT * FROM STRING_SPLIT('a,b', ',') 报错 对象名 'STRING_SPLIT' 无效，大概率是数据库兼容级别太低。
检查当前级别：
SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME();
- 必须 ≥ 130（对应 SQL Server 2016）；120 或更低版本查不到这个函数
- 改级别命令：
ALTER DATABASE [YourDB] SET COMPATIBILITY_LEVEL = 130; - 若无法改级别（比如老系统受限），只能退回到递归 CTE 或自定义拆分函数——
CHARINDEX循环必须双检边界，漏掉@m > 0判断或末段SUBSTRING补全，就会丢数据
实际用的时候，最常被跳过的就是清洗和保序两步。很多人看到 STRING_SPLIT 返回了“看起来像”的结果，就直接拿去 JOIN 或 CAST，结果上线后空串报错、顺序错乱、性能崩盘——这些都不是函数的问题，而是没处理它默认输出的“原始态”。
