sqlserver查询表是否存在

判断一张表在 SQL Server 里是询表否存在，最直接的否存办法是查系统视图。但这里有个坑：不同版本的询表 SQL Server，系统视图的否存写法不太一样。老代码里常见 sysobjects，询表新版本更推荐 sys.objects 或 INFORMATION_SCHEMA.TABLES。否存你要是询表拿旧脚本往 SQL Server 2019 上跑，虽然多数还能用，否存但微软早把 sysobjects 归到兼容视图里了，询表哪天彻底拿掉也不奇怪。否存

我平时最常用的询表是 OBJECT_ID 函数。一行就够：

IF OBJECT_ID('dbo.Users',否存 'U') IS NOT NULL PRINT '表存在'; ELSE PRINT '表不存在';

这里第二个参数 'U' 表示用户表。不写也行，询表但写了更稳——万一你库里有个同名存储过程或视图，否存不指定类型就可能误判。询表OBJECT_ID 返回的是对象 ID，找不到就返回 NULL。简单、快、所有版本通吃。我见过有人用 IF EXISTS (SELECT * FROM sys.objects WHERE name = 'Users')，也能跑，但少了个 AND type = 'U' 就容易出岔子。而且没指定 schema 的话，默认按当前用户的默认 schema 找，跨 schema 场景下会翻车。

说到 schema，这是另一个容易忽略的点。SQL Server 里表名实际是 schema.table 两级结构。你写 OBJECT_ID('Users')，它找的是当前默认 schema 下的 Users。如果表建在 dbo 下，而你当前登录用户的默认 schema 是 sales，那就找不到。所以稳妥写法永远带上 schema：OBJECT_ID('dbo.Users', 'U')。这个细节在多人开发、多 schema 的库里特别要命。我以前接手过一个项目，测试环境一切正常，上了生产就报“表不存在”，查了半天就是 schema 没对上。

另一种查法是走 INFORMATION_SCHEMA：

IF EXISTS ( SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'Users' ) PRINT '存在';

这个写法标准 SQL 味更浓，跨数据库平台移植时省事。但在 SQL Server 上，INFORMATION_SCHEMA.TABLES 只列当前用户有权限看到的表。权限不够的话，表明明在，查询结果却是空。而 OBJECT_ID 走的是元数据函数，权限要求相对宽松些——当然也不是完全没限制，至少你得能访问那个 schema。

临时表又是另一回事。查 tempdb 里的临时表，OBJECT_ID('tempdb..#TempUsers') 才行。直接写 OBJECT_ID('#TempUsers') 在某些上下文里能过，但依赖当前数据库上下文，不稳。全局临时表 ##GlobalTemp 同理，得带上 tempdb 前缀。我调试存储过程时经常要判断临时表建没建，一开始老忘加 tempdb，结果 OBJECT_ID 返回 NULL，白白多写一堆重复创建逻辑。

还有个场景：动态 SQL 里拼表名。比如按日期分表，表名是 Orders_202401 这种。这时候不能用参数化查询直接传表名，只能拼字符串。拼完再塞给 OBJECT_ID 判断。但拼的时候注意引号转义，别让用户输入钻了 SQL 注入的空子。我一般会先用 QUOTENAME 把表名包一层，再拼进动态语句。

性能上，这些查询都是查系统目录，开销极小，不用担心。真正要留心的是并发——判断完表存在，到实际使用之间，万一有人把表删了，照样报错。所以如果是关键逻辑，判断完最好直接 TRY...CATCH 兜底，别把 OBJECT_ID 当原子锁用。

总结下来就三句话：用 OBJECT_ID 带 schema 和类型参数最省心；INFORMATION_SCHEMA 适合需要标准 SQL 的场合但注意权限；临时表记得加 tempdb 前缀。至于 sysobjects，新代码就别用了，留着老系统里跑跑就行。