CROSS APPLY + STRING_SPLIT 是 SQL Server 中一行变多行最直接有效的方法，但需正确使用结构、过滤、顺序和空值处理；STRING_SPLIT 返回表而非标量，故不能直接用于 WHERE 或 SELECT 子句；必须配合 CROSS APPLY 并加别名；SQL Server 2022+ 支持 ordinal 参数保证顺序；需 TRIM 和 NULLIF 防空格与空值；性能瓶颈在于嵌套循环，应避免无索引全表扫描；不支持多字符分隔符。
CROSS APPLY + STRING_SPLIT 是 SQL Server 里处理“一行变多行”最直接有效的组合，但必须写对结构、加好过滤、注意顺序和空值，否则结果错位或丢失。
为什么不能直接在 WHERE 或 SELECT 里用 STRING_SPLIT？
STRING_SPLIT 返回的是表（不是单个值），而 WHERE col IN (...) 和 SELECT (subquery) 都只接受标量。常见错误写法：WHERE tag IN (SELECT value FROM STRING_SPLIT(t.tags, ','))——语法虽通，但一旦 t.tags 来自左表字段（比如 products.tags），就会报错“无法绑定多部分标识符”。因为子查询无法引用外部查询的列。
真正能动态传入左表字段的，只有 CROSS APPLY 或 OUTER APPLY。
无序列表呈现关键点：
-
STRING_SPLIT必须放在CROSS APPLY右侧，且必须带别名（如AS s） - 右侧不能是裸子查询，必须是可被当作“临时表”的表达式（函数调用、带
SELECT的括号表达式等） - 漏掉
AS别名会触发Incorrect syntax near '('
如何正确拆分并保留原始顺序？
默认 STRING_SPLIT 不保证顺序，'a,b,c' 可能返回 c/a/b。SQL Server 2022+ 支持第三个参数 enable_ordinal = 1，启用后返回 ordinal 列，按原始位置编号。
示例写法：
SELECT t.id, t.name, s.value FROM products t CROSS APPLY STRING_SPLIT(t.tags, ',', 1) AS s ORDER BY t.id, s.ordinal;
注意：ORDER BY s.ordinal 必须显式写，否则排序无效；若用的是 SQL Server 2016–2019，没 ordinal，只能靠业务逻辑补救（比如提前存好索引位）。
无序列表呈现关键点：
- 不加第三个参数时，
STRING_SPLIT结果完全无序，ORDER BY s.value没意义 - 启用
ordinal后，必须在ORDER BY中引用它，才能还原原始位置 - 旧版本 SQL Server 若需顺序，得改用数字辅助表 +
SUBSTRING+CHARINDEX手动拆，复杂度高
空格、空值、多分隔符怎么处理？
STRING_SPLIT 对空格零容忍：输入 ' urgent ,high ,low '，不 TRIM 就匹配不到 'urgent'；遇到连续分隔符如 'a,,b'，会返回空字符串行；输入为 NULL 或空串时，CROSS APPLY 直接跳过该行（OUTER APPLY 才保留）。
安全写法必须包含三重防护：
- 用
TRIM(s.value)做比较或输出，避免空格干扰 - 加
WHERE NULLIF(TRIM(s.value), '') IS NOT NULL过滤空值 - 存储过程开头加校验：
IF @input IS NULL OR LTRIM(@input) = '' RETURN
示例过滤条件：
WHERE TRIM(s.value) = 'urgent' AND NULLIF(TRIM(s.value), '') IS NOT NULL
CROSS APPLY 性能容易在哪卡住？
它本质是嵌套循环：对左表每行，都执行一次右侧逻辑。当左表有 10 万行，右侧没索引又没 TOP 限制，性能会断崖下跌。
典型陷阱：
- 右侧写成
CROSS APPLY (SELECT * FROM orders WHERE orders.user_id = users.id)，没TOP、没索引，等于对每个用户全表扫 orders - 把本可用
JOIN实现的简单关联硬套APPLY，执行计划反而更差 - 在大表上反复调用
STRING_SPLIT且未建计算列或持久化索引，CPU 占用飙升
优化建议：
- 拆分字段若高频查询，考虑提前用计算列 + 索引固化（如
ALTER TABLE products ADD tags_split AS STRING_SPLIT(tags, ',')不行，得用持久化视图或影子表） - 右侧务必加
TOP N或强WHERE条件，并确保关联字段有索引 - 确认是否真需要“逐行动态展开”——如果只是静态枚举映射，用
JOIN更稳
最后提醒一句：STRING_SPLIT 不支持多字符分隔符（如 '|;'），遇到就得分两步走，先替换再拆，或者换 OPENJSON 解析伪 JSON 格式。这点很容易被忽略，直到数据里突然冒出 'tag1;;tag2' 导致空行污染结果集。
