使用object_id判断表是否存在时返回null，是因为其默认仅在当前数据库的默认架构（如dbo）中查找，若表位于其他架构（如sales.customers）而未显式指定架构名，或查询临时表时未加tempdb..前缀，均导致查不到而返回null。
用 OBJECT_ID 判断表是否存在时，为什么返回 NULL？
因为 OBJECT_ID 默认只查当前数据库的默认架构（通常是 dbo），如果表在别的架构下（比如 sales.Customers），不显式指定架构名就会查不到，返回 NULL。常见错误是写成 OBJECT_ID('Customers')，结果判断失败，后续建表语句重复执行报错。
正确做法是带完整两段式名称：架构名 + 表名。SQL Server 要求必须用字符串字面量，不能拼接变量（否则可能被 SQL 注入或解析失败）。
- ✅ 正确：
OBJECT_ID('dbo.Customers')、OBJECT_ID('sales.Orders') - ❌ 错误：
OBJECT_ID('Customers')（隐式架构不可靠） - ❌ 错误：
OBJECT_ID(@schema + '.' + @table)（动态拼接不被OBJECT_ID支持）
如何让建表脚本真正幂等？
仅靠 IF NOT EXISTS（SQL Server 2016+）不够——它只对新语法有效，且不覆盖老版本；而 OBJECT_ID 是全版本兼容的兜底方案。关键在于把判断和建表包进同一个批处理，并避免 GO 分隔导致作用域丢失。
示例（安全建表）：
IF OBJECT_ID('dbo.ProductLog', 'U') IS NULL
BEGIN
CREATE TABLE dbo.ProductLog (
Id INT IDENTITY(1,1) PRIMARY KEY,
EventTime DATETIME2 DEFAULT GETDATE(),
Message NVARCHAR(500)
);
END
-
'U'表示用户表（User table），强烈建议显式传入类型参数，避免视图、同义词等干扰 - 不要在
IF和BEGIN之间换行加 GO —— 那会中断批处理，使CREATE TABLE独立执行，失去条件控制 - 如果脚本要支持部署到不同环境，把
dbo换成变量需配合EXEC sp_executesql，但会增加复杂度和风险
OBJECT_ID 在临时表和内存优化表上的行为差异
临时表（#tmp）的 OBJECT_ID 只在当前会话中有效，且名字会被系统重写（如 #tmp____000000000001），所以不能用 OBJECT_ID('#tmp') 判断——永远返回 NULL。内存优化表（WITH (MEMORY_OPTIMIZED=ON)）则完全支持 OBJECT_ID，和普通表一致。
- 判断本地临时表是否存在，改用
IF OBJECT_ID('tempdb..#tmp') IS NOT NULL - 全局临时表（
##tmp）同理，查tempdb下的对象名 - 内存优化表无需特殊处理，
OBJECT_ID('dbo.MyMemTable', 'U')可靠有效
为什么有时 OBJECT_ID 返回非 NULL 却建表仍报“对象名已存在”？
最常见原因是缓存或延迟：刚删掉一个表，立刻用 OBJECT_ID 查，可能因元数据未及时刷新而返回旧值；或者该名字被用作别名、同义词、视图，而你传的类型参数不对（比如漏了 'U'），导致误判。
- 删表后加
WAITFOR DELAY '00:00:00.001'不解决问题，应避免紧邻删-查操作 - 始终指定类型参数：
'U'（表）、'V'（视图）、'P'（存储过程） - 若需强一致性，可补查
sys.tables：SELECT 1 FROM sys.tables WHERE name = 'MyTable' AND schema_id = SCHEMA_ID('dbo')
真正麻烦的不是语法，而是跨环境时架构名硬编码、类型参数遗漏、以及把临时表当普通表查——这些地方一错，幂等性就彻底失效。
