迁移时直接导出 SQL 会丢事务吗？
不会自动丢，但默认
mysqldump不保证每个事务都完整包裹在
BEGIN/
COMMIT中。它按表导出，每张表内部语句是连续执行的，但跨表操作（比如转账涉及用户表和流水表）一旦被拆到不同文件或分批导入，就失去原子性。
关键看迁移方式：
单库整库导出 + 单次导入：靠 MySQL 自身恢复机制（如 binlog 或 crash-safe DDL）保障一致性，但前提是源库在导出期间无写入，否则快照不一致 逻辑复制（如mysqlbinlog+ 过滤重放）：能保留事务边界，但要求源库开启
binlog_format=ROW且
binlog_row_image=FULL物理拷贝（如
Percona XtraBackup）：直接复制数据文件，事务完整性由备份时刻的 InnoDB redo log 状态决定，恢复后自动前滚/回滚
mysqldump 怎么加事务包装？
用
--single-transaction参数可让
mysqldump在 InnoDB 表上启动一个一致性快照，所有表导出基于同一时刻数据，避免锁表又保持逻辑一致。但它本身不给每个 INSERT 加
BEGIN/
COMMIT包裹——那是导入端的事。
真正需要事务包装的场景，是导入时想把整个 dump 文件当一个事务执行（比如防止中途失败导致半截数据）。这时必须手动处理：
导出时加--skip-extended-insert（每行一个 INSERT），再用脚本在开头加
BEGIN、结尾加
COMMIT导入时不走
mysql命令行默认的自动提交，而是显式关闭：
mysql --init-command="SET autocommit=0" -e "source dump.sql; COMMIT;"注意：大文件这么做风险高，可能触发
max_allowed_packet或锁等待超时，
innodb_log_file_size也要足够大
跨版本或跨引擎迁移时事务行为怎么变？
MySQL 5.7 升 8.0 或迁移到其他存储引擎（如 MyISAM → InnoDB）时，事务支持不是“继承”的。MyISAM 表无论怎么 dump 都不支持事务，导入到 InnoDB 后才具备 ACID 能力，但历史数据已无回滚点。
容易踩的坑：
CREATE TABLE语句里没显式指定
ENGINE=InnoDB，目标库默认引擎可能是 MyISAM（尤其老配置），导致后续 INSERT 不进事务 8.0 默认
sql_mode更严格（含
STRICT_TRANS_TABLES），某些 5.7 允许的脏数据在导入时直接报错中断事务 GTID 模式下迁移需额外处理
gtid_purged，否则从库同步可能跳过部分事务，表面成功实则丢数据
如何验证迁移后事务是否真没丢？
不能只查行数或校验和。得模拟业务关键事务路径做端到端验证：
选几笔带强事务语义的操作（如“扣余额 + 写日志 + 更新状态”三步），在源库执行后记录主键和时间戳，迁移完立刻在目标库查这组数据是否全部存在、状态一致、时间戳未倒退 检查information_schema.INNODB_TRX和
INNODB_LOCK_WAITS（迁移后立即查），确认没有残留长事务或死锁痕迹 如果用了逻辑复制，比对源库
SHOW MASTER STATUS和目标库
SHOW SLAVE STATUS\G中的
Exec_Master_Log_Pos和
Relay_Master_Log_File，确保无延迟且无跳过事件
最隐蔽的问题往往出在隐式提交：比如导入过程中执行了
ALTER TABLE或
CREATE INDEX，会自动提交当前事务——这种操作在 dump 文件里容易被忽略，却会切断事务链。
