在MySQL中不能用SELECT INTO，应使用CREATE TABLE AS SELECT；该语句仅复制列名、数据类型和NOT NULL属性，不复制主键、索引、外键、AUTO_INCREMENT、COMMENT等约束。
可以直接用 CREATE TABLE ... AS SELECT 一次性完成建表 + 插入，但必须注意字段类型推导和 NULL 约束的丢失。
用 CREATE TABLE ... AS SELECT 快速复制指定列
这是最直接的方式，适合目标表不存在、且对字段约束要求不高的场景。MySQL、PostgreSQL、SQLite 都支持，但行为略有差异。
- 语句形如：
CREATE TABLE new_table AS SELECT col1, col2, col3 FROM old_table WHERE condition; - 新表字段名和类型由
SELECT结果集自动推导，比如SUM(price)会变成decimal或double，具体取决于数据库实现 - 所有约束（
PRIMARY KEY、NOT NULL、默认值、索引）都不会被继承，新表是“裸数据”结构 - PostgreSQL 中该语句默认不包含
OIDS，但若源表有生成列或表达式，需显式别名才能建成功
先建表再 INSERT INTO ... SELECT，控制字段定义
当需要保留 NOT NULL、默认值、主键或后续加索引时，必须分两步走。这是生产环境更稳妥的做法。
- 先手工写
CREATE TABLE，明确指定每列类型、是否允许 NULL、默认值等，例如：CREATE TABLE users_summary ( id INT PRIMARY KEY, name VARCHAR(100) NOT NULL, total_orders INT DEFAULT 0 );
- 再执行插入：
INSERT INTO users_summary (id, name, total_orders) SELECT id, name, COUNT(*) FROM orders GROUP BY id, name; - 注意：列数、顺序、类型兼容性必须匹配；若目标列为
NOT NULL而源SELECT可能返回NULL（如外连接结果），会报错 - 大表迁移时建议加
WHERE分批，或在事务中操作，避免长事务阻塞
处理类型不一致或需要转换的字段
源列类型和目标列不完全对应时，不能依赖隐式转换，尤其跨数据库或涉及精度丢失风险。
- 日期字段常见问题：
SELECT created_at FROM old_table是DATETIME，但目标列定义为DATE，需显式转换：DATE(created_at) - 字符串截断风险：源
VARCHAR(255)插入目标VARCHAR(50)，MySQL 默认截断并警告，PostgreSQL 直接报错value too long for type character varying(50) - 数值溢出：源列是
BIGINT，目标是INT，超范围值会失败或静默转为边界值（取决于 SQL mode） - 建议迁移前用
SELECT MAX(LENGTH(col)), COUNT(*) FROM old_table校验长度，或用CASE WHEN LENGTH(col) > 50 THEN 'too long' ELSE col END做兜底
避免常见坑：NULL、空字符串、字符集和排序规则
这些细节在测试环境常被忽略，上线后引发数据异常或查询变慢。
-
SELECT中若含聚合函数（如COUNT()、AVG()）且无GROUP BY，结果只有一行——容易误以为是逐行迁移 - 源表某列为
TEXT且含大量空格或不可见字符，迁移到VARCHAR后可能因末尾空格被截断（MySQL 5.7+ 的sql_mode=STRICT_TRANS_TABLES下会报错） - 字符集不一致：源表用
utf8mb4，目标表建表时没指定，默认可能是latin1，中文会变乱码；务必在CREATE TABLE中显式声明CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 时间字段带时区？PostgreSQL 的
TIMESTAMP WITH TIME ZONE和 MySQL 的TIMESTAMP行为不同，迁移前确认业务是否依赖时区转换
真正麻烦的不是语法，而是字段语义是否被准确传递——比如一个叫 status 的 TINYINT 列，到底是 0/1 枚举，还是 0/1/2/99 多状态，还是历史遗留的 magic number。这类信息不会随数据一起迁移，得靠文档或代码反查。
