把查询结果插入临时表，看起来只是把 SELECT 接到 INSERT 后面，但真正容易出问题的往往不是语法本身，而是列顺序、临时表作用域、类型推导和筛选条件。本文把这些高频坑点拆开说明，并给出更适合生产环境的写法。
INSERT INTO ... SELECT 时，目标列名要不要写？
结论很直接：目标列名不是强制，但实际开发里应当尽量显式写出。
如果省略列名，那么 SELECT 返回的列数、顺序和类型都必须与目标临时表完全一致。只要有一点偏差，就可能报错，比如 Column count doesn't match value count，或者出现隐式转换失败。
为什么显式列名更稳妥
- 避免依赖字段顺序，后续改表结构时不容易误伤已有逻辑
- 源查询里有表达式时，字段语义更清晰
- 插入失败时更容易定位具体是哪一列不匹配
实操建议
- 始终使用
INSERT INTO #temp (col1, col2) SELECT a, b FROM ...这种显式列名写法 - 如果源查询包含表达式，例如
COUNT(*)、ISNULL(x,0)，必须给结果列起别名，否则可能出现(No column name)，进而导致插入失败 - 如果临时表字段定义为
NOT NULL，就要确保SELECT结果里没有NULL，否则会报Cannot insert the value NULL
INSERT INTO #temp (col1, col2)
SELECT a, b
FROM ...#temp 和 ##temp 有什么区别？
这两个临时表前缀，决定的不是语法风格，而是可见性和并发行为。
#temp：会话级本地临时表，只在当前连接可见##temp：全局临时表，所有会话都可读
其中 ##temp 虽然看起来“更方便”，但前提很多：创建者连接不能断开，而且没有其他连接在不安全地独占写入，否则很容易引发并发问题。
常见误用场景
- 在存储过程中创建
#temp，上层应用多线程并发执行：各自会话互不影响，这是本地临时表的正常用法 - 误用
##temp做并发写入：可能出现数据覆盖，或者报Invalid object name '##temp'，因为另一连接已经把它删掉 - 在 SSMS 打开新查询窗口后，误以为能继续访问另一个窗口里的
#temp：实际不能，会报Invalid object name '#temp'
怎么选更合适
如果只是当前脚本、当前存储过程或当前连接内的中间结果，优先用 #temp。只有确实需要跨会话共享，而且能控制并发和生命周期时，才考虑 ##temp。
SELECT INTO 和 INSERT INTO ... SELECT 该怎么选？
两者最核心的区别在于：SELECT INTO 会自动创建临时表结构，而 INSERT INTO ... SELECT 要求目标表事先存在。
SELECT INTO 适合什么场景
如果你在做快速原型、临时调试，SELECT INTO #temp FROM ... 写起来确实更省事，因为不需要先手工定义表结构。
但它的代价也很明显：
- 不能提前指定索引、约束、
NULL/NOT NULL属性 - 字段类型完全由源列推断，结果未必符合预期，例如
VARCHAR(50)可能被推成VARCHAR(8000) SELECT INTO在事务中不可回滚表结构创建，虽然 SQL Server 2019+ 支持部分回滚，但兼容性并不稳定
生产环境为什么更常用显式建表
对于正式逻辑，更推荐先建表，再插入数据：
CREATE TABLE #temp (...)
INSERT INTO #temp (col1, col2)
SELECT a, b
FROM ...这样做的好处是：
- 字段类型可控，避免推导错误
- 可以添加
PRIMARY KEY或INDEX - 显式
CREATE+INSERT整体更容易纳入事务控制
最容易被忽略的坑：WHERE 条件漏写
相比语法报错，更麻烦的是语法正确、结果却失控。最典型的情况就是漏写 WHERE，或者关联条件写错，导致 SELECT 一次性返回百万行，插入临时表时出现卡死、日志暴涨、阻塞其他会话。
上线前怎么排查
- 先执行
SELECT COUNT(*) FROM ... [你的 WHERE 条件]，确认返回行数是否符合预期 - 在
INSERT INTO #temp SELECT ...前临时加上SET ROWCOUNT 1000;做小批量验证，确认逻辑没问题后再去掉 - 如果只需要最新 N 条数据，优先使用
TOP N配合ORDER BY，避免全表扫描后再排序
为什么这个问题最难排查
因为这类错误常常不会第一时间报语法异常。你看到的可能只是任务变慢、锁等待增加、日志突然膨胀，或者临时表数据量远超预期。等到回头翻日志、重跑任务时，排查成本就已经很高了。
实战中的推荐写法
如果你希望把查询结果稳定地插入临时表，下面这套原则基本够用：
- 优先写成
INSERT INTO #temp (col1, col2) SELECT ...，不要省略目标列名 - 表达式结果一定要加别名，避免
(No column name) - 生产逻辑优先选择
CREATE TABLE #temp (...)再INSERT INTO - 默认使用
#temp，慎用##temp做跨会话共享 - 插入前先验证
WHERE条件和数据量，避免临时表“爆表”
真正影响稳定性的，通常不是 INSERT INTO ... SELECT 这几个关键字本身，而是字段类型推导、并发可见性和结构创建时机这三个细节。把这几处控制住，临时表脚本会稳很多。
