mysql迁移中insert...select丢数据主因是innodb与myisam引擎混用：myisam不参与事务，出错时innodb回滚而myisam已写入，导致“只写一半”；需统一引擎、校验sql_mode、避免隐式字符集转换，并注意alter table engine转换过程及auto_increment行为差异。
MySQL 迁移时 INSERT ... SELECT 丢数据，先查存储引擎是否混用
InnoDB 和 MyISAM 对事务、自动提交、锁机制的处理完全不同，跨引擎执行 INSERT ... SELECT 时，MyISAM 表不会参与事务，一旦中途出错，InnoDB 那边回滚了，MyISAM 已写入的数据就留在那里——看起来像“丢数据”，其实是“只写一半”。
- 迁移前统一用
SHOW CREATE TABLE `table_name`检查源表和目标表的ENGINE=值，别只看建表语句里写了什么，实际可能被配置覆盖 - 如果目标是 InnoDB 表，但
SELECT来源是 MyISAM，且语句里没加SET autocommit=0或显式事务包裹，就别指望原子性 - MyISAM 不支持外键和行级锁，
INSERT ... SELECT过程中若并发写源表，可能读到不一致快照（尤其没加LOCK TABLES）
mysqldump 导出再导入，--skip-extended-insert 会放大丢失风险
默认 mysqldump 用批量 INSERT（多值一行），恢复时单条失败整个语句跳过；加了 --skip-extended-insert 后变成每行一条 INSERT，看似更可控，实则在 MyISAM 表上更容易因某一行字段超长、编码不匹配等问题静默跳过——错误日志里只报 warning，不中断导入。
- 用
mysqldump --single-transaction导出 InnoDB 表（保证一致性），但该参数对 MyISAM 无效，导出时需配合--lock-tables - 导入前确认目标库
sql_mode和源库一致，尤其注意STRICT_TRANS_TABLES是否开启——MyISAM 在非严格模式下会截断超长字符串并吞掉 warning - 导入命令末尾加
2>&1 | grep -E "(error|warning)"，别只看 “Query OK”
ALTER TABLE ... ENGINE=InnoDB 转换后数据“消失”，其实是没等完成就查
MyISAM 转 InnoDB 是重建表过程：拷贝数据 → 建索引 → 替换原表。期间原 MyISAM 表仍可读写，但新 InnoDB 表在 ALTER 完成前不可见；如果脚本里 ALTER 后立刻 SELECT COUNT(*)，而没检查 SHOW PROCESSLIST 或 INFORMATION_SCHEMA.PROCESSLIST 状态，就可能误判为数据丢失。
-
ALTER TABLE t ENGINE=InnoDB在大表上可能耗时几分钟，执行完SHOW TABLE STATUS LIKE 't'确认Engine字段已变，且Rows不为 NULL - 转换过程中，
information_schema.TABLES的TABLE_ROWS对 InnoDB 是估算值，别拿它和 MyISAM 时期的精确值比 - 如果用 Percona Toolkit 的
pt-online-schema-change，它默认不改存储引擎，要显式加--alter "ENGINE=InnoDB"参数
从 MyISAM 迁到 InnoDB，auto_increment 值不连续不是 bug
MyISAM 把 AUTO_INCREMENT 值存在文件头，重启不丢；InnoDB 存在内存里，启动时靠扫描最大值重新计算。迁移后第一次插入，如果旧 MyISAM 表最大 ID 是 1000，InnoDB 可能只设到 950（取决于上次 checkpoint 位置），后续插入就会从 951 开始——看着像“倒退”，其实是正常行为，不影响数据完整性。
- 迁移后立即执行
ALTER TABLE t AUTO_INCREMENT = (SELECT MAX(id)+1 FROM t)强制重置（需确保无并发写入） - 不要依赖
AUTO_INCREMENT值做业务逻辑判断，比如“ID > 1000 就是新数据”，InnoDB 下这不可靠 - 如果应用代码里硬编码了 MyISAM 的锁表逻辑（如
LOCK TABLES t WRITE），迁到 InnoDB 后得删掉——InnoDB 行锁自动处理，并发写时留着反而导致死锁
真正容易被忽略的是字符集隐式转换：MyISAM 表用 utf8（即 utf8mb3），InnoDB 目标表用 utf8mb4，但列定义没同步改，插入含 emoji 的数据时会被截断，且不报错——得查 SHOW WARNINGS，而不是只看 ROW_COUNT()。
