T-SQL视图中模拟局部变量的方法及局限性问询

• 非字符串类型值解析失败：STRING_SPLIT仅支持字符串拆分，若传递日期、数值等类型的字符串格式不符合SQL Server默认解析规则（比如服务器日期格式为DD/MM/YYYY，但传入MM/DD/YYYY格式的日期字符串），会直接抛出转换错误；数值型值带千分符或小数分隔符不匹配时，同样会导致转换失效。
• 空值/空列表逻辑异常：如果vars CTE中的变量值为空，或vars_dates拆分后得到空列表，会引发两种问题：一是IN (SELECT value FROM vars_dates)这类条件会永远不成立，导致查询返回空结果；二是若业务期望“无过滤”的场景，这种写法无法自动适配，必须额外处理空值逻辑。
• 重复值引发的性能/数据问题：STRING_SPLIT不会自动去重，若传入的字符串包含重复值，会生成重复行，后续关联或过滤时会导致数据重复，或让查询计划做多余的匹配操作，增加不必要的计算开销。
• 超长字符串拆分受限：STRING_SPLIT的输入字符串最大长度受限于VARCHAR(MAX)，若需传递的列表值过多、总长度超过上限，会直接截断或报错，无法处理超大量的条件值。

• 查询计划稳定性差：由于变量值通过CTE动态生成，SQL Server查询优化器难以准确预估行数，容易生成低效执行计划——比如本该用索引seek的场景，可能因预估错误变成全表扫描；且当拆分后的列表值数量波动大时，计划复用性极差。
• 维护成本高：所有“变量”需在CTE中硬编码或通过固定字符串传递，调整条件值必须修改VIEW定义，无法像局部变量那样在调用时动态传入；多变量、多值列表的场景下，CTE结构会极度臃肿，可读性和可维护性大幅下降。
• 类型无安全保障：STRING_SPLIT返回的value列是VARCHAR(MAX)类型，必须手动转换为目标类型（如CAST(value AS DATE)），一旦转换逻辑遗漏或写错，就会出现类型不匹配错误；且无编译时类型检查，问题只能在运行时暴露。
• 复杂逻辑无法实现：该方式仅能模拟简单的标量变量和单值列表过滤，无法支持复杂动态逻辑——比如根据变量值切换过滤条件、动态调整JOIN表，或实现多条件的AND/OR动态组合，所有逻辑必须在VIEW中写死，灵活性极低。
• 权限与部署受限：修改VIEW定义需要对应权限，频繁变更会增加运维风险；在严格的生产环境中，VIEW变更需经过审批流程，无法快速调整查询条件。

内容的提问来源于stack exchange，提问作者Greg