先说几个核心判断：SELECT INTO 是 SQL Server 环境下最直接的单表备份手段，但它绝非“无脑复制”的工具。用错了方向，报错、丢失约束、甚至阻塞业务都是常有的事。它更适合开发调试、快速生成临时快照，而不应该被当作完整备份策略的替代方案。

那这个看似简单的功能，为什么经常让人踩坑？接着往下看。

为什么 SELECT INTO 执行失败？常见报错和原因

最常见的报错信息是：There is already an object named 'xxx' in the database. —— 原因很简单，SELECT INTO 要求目标表必须不存在，它不支持覆盖或追加操作，一旦目标表已存在，语句就会立即终止。

其他典型问题还包括：

• SELECT INTO 只能在当前数据库内执行，无法跨库写入。除非你使用四部分命名配合链接服务器，但那已经是另一套复杂的逻辑了。
• 如果源表包含计算列、稀疏列、FILESTREAM 列或 CLR 类型，SELECT INTO 虽然能勉强建表，但部分特性可能被降级处理，甚至直接丢失。
• 事务日志增长会非常剧烈。大表执行时，数据是一次性全部写入，无法分批提交，很容易触发日志文件满或超时问题。

如何安全生成带时间戳的备份表名？避免命名冲突

如果你在自动化脚本里硬编码表名，比如直接用 orders_backup，那么冲突几乎是必然的。推荐的做法是动态拼接表名，加入时间戳来区分不同版本：

DECLARE @backup_table_name NVARCHAR(128) = N'orders_backup_' + FORMAT(GETDATE(), 'yyyyMMddHHmmss');
DECLARE @sql NVARCHAR(MAX) = N'SELECT * INTO ' + QUOTENAME(@backup_table_name) + N' FROM dbo.orders;';
EXEC sp_executesql @sql;

这里有几个关键点：

• 一定要用 QUOTENAME() 包裹变量表名，这是防止注入和非法字符的底线。
• FORMAT() 在 SQL Server 2012 及以上版本可用；如果版本较老，可以改用 CONVERT(VARCHAR, GETDATE(), 120) 然后手动替换符号。
• 不要省略 dbo. 这样的 schema 前缀，否则很可能因为默认 schema 不同而查错表。

SELECT INTO 和 INSERT INTO ... SELECT 的本质区别

两者看似都能复制数据，但门道完全不同：

• SELECT INTO：自动建表并插入数据，这是 DDL + DML 的合并操作。它会获取数据库级别的架构锁（Sch-M），期间其他 DDL 操作（比如建索引、删表）都会被阻塞住。
• INSERT INTO ... SELECT：要求目标表已经存在，只做纯粹的 DML。锁粒度更细，通常是表级或页级，对并发环境的影响小得多。
• 如果你已经建好结构一致的空备份表（比如先用 SELECT * INTO dummy FROM xxx WHERE 1=0 建个壳子），后续用 INSERT INTO 分批插入数据，这种策略更适合处理大数据量场景。

备份后必须手动补上的东西

SELECT INTO 只复制列定义和数据，以下这些东西统统不会带过来：

• 主键、外键、唯一约束 → 必须用 ALTER TABLE ... ADD CONSTRAINT 重新添加。
• 索引（包括聚集索引）→ 必须单独 CREATE INDEX，否则查询性能会断崖式下跌。
• 统计信息 → 新表初始没有任何统计信息，首次查询大概率生成错误执行计划。记得手动执行 UPDATE STATISTICS。
• 权限设置、扩展属性、触发器 → 全部不继承，需要额外脚本同步。

真正要用于生产环境的备份表，这些补丁缺一不可。别只盯着数据“看起来一样”就以为完事了。