MySQL不支持SELECT INTO，应使用CREATE TABLE ... AS SELECT；该语句仅复制列名、数据类型和NOT NULL属性，不复制主键、索引、外键、AUTO_INCREMENT、COMMENT等约束。
直接说结论：在 MySQL 中不能用 SELECT INTO，它只属于 SQL Server / Access；MySQL 里等效的是 CREATE TABLE ... AS SELECT，但要注意它不复制主键、索引、外键、自增属性等约束。
MySQL 里 CREATE TABLE ... AS SELECT 的行为边界
这个语句本质是「建表 + 插入」一步完成，但只基于查询结果推导列名和数据类型，不读取原表的 DDL 元信息。
- 会复制
NOT NULL、DEFAULT（部分版本）、列类型（如VARCHAR(255)），但精度可能被截断（比如原为DECIMAL(10,2)，推导成DECIMAL(10,0)） - 完全丢失：
PRIMARY KEY、UNIQUE KEY、FOREIGN KEY、AUTO_INCREMENT、COMMENT、分区定义、字符集/排序规则（除非显式指定CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci） - 如果原表有生成列（generated column）或虚拟列，
AS SELECT会把它转成普通列，失去计算逻辑
SQL Server 中 SELECT INTO 的实际限制
它看起来更“全自动”，但其实也有明确盲区：
- 能继承源列的
NULL/NOT NULL属性、数据类型、IDENTITY属性（但新表的 identity seed 重置为 1） - 不复制：
CHECK约束、DEFAULT约束、FOREIGN KEY、索引、触发器、统计信息 - 执行前目标表不能存在，否则报错
Msg 2714, Level 16, State 6: There is already an object named 'xxx' in the database. - 事务日志开销大，大表操作容易填满日志文件 —— 生产环境慎用，尤其在简单恢复模式下
真正要“完整复制”，得拆成两步走
无论是 MySQL 还是 SQL Server，只要涉及主键、索引、约束等生产级要求，就不能依赖单条语句。
- MySQL：先用
SHOW CREATE TABLE 原表拿到完整建表语句，手动改表名后执行；再用INSERT INTO 新表 SELECT * FROM 原表 - SQL Server：用 SSMS 右键 → “编写表脚本为” → “CREATE 到”，或用
sys.dm_exec_describe_first_result_set辅助生成 DDL；数据用INSERT INTO 新表 SELECT * FROM 原表（注意IDENTITY_INSERT开关） - 跨库或跨实例时，
mysqldump --no-data+--where="1=1"是更稳的选择，它保留全部元数据
最容易被忽略的一点：CREATE TABLE ... AS SELECT 和 SELECT INTO 都不会校验字段顺序是否与目标业务逻辑匹配。如果后续应用硬编码了列序（比如 JDBC 的 rs.getString(1)），而原表某天加了新字段，复制出来的表字段顺序可能已不同 —— 这类隐性兼容问题，比少个索引更难排查。
