为何含TRY_CAST()的视图自连接全外查询性能极差？

• 执行计划被迫退化：
  原查询通过WHERE A.field_name = 'MyDummyTextToGetADateInTheValueColumn'可以利用视图底层表的索引快速筛选出50000行数据。但添加TRY_CAST(NULLIF(A.[value], '') AS DATE) IS NULL条件后，SQL Server无法通过索引直接判断字符串是否能转换为有效日期，必须对每一行的A.[value]执行逐行计算——先做NULLIF处理，再尝试日期转换。这种计算无法被索引覆盖，直接导致执行计划从高效的索引扫描/查找退化为全表扫描；再加上视图未物化，数据库需要先展开视图的所有底层表连接，再逐行执行转换逻辑，计算量大幅飙升。

• 全外连接的逻辑放大了开销：
  你的查询是自全外连接，原本过滤后A侧50000行、B侧15000行，但添加TRY_CAST条件后，数据库可能会先执行全外连接，再对连接后的所有行应用过滤条件（而非先过滤A侧再连接）。这使得原本只需要处理50000行的转换计算，变成了处理连接后最多65000行的全量计算，同时连接操作本身也会因为执行计划的改变变得更耗时。

• TRY_CAST本身的CPU开销：
  日期字符串转DATE类型属于CPU密集型操作，尤其是当需要处理大量数据时。你的A.[value]列有近20%的非空非空串值，加上空串的NULLIF处理，每一行都要经过字符串检查和转换尝试。如果视图未物化，每次查询都要重新计算视图的底层连接，再叠加TRY_CAST的逐行计算，CPU负载会急剧上升，直接拖慢查询速度甚至导致超时。

• 统计信息偏差引发的计划错误：
  视图基于多个索引表的内连接构建且未物化，SQL Server的统计信息可能无法准确预估TRY_CAST条件过滤后的数据量。如果统计信息过时，数据库可能会选择效率极低的执行计划——比如错误地选择哈希连接替代嵌套循环，或者因行数预估错误导致内存分配不足，进一步加剧查询的性能问题。

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