STRING_SPLIT函数在SQL Server 2016中首次引入，专门用于解决字符串拆分这一长期存在的难题。到了2022版本，虽然功能有所增强，但若将其视为一把完美的“瑞士军刀”直接投入生产环境，很可能会遇到各种棘手问题。许多隐藏的陷阱，如果不仔细查阅官方文档，根本难以察觉。
先给出几个核心判断：STRING_SPLIT确实能完成拆分任务，但默认状态下存在“不保序、不清洗、不兼容多字符分隔符”三大缺陷。只要其中任何一个没有妥善处理，查询数据时就会感觉处处不对劲，结果与预期不符。
先从最基本的参数说起。
两个必填参数如何正确传递才不报错
函数签名清晰明了：STRING_SPLIT(string, separator[, enable_ordinal])。前两个参数是必需的。
string参数允许传入NULL，但如果真传了NULL，返回的并不是一行NULL，而是空结果集。这个细节在编写外连接逻辑时，很容易导致意外的断链，影响数据完整性。separator分隔符的要求非常严格，必须是单字符。传入','没问题，但如果是', '（逗号加空格）或'\t'，立刻会报错：Msg 214，明确提示分隔符必须是单字符字符串。- 如果分隔符来自变量（如
@sep），稳妥的做法是增加校验：WHERE LEN(@sep) = 1，或者直接用SUBSTRING(@sep, 1, 1)强制取第一个字符作为分隔符。
行顺序为什么总是混乱的
这可能是STRING_SPLIT最令人头疼的设计缺陷。默认情况下，它不保留原始元素在字符串中的位置顺序。输入 'a,b,c'，可能返回 ('a', 'c', 'b')。这不是Bug，而是关系型数据库集合本身没有顺序概念，它只是忠实地执行了设计规范。
- 想要保持顺序？SQL Server 2022+ 必须显式启用第三个参数：
STRING_SPLIT(@str, ',', 1)。这样才能同时获取value和ordinal两列，ordinal从1开始，表示元素在原字符串中的实际位置。 - 如果漏掉了第三个参数，或者传了
0或NULL，ordinal列就不会出现。 - 需要稳定顺序时，必须写成：
SELECT value, ordinal FROM STRING_SPLIT(@str, ',', 1) ORDER BY ordinal。
连续逗号、前后空格、超长文本怎么处理
STRING_SPLIT是一个直来直去的函数，只负责机械切割。遇到 'a,,b'，它返回三行：'a'、''、'b'；遇到 ' a , b '，空格原样保留。它的 value 列类型固定为 NVARCHAR(4000)，即使源字段是 VARCHAR(MAX)，超过4000个字符的部分也会被截断。
- 过滤空项：添加
WHERE TRIM(value) != '' - 统一去除空格：使用
TRIM(value) AS clean_value - 防止截断：如果源字符串可能超过4000字符，建议先执行
CAST(@input AS NVARCHAR(MAX))再传入函数。 - 连续分隔符产生的空项，如果业务上并非有意为之，不处理的话，在
IN子句中使用时可能会匹配到空值，导致逻辑完全混乱。
在 WHERE 或 JOIN 中直接嵌套调用为什么慢
这个坑踩的人最多。将 STRING_SPLIT 直接塞进 WHERE id IN (SELECT value FROM STRING_SPLIT(@ids, ','))，优化器很难对它进行谓词下推，也难以利用索引，极易引发全表扫描。
- 更稳妥的做法是：先将拆分结果存入临时表，再建立索引。例如
SELECT TRIM(value) AS val INTO #split FROM STRING_SPLIT(@ids, ',') WHERE TRIM(value) != ''，然后执行CREATE INDEX IX_val ON #split(val)。 - 如果应用层能改为表值参数（TVP），性能会大幅提升，服务端可以直接走索引查找。
- 绝对要避免在大表的
WHERE子句中反复调用这个函数，尤其是当作标量子查询使用时。
归根结底，STRING_SPLIT真正让人头疼的地方，从来不是“能不能拆分”，而是“拆分之后顺序对不对、空值有没有遗漏、性能扛不扛得住”。这三点只要有一个没有考虑周全，上线后数据就可能出错，但排查半天往往还发现不了问题根源。
