MySQL默认不自动回滚部分失败的多行INSERT,因默认autocommit=1,每条INSERT独立提交;仅当显式开启事务(BEGIN/START TRANSACTION)后,才能通过ROLLBACK整体回滚已执行的成功行。

MySQL 默认不自动回滚部分失败的多行 INSERT —— 除非你显式开启事务且没提交,否则“部分失败”根本不会触发回滚,而是由 SQL 模式和语句写法决定行为。
SQL 模式决定 INSERT 失败时是否中断整批
MySQL 的 sql_mode 直接控制多行 INSERT 遇到错误时的行为:
-
STRICT_TRANS_TABLES或STRICT_ALL_TABLES开启时:第一行违反约束(如主键重复、NOT NULL 缺值、类型超长)会报错并中止整个语句,后续行不插入,也不自动回滚——因为语句本身没执行完,没产生可回滚的变更 - 未开启严格模式时:出错行被跳过,其余行照常插入,且不报错(只发警告),
SHOW WARNINGS才能看到具体哪几行被忽略 - 检查当前模式:
SELECT @@sql_mode;生产环境强烈建议启用STRICT_TRANS_TABLES,避免静默丢数据
事务边界没包住 INSERT,ROLLBACK 就无效
即使你写了 ROLLBACK,如果 INSERT 不在事务里,它早就被自动提交了:
- MySQL 默认
AUTOCOMMIT = 1,每条INSERT是独立事务,执行完立刻落盘,ROLLBACK对它完全没作用 - 想让多行 INSERT 可整体回滚,必须显式控制事务:
BEGIN→INSERT ... VALUES (...),(...),(...)→COMMIT或ROLLBACK - 注意:如果 INSERT 过程中某行触发错误导致语句终止,但事务仍处于打开状态,此时
ROLLBACK才能撤回前面已成功插入的行(前提是引擎支持事务,如 InnoDB)
INSERT ... SELECT 中单行失败的处理逻辑不同
INSERT ... SELECT 是原子性语句,它的失败/忽略策略和普通多值 INSERT 不一样:
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
- 默认行为同上,受
sql_mode控制;但无法用IGNORE跳过单行错误,除非加INSERT IGNORE ... SELECT - 更可控的方式是用
ON DUPLICATE KEY UPDATE,把冲突转为更新,避免中断 - 若目标表有自增主键且源数据含空值,可能因
NO_AUTO_VALUE_ON_ZERO等隐式规则报错,需提前校验数据
真正“部分失败后整批回滚”的场景其实很窄
现实中所谓“整批回滚”,往往不是 MySQL 主动做的,而是开发者自己写的逻辑:
- 比如用程序分批次插入,某批中途报错,程序捕获异常后主动执行
ROLLBACK(前提是之前BEGIN了) - 或者用存储过程封装,配合
DECLARE EXIT HANDLER在出错时触发ROLLBACK - 单纯一条
INSERT INTO t VALUES (1),(2),(3)报错,MySQL 不会回滚已插入的行——因为那行根本没插成;只有在事务内连续执行多条 INSERT 语句,其中一条失败,你再手动ROLLBACK,才可能撤回前面成功的那些
最容易被忽略的是:InnoDB 表的碎片问题。批量插入后回滚(如大事务未提交就 ROLLBACK),会导致大量空闲页残留,innodb_file_per_table = ON 时表空间文件不会自动收缩,得靠 OPTIMIZE TABLE 或重建表来清理——这点和回滚行为无关,但常被误认为“回滚没生效”。










