SELECT INTO仅SQL Server原生支持，可自动建表并插入数据；MySQL、PostgreSQL等不支持，需用CREATE TABLE ... AS SELECT替代，且新表不继承索引、约束、主键及排序规则。
SELECT INTO 在 SQL Server 中能直接建表并插入数据
只有 SQL Server（及部分兼容版本如 Azure SQL）原生支持 SELECT INTO 语法，它会在执行时自动创建目标表结构并写入数据。MySQL、PostgreSQL、SQLite 等主流数据库**不支持该语法**，强行使用会报错 Incorrect syntax near 'INTO' 或类似提示。
常见误操作是把 MySQL 的 CREATE TABLE ... AS SELECT 写成 SELECT ... INTO，结果直接失败。
- SQL Server 示例：
SELECT name, age INTO new_users FROM users WHERE age > 18;—— 自动建表new_users，字段类型和 NULL 属性继承自源列 - 表名不能已存在，否则报错
There is already an object named 'xxx' in the database - 新表默认不带索引、约束、主键、默认值；即使源列有
IDENTITY，目标列也不会自动继承（除非显式用IDENTITY(int,1,1)包裹）
MySQL 和 PostgreSQL 必须用 CREATE TABLE ... AS SELECT
MySQL 和 PostgreSQL 不认 SELECT INTO 表名，但都支持 CREATE TABLE ... AS SELECT，语义接近但行为细节不同：
- MySQL：
CREATE TABLE new_users AS SELECT name, age FROM users WHERE age > 18;—— 仅复制数据和列定义，不复制索引、主键、注释；NOT NULL属性会保留，但自增属性（AUTO_INCREMENT）不会自动加到新表 - PostgreSQL：
CREATE TABLE new_users AS SELECT name, age FROM users WHERE age > 18;—— 默认不继承NOT NULL约束，也不带默认值或序列；如需约束，得额外执行ALTER TABLE - 二者都不支持在
AS SELECT后直接加WITH NO DATA（那是 SQL Standard 的写法，仅部分数据库如 PostgreSQL 12+ 支持CREATE TABLE ... AS SELECT ... WITH NO DATA）
导出为新表时最容易忽略的三个坑
无论用哪种语法，以下问题高频出现且难定位：
-
SELECT *导出后字段顺序可能错乱：源表加了新列但应用代码仍按旧顺序读取，导致数据错位；建议始终显式列出字段名 - NULL 值处理差异：SQL Server 的
SELECT INTO会按源列的 NULL 性设置新列，但 PostgreSQL 的CREATE TABLE AS默认所有列为NULL，容易引发后续插入失败 - 字符集与排序规则丢失：SQL Server 新表继承当前数据库默认排序规则，但若源列为
COLLATE Latin1_General_CI_AS而目标库是Chinese_PRC_CI_AS，查询时可能隐式转换失败；MySQL 新表用当前库默认字符集，不继承源字段的CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
跨数据库迁移时别硬套 SELECT INTO
写脚本前先确认目标数据库类型，不要把 SQL Server 的运维习惯带到其他环境。例如在 Docker 里跑 MySQL 容器，看到别人写的 SELECT * INTO backup_table FROM origin 就直接粘贴，结果报错 ERROR 1064 (42000)。
如果必须统一写法，可考虑用应用程序层做中转（如 Python + pandas.read_sql + to_sql），或用数据库自带导出工具（mysqldump --where、pg_dump -t），而不是强求一条 SQL 解决所有问题。
真正麻烦的不是语法本身，而是建表后没人记得给新表加索引——等查得慢了才回头补，那时数据量已经上亿了。
