不能直接用insert into ... select合并结构不一致的表，因为字段名、数量、顺序、类型不匹配时会报column count doesn't match value count等错误，或引发静默错位（如phone误插进age）；安全做法是显式声明列映射、用coalesce/case处理缺失与逻辑字段、cast强转类型、分批去重插入，并统一用null补齐避免类型推导偏差。
为什么不能直接用 INSERT INTO ... SELECT 合并结构不一致的表
因为字段名、数量、顺序、类型不匹配时，INSERT INTO t_new SELECT * 会报错，比如 Column count doesn't match value count 或 Truncated incorrect value。更危险的是“静默错位”——字段对不上但语句执行成功，比如把 phone 插进 age 字段，数据就乱了。
安全合并的前提是显式声明映射关系，而不是依赖列序或通配符。
用显式列名 + COALESCE / CASE 处理缺失字段
两张历史表字段交集可能很小，比如 old_user_v1 有 uid, name, reg_time，而 old_user_v2 有 id, full_name, created_at, status。目标表 users 定义为 (id BIGINT, name VARCHAR(100), created_at DATETIME, status TINYINT DEFAULT 0)。
实操建议：
- 只在
SELECT子句中列出目标表所有字段，并一一对应来源字段或默认值 - 用
COALESCE(old_v1.name, old_v2.full_name)填补非空优先字段 - 用
CASE WHEN old_v1.uid IS NOT NULL THEN 1 ELSE 0 END AS status补充逻辑推导字段 - 对类型不一致的字段做显式转换，如
CAST(old_v2.created_at AS DATETIME)，避免隐式转换出错
分批插入 + WHERE NOT EXISTS 避免主键冲突
历史表通常没主键或主键不统一，直接全量插入容易重复。不能靠 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 简单兜底，因为它们掩盖了数据源本身的歧义（比如同一业务 ID 在两张表里对应不同人）。
更稳妥的做法：
- 先用
SELECT id FROM users缓存已存在主键（若数据量小），或建临时表存已处理 ID - 对每张源表分别执行带去重条件的插入：
INSERT INTO users (...) SELECT ... FROM old_user_v1 u1 WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = u1.uid) - 插入前加
SELECT COUNT(*)预估行数，防止某张表意外导入百万行导致锁表 - 用
LIMIT分批次（如每次 5000 行），配合OFFSET或基于自增 ID 的游标推进
用 UNION ALL 合并多源再插入，但必须保证字段类型强一致
如果两张表都要映射到同一目标结构，UNION ALL 比写两个独立 INSERT 更易维护。但它的陷阱在于：MySQL/PostgreSQL 对 UNION 各子查询的列类型会取“最宽类型”，比如一个子查询用 VARCHAR(20)，另一个用 VARCHAR(100)，结果列类型变成 VARCHAR(100)——看似没问题，但若目标字段是 VARCHAR(50)，插入时就会截断。
关键控制点：
- 每个子查询都用
CAST(... AS target_type)显式转为目标字段类型 - 用
NULL AS field_name补齐缺失字段，别用空字符串或 0，否则类型推导会偏移 - 避免在
UNION ALL中混用''和NULL表示空值，统一用NULL并设目标列为NULLABLE - 先跑
SELECT * FROM (...) AS tmp LIMIT 10看实际结果列类型和值，再执行插入
字段映射这件事，没人能替你做判断；类型转换和空值策略一旦定错，数据污染就是不可逆的。
