如何让SQL Server在编译阶段拒绝存在表引用错误的存储过程？

先看你提供的有问题的存储过程代码：

create procedure tempsproc as 
select t1.c1 from #t join t2 on #t.c2 = t3.c3 

上述存储过程的SELECT子句引用了FROM子句未提及的表t1，ON子句也引用了未提及的表t3。我了解延迟名称解析机制，但无论运行时存在哪些表，该SELECT语句都无法正常执行。然而这段SQL在SQL Server 2008 R2 SP3中编译无报错，仅在运行时才暴露问题。请问需如何操作才能让SQL Server在编译阶段就拒绝该存储过程？

要解决这个问题，让SQL Server在编译阶段就检测出这类无效引用，你可以根据场景选择下面的方法：

1. 使用 WITH SCHEMABINDING 强制编译时验证 #

这是最直接的官方解决方案，当你创建存储过程时加上这个选项，SQL Server会在编译阶段严格检查所有对象引用的有效性，包括表、列是否存在，以及引用是否合法。

不过要注意，这个选项有几个关键限制，刚好你的代码里用到了临时表 #t，这个方法不适用于包含临时表的存储过程——因为临时表是会话级对象，无法绑定到数据库架构。如果你的存储过程可以替换掉临时表（比如改用永久表或表变量），那可以这么写：

create procedure tempsproc 
WITH SCHEMABINDING
as 
select t1.c1 from dbo.t join dbo.t2 on dbo.t.c2 = dbo.t3.c3 

（注意：使用SCHEMABINDING时，必须指定表的架构名，比如dbo.，且不能用临时表、表变量，也不能用*选择列）

2. 针对含临时表的场景：提前验证逻辑 #

如果必须用临时表，那SCHEMABINDING就派不上用场了，你可以这么做：

• 手动预验证：在创建存储过程前，先把临时表换成测试用的永久表，单独执行SELECT语句，这样能提前发现t1、t3这类未声明的表引用问题。
• 改用表变量：表变量（@t）的引用会在编译阶段被验证，如果你能接受表变量和临时表的性能/功能差异，把#t换成@t，SQL Server会在编译时就检测到t1、t3的无效引用。

3. 用静态代码分析工具提前预警 #

不管有没有临时表，你都可以借助SQL Server Management Studio（SSMS）的内置代码分析，或者第三方工具（比如Redgate SQL Prompt、ApexSQL Refactor），这些工具在你编写代码时就能实时扫描出这类“引用了未在FROM/JOIN中声明的表”的错误，不用等到编译或运行时才发现。

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