CREATE TABLE ... SELECT 最快但丢失主键索引等元信息且字段类型可能被推断失真；应优先用 SHOW CREATE TABLE 复制建表语句，再 INSERT SELECT 并显式处理类型、NULL、字符集及分批迁移。
CREATE TABLE ... SELECT 一步到位，但字段类型可能不匹配
直接用 CREATE TABLE new_table AS SELECT * FROM old_table 最快，但新表的字段类型会按查询结果“推断”——比如 VARCHAR(255) 字段参与了 GROUP BY 或拼接，可能变成 TEXT；TINYINT(1) 布尔字段可能变成 TINYINT(3)。主键、索引、注释、默认值全丢光。
- 如果只要数据结构一致，优先用
SHOW CREATE TABLE old_table复制建表语句，再手动改表名，最后INSERT INTO new_table SELECT * FROM old_table - 如果旧表有
auto_increment主键，新表需要保留自增属性，不能靠AS SELECT，必须显式定义id INT PRIMARY KEY AUTO_INCREMENT - 注意字符集：若旧表是
utf8mb4，而连接客户端默认latin1，SELECT过程中可能触发隐式转换，导致乱码或截断
INSERT INTO ... SELECT 要求字段数量和类型严格兼容
目标表必须已存在，且 SELECT 的列数、顺序、可隐式转换的类型需与目标表字段对齐。MySQL 不会自动 cast 大多数类型（比如 DATETIME 列不能直接插入字符串 '2023-01-01'，除非 SQL mode 允许）。
- 明确写出字段名，别用
*：INSERT INTO new_table (id, name, created_at) SELECT id, name, created_at FROM old_table - 遇到类型不兼容时，用
CAST()或函数转换：CAST(phone AS CHAR)、DATE(created_time) - 如果旧表有生成列（generated column）或虚拟列，
SELECT *会把它们也拉出来，但目标表若没有对应字段就会报错Column count doesn't match value count
大批量迁移时避免锁表和日志爆炸
单条 INSERT INTO ... SELECT 会持有一个事务级写锁，旧表不可写，binlog 写入整条语句（不是逐行），可能撑爆磁盘或拖慢从库同步。
- 分批次处理：用
WHERE id BETWEEN ? AND ?配合循环脚本，每次 10k 行左右 - 临时关闭唯一性检查和外键约束（仅限迁移期间）：
SET FOREIGN_KEY_CHECKS = 0、SET UNIQUE_CHECKS = 0，完事后记得恢复 - 确认 binlog format 是
ROW（推荐），避免语句级复制在从库因时间/函数等产生不一致
NULL 值、默认值和空字符串容易被忽略的细节
旧表某列为 NOT NULL DEFAULT 'N/A'，但 SELECT 拉出来的值如果是 NULL，直接 INSERT 会报错；反过来，如果目标列允许 NULL，但旧表该字段实际全是空字符串 ''，迁移后看起来“没数据”，其实是有效值。
- 检查旧表是否有
NULL值：SELECT COUNT(*) FROM old_table WHERE col_name IS NULL - 用
COALESCE(col_name, 'N/A')替换NULL，或用IFNULL()，确保不违反目标表约束 - 注意
TRIM()：某些文本字段带首尾空格，看着像空，其实不是''，也不是NULL，影响业务判断
事情说清了就结束。最常出问题的不是语法，而是字段类型推断偏差、NULL 处理逻辑不一致、以及一次性跑全量时锁表现象超出预期。
