mysql中批量insert默认不回滚已成功语句，必须显式开启事务并手动控制；若需局部回滚，应使用savepoint标记后执行rollback to savepoint。
批量插入失败时，事务默认不自动回滚部分语句
SQL 标准下，INSERT 语句一旦出错（比如主键冲突、字段类型不匹配），当前语句会失败，但**已成功执行的前序插入不会自动撤销**——除非你显式开启并控制事务。很多人误以为“一条失败整批丢”，实际恰恰相反：没加事务包裹的批量 INSERT 是“各扫门前雪”，失败只停在那条，前面的照常落库。
常见错误现象：INSERT INTO t VALUES (1,'a'),(2,'b'),(3,'a'); 中第三条因唯一约束失败，但 (1,'a') 和 (2,'b') 已写入表中。
- 必须用
BEGIN TRANSACTION/START TRANSACTION显式开启事务（MySQL/PostgreSQL 语法略有差异） - 所有要“共进退”的
INSERT必须在同一事务块内，且在失败后手动执行ROLLBACK - 不要依赖客户端自动提交模式（如 MySQL 默认
autocommit=1），它会让每条语句独立提交
用 SAVEPOINT 实现“局部回滚”而非全事务放弃
如果一批数据中部分失败、但你想保留前面成功的记录，又不想整个事务重试，SAVEPOINT 是唯一可行路径。它允许你在事务内打点，失败时只回退到该点，不影响之前已确认的操作。
使用场景：导入日志、同步外部数据时，容忍个别脏数据，但需保证整体流程可控。
- 在关键分界处设点：
SAVEPOINT sp1;，之后执行一组INSERT - 若某条失败，立刻
ROLLBACK TO SAVEPOINT sp1;，再继续后续逻辑 - 注意：PostgreSQL 支持重复使用同名
SAVEPOINT，MySQL 要求先释放（RELEASE SAVEPOINT sp1;）再重建 - 别把
SAVEPOINT当异常捕获器——它不拦截错误，只是提供回退锚点，错误仍需应用层或存储过程里EXCEPTION/DECLARE HANDLER捕获
INSERT ... ON CONFLICT / INSERT IGNORE 不等于事务安全
INSERT IGNORE（MySQL）或 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）看起来能跳过冲突，但它们**只抑制特定错误，不解决原子性问题**。比如字段长度超限、非空约束失败等依然报错，且这些语句本身仍是单条执行单位。
参数差异明显：ON CONFLICT 需明确指定冲突列（如 ON CONFLICT (id)），而 INSERT IGNORE 依赖表的全部唯一/主键约束，行为更隐蔽。
- 它们不能替代事务：即使用了
IGNORE，前面已插入的行仍可能留在库里，后续语句失败也不会触发回滚 - 性能上，
ON CONFLICT在 PostgreSQL 中通常比SELECT + INSERT更高效，但大量冲突时锁竞争加剧 - MySQL 的
INSERT IGNORE在严格模式下可能转为警告而非静默忽略，需检查sql_mode
应用层批量插入务必绑定事务生命周期
ORM 或数据库驱动（如 Python 的 psycopg2、Java 的 JDBC）里，批量插入本质还是多条 INSERT 语句拼接或循环执行。是否回滚，完全取决于你是否把这批操作包在同一个事务对象里。
容易踩的坑是：循环中每插一条就 commit()，或忘记 rollback() 异常分支。
- Python 示例：
conn.autocommit = False后，用cursor.executemany(...)，再统一conn.commit()或conn.rollback() - JDBC 注意：
Connection.setAutoCommit(false)必须在获取Statement前设置，否则无效 - Node.js 的
pg库中，client.query('BEGIN')后所有查询需复用同一client，跨 client 就脱离事务上下文
真正难的不是语法，而是判断哪些数据必须强一致、哪些可以降级处理——这得看业务场景，而不是看 SQL 能不能写出来。
