SELECT INTO不能接动态表名，因其是DDL语句，要求表名在编译期确定，不支持变量；强行拼接会报语法错误，且无法覆盖已存在表，也不保留索引、约束等元数据。
不能直接在存储过程中用 SELECT INTO + 动态表名实现“自动备份表”，因为 SELECT INTO 不支持变量表名，且无法在运行时动态生成目标表结构而不显式声明。
为什么 SELECT INTO 不能接动态表名
SELECT INTO 是 DDL 语句，要求目标表名在编译期就确定；SQL Server 不允许把变量（如 @backup_table_name）直接放在 INTO 后面。强行拼接会报错：Incorrect syntax near '@backup_table_name'。
即使改用 EXEC(@sql) 执行拼接字符串，也面临新问题：目标表若已存在，SELECT INTO 会失败（它只创建新表）；若想覆盖，必须先 DROP TABLE，但又可能误删业务表。
- 常见错误现象：
Msg 2714, Level 16, State 6: There is already an object named 'xxx' in the database. - 根本原因：
SELECT INTO的语义是“创建并插入”，不是“备份”；它不检查源表结构变更，也不保留索引、约束、权限等元数据。 - 性能影响：每次执行都重建表，触发统计信息重生成、日志暴增，尤其对大表会阻塞其他操作。
真正可用的动态备份方案：用 CREATE TABLE + INSERT INTO
要安全、可控地按需备份任意表（含动态表名），必须分两步：先建结构一致的新表，再插入数据。关键点在于用系统视图 sys.columns 和 sys.types 动态生成建表语句。
示例逻辑（简化版，不含错误处理）：
DECLARE @src_table SYSNAME = 'Orders';
DECLARE @dst_table SYSNAME = 'Orders_backup_' + FORMAT(GETDATE(), 'yyyyMMdd_HHmmss');
DECLARE @sql NVARCHAR(MAX);
<p>-- 构建 CREATE TABLE 语句（仅列定义，不含索引/约束）
SELECT @sql = 'CREATE TABLE ' + QUOTENAME(@dst_table) + ' (' +
STRING_AGG(
QUOTENAME(c.name) + ' ' +
t.name +
CASE
WHEN t.name IN ('char', 'varchar', 'nchar', 'nvarchar')
THEN '(' + CAST(c.max_length AS VARCHAR) + ')'
WHEN t.name IN ('decimal', 'numeric')
THEN '(' + CAST(c.precision AS VARCHAR) + ',' + CAST(c.scale AS VARCHAR) + ')'
ELSE ''
END, ', ')
WITHIN GROUP (ORDER BY c.column_id) + ');'
FROM sys.columns c
JOIN sys.types t ON c.user_type_id = t.user_type_id
WHERE c.object_id = OBJECT_ID(@src_table);</p><p>-- 拼接 INSERT
SET @sql = @sql + ' INSERT INTO ' + QUOTENAME(@dst_table) + ' SELECT * FROM ' + QUOTENAME(@src_table) + ';';</p><p>EXEC sp_executesql @sql;- 使用
QUOTENAME()防止 SQL 注入（尤其当表名来自用户输入时） - 不复制索引/主键/外键——这是备份表的合理取舍；如需完整副本，应改用
BACKUP DATABASE或第三方工具 - 注意：
STRING_AGG要求 SQL Server 2017+；旧版本需用FOR XML PATH替代
更稳妥的替代：用 BACKUP DATABASE + 还原到新库
如果目标是“保留某张表的历史快照供回溯”，比动态建表更可靠的方式是利用数据库级备份机制：
- 对整个数据库做一次
BACKUP DATABASE，指定WITH COPY_ONLY避免干扰现有日志链 - 还原到一个临时命名的数据库（如
MyDB_Backup_20260430），再从该库中SELECT INTO目标表 - 优点：100% 保持原表结构、数据类型、NULL 性、默认值；不依赖动态 SQL 安全性风险
- 缺点：占用更多磁盘空间；不适合高频小表备份场景
真正容易被忽略的是权限和上下文：存储过程默认以调用者权限运行，但 CREATE TABLE 需要目标数据库的 db_ddladmin 或 db_owner 角色；若用 EXECUTE AS OWNER 提权，必须确保 owner 账户有足够权限且未被锁定——这点在跨实例或 Always On 环境中极易出问题。
