异步导出不应开启事务，因其本质是只读+批量IO，非业务原子操作；开启事务会拉长生命周期、加剧锁竞争与MVCC膨胀，破坏一致性；正确做法是依赖MySQL可重复读隔离级别下的自动快照机制，确保所有SELECT复用同一连接与事务快照，禁用任何写操作。
异步导出不能开事务，开了反而破坏一致性
导出类操作本质是只读+批量IO，不是业务原子操作；一旦套进事务，会拉长事务生命周期，导致锁持有时间剧增、MVCC快照膨胀、其他写事务被阻塞。GORM里用 db.Transaction 包裹导出逻辑，是典型误用。
真正需要的不是“事务”，而是“一致性的读视图”。MySQL默认的可重复读（RR）隔离级别下，每个查询开始时自动获取一个事务快照（snapshot），只要整个导出过程在同一个数据库连接内完成、不跨连接重连，就能天然保证快照一致性。
- 导出前显式执行
BEGIN或调用db.Begin()是危险操作，尤其在连接池场景下极易复用连接，造成意外锁表或长事务 - 如果导出要关联多张表（如订单+用户+商品），必须确保所有
SELECT都在同一连接上执行，避免不同连接拿到不同时间点的快照 - GORM 的
Session(&gorm.Session{PrepareStmt: true})不影响快照，但能复用预编译语句，对大批量导出有轻微性能收益
GORM 导出时怎么保证快照一致性读取
不需要额外加锁，也不用改隔离级别。关键在于让所有 SELECT 共享同一个事务快照——这由 MySQL 自动保障，前提是：不主动提交、不新开连接、不触发隐式提交（如 DDL 语句）。
常见错误是边查边写日志或更新导出状态，比如：db.First(&order).Error; db.Model(&Log{}).Create(&log) —— 第二句会隐式提交当前事务（如果没显式开启），导致后续查询拿到新快照，破坏一致性。
- 导出全程只做
SELECT，禁用任何INSERT/UPDATE/DELETE操作 - 避免在导出循环中调用
db.Create()、db.Save()等写操作，哪怕只是记录进度 - 若必须记录进度，改用外部系统（如 Redis incr）或导出完成后统一写入
- 确认数据库连接未被中间件或日志库偷偷关闭重连（检查是否用了
db.Session(&gorm.Session{NewDB: true})）
什么时候才真要加锁？别和导出混为一谈
Shared Lock（LOCK IN SHARE MODE）只适用于「读完立刻要改」的强一致性校验场景，比如优惠券核销前查剩余数量并锁定该行。导出是纯读、无后续修改，加锁只会徒增锁等待、降低并发吞吐。
GORM 中唯一合法使用方式是：Clauses(clause.Locking{Strength: clause.LockingStrengthShared})，且必须包裹在 db.Transaction 内。但导出场景下，这个组合毫无意义，还可能因全表扫描触发表锁。
-
Where("status = ?")没走索引 → MySQL 升级为表级 S 锁 → 整个导出卡死 - 用
Strength: "SHARED"或"READ"→ GORM 静默忽略，生成的 SQL 没有LOCK IN SHARE MODE - 在非事务上下文中调用 Shared Lock → MySQL 直接忽略锁声明，行为不可控
导出性能与安全边界在哪
大批量导出真正的瓶颈从来不是快照机制，而是内存占用和网络传输。GORM 默认把全部结果加载进内存再序列化，10 万行用户数据轻松吃掉 500MB+ 内存。这时候“一致性”还在，但服务已经 OOM 了。
- 用
Rows()+Scan()流式读取，每批处理 1000 行后 flush 到文件，避免内存爆炸 - 禁止在导出中用
Preload加载深层关联，会导致 N+1 查询或笛卡尔积膨胀 - 如果必须导出关联数据，先用原生 SQL JOIN +
Rows()，比 GORM 的结构体映射更可控 - 注意 MySQL 的
max_allowed_packet，超大字段（如 JSON、TEXT）可能被截断而不报错
导出不是事务问题，是读视图 + 资源控制问题。快照一致性是 MySQL 的默认馈赠，别用事务把它变成枷锁；锁机制是给“读-改”闭环准备的，不是给“读-扔”流程设计的。
