Go中设置MySQL事务隔离级别必须使用BeginTx并传入sql.TxOptions，连接字符串中的tx_isolation仅影响默认会话行为，对显式事务无效；ReadOnly=true时Isolation字段被忽略，需预先设置会话级隔离级别。
Go 语言操作 MySQL 事务隔离级别，不是靠改连接字符串就能一劳永逸的事——sql.TxOptions 才是真正起效的控制点，而连接串里的 transaction_isolation 只影响默认会话级行为，对显式开启的事务无效。
Go 中设置事务隔离级别必须用 BeginTx，不能只靠连接串
很多人在 DSN 里加了 ?tx_isolation=READ-COMMITTED 或类似参数，却发现事务里读取行为没变化。这是因为：database/sql 的 Begin() 方法不接受隔离级别参数，它只会沿用当前连接的会话默认值；而 MySQL 默认是 REPEATABLE READ，哪怕你改了全局或会话级配置，Go 的 Begin() 仍可能复用旧连接，结果不可控。
真正生效的方式是调用 BeginTx() 并传入 *sql.TxOptions：
-
sql.TxOptions{Isolation: sql.LevelReadCommitted}→ 对应 MySQL 的READ COMMITTED -
sql.TxOptions{Isolation: sql.LevelRepeatableRead}→ 对应REPEATABLE READ（MySQL 默认） -
sql.TxOptions{Isolation: sql.LevelSerializable}→ 对应SERIALIZABLE
注意：sql.LevelReadUncommitted 在 MySQL 中虽存在，但实际会被降级为 READ COMMITTED（InnoDB 不支持真正意义上的脏读），不要依赖它做逻辑判断。
立即学习“go语言免费学习笔记（深入）”；
BeginTx 的 ctx 参数不是摆设，超时控制直接影响隔离效果
事务长时间挂起会导致锁堆积、连接池耗尽，尤其在 REPEATABLE READ 下，MVCC 版本链可能越拉越长，拖慢整个实例。所以 BeginTx 的第一个参数 context.Context 必须带超时：
- 用
context.WithTimeout(ctx, 5*time.Second)显式限制事务生命周期 - 避免直接传
context.Background()，否则出错时只能靠 MySQL 的innodb_lock_wait_timeout强制中断（默认 50 秒，太长） - HTTP 请求场景下，建议复用请求上下文，让事务随请求取消自动终止
如果事务内有外部 HTTP 调用或重试逻辑，更要提前规划超时边界——否则隔离级别再高，卡死的事务也等于没隔离。
读写分离场景下，ReadOnly: true 会绕过隔离级别设置
当你调用 BeginTx(ctx, &sql.TxOptions{ReadOnly: true, Isolation: sql.LevelReadCommitted})，MySQL 实际执行的是 START TRANSACTION READ ONLY，此时 Isolation 字段会被忽略。MySQL 会按会话当前的 transaction_isolation 值启动只读事务，而不是你传的值。
这意味着：
- 只读事务的隔离级别由连接初始化时的会话配置决定，不是
BeginTx参数 - 若你依赖只读事务做一致性快照，必须确保连接池创建后主动执行
SET SESSION transaction_isolation = 'READ-COMMITTED' - GORM 等 ORM 框架的
Session.ReadOnly()同样受此限制，不能靠方法链设隔离级
并发更新时，REPEATABLE READ 不等于“不会冲突”
MySQL 默认的 REPEATABLE READ 能防止脏读和不可重复读，但幻读依然存在；更重要的是，它不解决写冲突——两个事务同时更新同一行，后提交者会因锁等待超时或死锁被回滚，错误是 ERROR 1205 (HY000): Deadlock found when trying to get lock 或 ERROR 1213 (40001): Deadlock found when trying to get lock。
应对方式不是换隔离级别，而是：
- 按主键/唯一索引顺序更新，减少锁竞争范围
- 避免在事务中做非数据库操作（如发消息、调第三方 API），缩短持有锁时间
- 捕获
driver.ErrBadConn和死锁错误，实现指数退避重试（注意：仅限幂等操作）
把隔离级别当成“自动防冲突开关”是危险的。它控制的是读可见性，不是写协调机制。
真正难的不是选哪个隔离级别，而是确认你的业务逻辑在那个级别下是否真的满足一致性要求——比如“查余额→扣款”这个经典组合，在 READ COMMITTED 下仍可能被并发扣成负数，必须加 SELECT ... FOR UPDATE 或应用层分布式锁，光调高隔离级别解决不了问题。
