必须用 OBJECT_ID('tempdb..#表名', 'U') 判断本地临时表是否存在，因临时表仅存于 tempdb 且名称被系统重写；直接 OBJECT_ID('#表名') 永远返回 NULL，且 DROP TABLE #表名 不可在动态 SQL 中执行，须在同一作用域内操作。
SQL Server 中用 OBJECT_ID 判断临时表是否存在
SQL Server 不支持 DROP TABLE IF EXISTS #temp（直到 2016 SP1 才在全局临时表中部分支持，但本地临时表始终不支持），所以必须先查再删。核心是用 OBJECT_ID 检查对象 ID，注意传入的第二个参数必须是 'U'（表示用户表），且临时表名要带 # 前缀和数据库上下文。
常见错误是写成 OBJECT_ID('#temp') 却没指定数据库，或误用 'local_temporary_table' 这类不存在的类型参数。
-
OBJECT_ID查本地临时表时，必须指定当前会话所在的数据库名，例如tempdb..#mytemp—— 但更稳妥写法是直接用tempdb数据库上下文查：OBJECT_ID('tempdb..#mytemp', 'U') - 不能只写
OBJECT_ID('#mytemp')：它默认在当前数据库下查找，而本地临时表物理上只存在于tempdb，所以永远返回NULL - 如果在存储过程中多次创建同名临时表，不加判断直接
DROP会报错Cannot drop the table '#mytemp', because it does not exist or you do not have permission.
删除前必须确保在 tempdb 上下文中执行 DROP
即使 OBJECT_ID('tempdb..#mytemp', 'U') 返回了有效 ID，也不能直接 DROP TABLE #mytemp —— 这条语句本身没问题，但如果你在动态 SQL 中拼接 DROP，就容易出错。根本原因是：本地临时表作用域绑定到会话+批处理，而动态 SQL 是独立批处理，无法访问外层定义的本地临时表。
所以安全做法是：用 OBJECT_ID 判断后，在同一作用域内直接 DROP TABLE #mytemp，不要包进 EXEC() 或 sp_executesql。
- ✅ 正确：
IF OBJECT_ID('tempdb..#mytemp', 'U') IS NOT NULL<br> DROP TABLE #mytemp - ❌ 错误：
IF OBJECT_ID('tempdb..#mytemp', 'U') IS NOT NULL<br> EXEC('DROP TABLE #mytemp')—— 动态 SQL 里看不到外层的#mytemp - ⚠️ 注意：全局临时表（
##mytemp）不受此限制，但它的可见性跨会话，需谨慎清理
为什么不用 sys.tables 或 sys.objects 直接查？
有人会想用 SELECT 1 FROM tempdb.sys.tables WHERE name LIKE '#mytemp%'，这理论上可行，但实际不推荐。因为本地临时表在 tempdb 中的真实名字被系统重命名（如 #mytemp__________________________________________________________________________________________________________________000000000001），靠 LIKE 匹配不可靠，且性能差、易误匹配。
-
OBJECT_ID('tempdb..#mytemp', 'U')内部已处理了这种重命名映射，是 SQL Server 官方支持的唯一可靠方式 -
sys.tables查出来的name字段是物理名，不是你写的逻辑名，不能直接比对 - 即使加上
session_id过滤（通过sys.dm_exec_sessions关联），也增加复杂度，无必要
存储过程里重复使用临时表的典型模式
实际写存储过程时，往往需要“先删旧、再建新”，尤其在循环或条件分支中反复操作同一临时表。这时候顺序和作用域最关键：删、建、用必须在同一个批处理层级，否则建表后可能因作用域提前结束而丢失。
- 把
DROP和CREATE TABLE #mytemp放在同一IF块或连续语句中，避免中间有GO或嵌套批处理 - 如果用
INSERT INTO #mytemp SELECT ...，确保#mytemp已存在；否则先CREATE，别依赖隐式创建（SQL Server 不支持） - 临时表名尽量带业务前缀（如
#sales_calc），避免和别人写的#temp碰撞，尤其在调试时多个会话并行运行存储过程
OBJECT_ID 的调用方式和 DROP 的执行位置稍有偏差，就会导致“删不掉”或“删错了”。真正麻烦的不是语法，而是会话上下文和批处理边界的隐式影响。 
