不能直接用 STRING_SPLIT() 做 JOIN，因其是表值函数且受作用域限制，需用 CROSS APPLY 实现逐行调用；注意分隔符须为 CHAR(1)、2022+ 才支持 ordinal 序号、空值需显式过滤。
为什么不能直接用 STRING_SPLIT() 做 JOIN？
因为 STRING_SPLIT() 返回的是表值函数结果，但 SQL Server 不允许在 FROM 子句中直接对它做 JOIN（尤其当拆分字段来自左表且需逐行处理时），强行写 INNER JOIN STRING_SPLIT(...) 会报错“无法绑定多部分标识符”，本质是作用域和执行顺序问题。
这时候 CROSS APPLY 就成了唯一自然的解法：它让右表达式能“看到”左表每一行的值，并为每行独立调用一次 STRING_SPLIT()，返回的结果自动横向展开。
CROSS APPLY + STRING_SPLIT() 的标准写法
核心是把拆分逻辑放在 APPLY 右侧，左侧保留主表引用。注意两个关键点：分隔符必须是 CHAR(1) 类型，且 STRING_SPLIT() 默认不保证顺序（SQL Server 2022+ 才支持 ordinal 列）。
-
CROSS APPLY STRING_SPLIT(t.tags, ',')——t.tags是主表字段，逗号是分隔符，不能传变量或表达式（如',' + ''） - 若需去重或过滤空值，得在外层加
WHERE value != ''或NULLIF(value, '') IS NOT NULL - SQL Server 2016+ 才内置
STRING_SPLIT()；低版本需用递归 CTE 或自定义拆分函数
SELECT t.id, s.value AS tag FROM posts t CROSS APPLY STRING_SPLIT(t.tags, ',') s WHERE NULLIF(TRIM(s.value), '') IS NOT NULL;
拆分后还想带原始序号？小心 ordinal 缺失
SQL Server 2022 之前，STRING_SPLIT() 不返回位置信息，你无法知道 “java” 在 “java,python,go” 中排第几位。即使加 ORDER BY 也无意义——结果集本身无序。
如果业务强依赖顺序（比如解析带权重的标签、按位置映射字段），必须换方案：
- 升级到 SQL Server 2022+，改用
STRING_SPLIT(t.tags, ',', 1)（第三个参数开启ordinal） - 用
OPENJSON()模拟：先转成 JSON 数组'["' + REPLACE(t.tags, ',', '","') + '"]'，再OPENJSON()提取key（即索引） - 避免在 SQL 层处理顺序敏感逻辑，交给应用层更可控
性能陷阱：别在大表上无条件 CROSS APPLY
CROSS APPLY 是逐行执行的，如果左表有百万行，而 tags 字段平均含 5 个值，实际会产生 500 万行中间结果——这比简单 JOIN 开销高得多。
- 务必给
tags字段加WHERE过滤（比如只处理tags IS NOT NULL AND tags != ''） - 避免在
SELECT中对同一字段多次CROSS APPLY（如同时拆分tags和categories），应合并为一次拆分或用 CTE 预计算 - 如果只是查某一个 tag 是否存在，用
EXISTS (SELECT 1 FROM STRING_SPLIT(...) WHERE value = 'xxx')比CROSS APPLY更轻量
CROSS APPLY 的执行语义、STRING_SPLIT() 的版本差异、序号缺失、空值处理、以及隐式膨胀带来的性能抖动——这些点在真实查询里往往集中爆发。真正“优雅”的前提是清楚自己在哪一环妥协了。 
