存储过程重复执行create temporary table报错，因临时表在会话内持久存在，未显式drop则名称被占用；须在创建前加drop table if exists或动态生成唯一名。
CREATE TEMPORARY TABLE 本身不会跨会话冲突，但存储过程中若重复执行、嵌套调用或与普通表同名，就真会报错或行为异常——根本原因不是“名字重复”，而是作用域和生命周期没管住。
为什么存储过程里 CREATE TEMPORARY TABLE #t 第二次执行会报错？
因为临时表在会话内是持久存在的，只要没显式 DROP TABLE #t 或会话没断开，#t 就一直占着名字。存储过程反复调用时，第二次执行 CREATE TEMPORARY TABLE #t 就会触发 “There is already an object named '#t' in the database” 错误。
常见场景包括：报表定时任务反复跑、Web API 多次请求复用同一连接池、SSIS 包循环执行存储过程。
- 必须在
CREATE前加判断：IF OBJECT_ID('tempdb..#t') IS NOT NULL DROP TABLE #t - 更稳妥的做法是把
DROP放在过程开头，而不是依赖IF——避免竞态（比如两个并发线程同时判断存在，然后都去创建） - 不要用
SELECT ... INTO #t替代CREATE，它不支持指定列类型、约束、索引，且同样受“已存在”限制
存储过程调用链中，#t 在子过程里能访问吗？
能，但仅限于**同一会话 + 同一线程 + 未被上层显式 DROP**。SQL Server 的本地临时表作用域是会话级，不是过程级。这意味着：
- 父过程创建
#t，子过程可以直接INSERT/SELECT它，无需重新CREATE - 但如果父过程里写了
DROP TABLE #t，子过程再引用就会报 “Invalid object name '#t'” - 反过来，子过程
DROP了#t，父过程后续操作也会失败 - 全局临时表
##t虽然所有会话可见，但极易引发并发写冲突，实际项目中应避免使用
CREATE PROCEDURE 内部建临时表，为什么有时提示 collation 冲突？
错误信息类似：Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and "Chinese_PRC_CI_AS"。这不是临时表命名问题，而是 tempdb 和用户数据库排序规则不一致导致的字符串比较失败。
典型触发点：临时表字段是 VARCHAR 或 NVARCHAR，而插入/JOIN 的数据来自不同 collation 的库表，SQL Server 在隐式转换时无法自动对齐。
- 最直接的修复是在建表时显式声明 collation：
name VARCHAR(50) COLLATE DATABASE_DEFAULT -
DATABASE_DEFAULT表示继承当前上下文数据库的 collation（即你调用存储过程的那个库），不是 tempdb 的 - 避免用
COLLATE Chinese_PRC_CI_AS这类硬编码，否则换环境就崩 - 如果字段来自
SELECT INTO，记得在SELECT子句里给字符串列加COLLATE DATABASE_DEFAULT
如何让临时表名在存储过程中真正“隔离”？
靠人工拼接前缀（如 #t_@session_id）既麻烦又不可靠。真正可控的方式是利用系统函数动态生成唯一名：
- 用
NEWID()或@@SPID+GETDATE()拼接：DECLARE @tname NVARCHAR(128) = '#t_' + CONVERT(VARCHAR(10), @@SPID) + '_' + REPLACE(CONVERT(VARCHAR(23), GETDATE(), 121), ':', '') - 然后用
EXEC('CREATE TABLE ' + @tname + ' (...)')动态建表 - 关键点：后续所有
INSERT/SELECT/DROP都得用这个变量，不能写死#t - 注意：动态 SQL 中的临时表只在该 EXEC 上下文中存在，出作用域就消失——所以建表和使用必须在同一个
EXEC字符串里，或改用sp_executesql并传参
这种写法绕过了名称冲突，但代价是可读性下降、调试困难。除非你明确需要多实例并行运行同一存储过程，否则优先用开头的 DROP IF EXISTS 方案更轻量。
