SQL视图执行顺序疑问：CAST转换为何先于WHERE过滤执行？

问题场景 #

需要将Test表中InvoiceNumber列的文本转为整数，创建了如下视图，意图先用WHERE子句过滤掉包含"ASD"的行，再将剩余行的InvoiceNumber列CAST为INT：

CREATE VIEW v_test as
SELECT [Id]
      ,CAST([InvoiceNumber] as INT) as [InvoiceNumber]
  FROM [Test]
  WHERE InvoiceNumber NOT LIKE '%ASD%'

但查询该视图时，却因含"ASD"的行转换失败报错——原以为视图会先执行过滤返回前三行，再进行转换。最终用TRY_CONVERT函数解决了问题，但疑惑为何会出现这种执行顺序异常？

测试用表及数据 #

CREATE TABLE [dbo].[Test](
    [Id] [int] NOT NULL,
    [InvoiceNumber] [nvarchar](100) NULL
) ON [PRIMARY]

INSERT [dbo].[Test] ([Id], [InvoiceNumber]) VALUES (1, N'10')
INSERT [dbo].[Test] ([Id], [InvoiceNumber]) VALUES (2, N'11')
INSERT [dbo].[Test] ([Id], [InvoiceNumber]) VALUES (3, N'12')
INSERT [dbo].[Test] ([Id], [InvoiceNumber]) VALUES (4, N'ASD')

原因解析 #

核心原因是SQL Server的查询优化器不遵循SQL语句的书写顺序执行。

SQL是声明式语言：你只需要告诉数据库要实现什么结果，不需要指定具体的执行步骤。查询优化器会根据表的统计信息、索引情况、数据分布等因素，自动生成它认为最优的执行计划——这个计划的步骤顺序，可能和你写SQL的顺序完全不同。

在你的场景中，优化器可能认为先尝试转换InvoiceNumber列，再进行过滤（或者在扫描表的过程中同时执行转换和过滤逻辑），这样的执行路径在某些情况下效率更高。但这种调整就导致了包含"ASD"的行被提前触发转换，最终抛出转换失败的错误。

可靠的解决方式 #

你使用TRY_CONVERT函数是非常合适的方案，它在转换失败时会返回NULL而非抛出错误，从根源上避免了转换异常：

CREATE VIEW v_test as
SELECT [Id]
      ,TRY_CONVERT(INT, [InvoiceNumber]) as [InvoiceNumber]
  FROM [Test]
  WHERE InvoiceNumber NOT LIKE '%ASD%'

另外，也可以通过嵌套子查询或CTE尝试强制先过滤再转换，但这种方式并非绝对可靠——优化器仍有可能调整执行顺序。而TRY_CONVERT直接处理了转换失败的场景，是更稳健的选择。

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