Go中SELECT查询引发锁问题：NOLOCK与只读事务选哪种？

核心区别对比 #

• NOLOCK（READ UNCOMMITTED）：

  • 直接读取磁盘上的未提交数据（脏读），不会对目标表加共享锁，也不会被写锁阻塞，但可能返回不一致结果（比如读到半修改的行、已标记删除但未提交的行）。
  • SQL写法：SELECT * FROM [pipe].[Message] WITH (NOLOCK) ...

• 只读事务（READ ONLY）：

  • 若数据库开启了READ_COMMITTED_SNAPSHOT或ALLOW_SNAPSHOT_ISOLATION，事务会读取启动时刻的一致性快照数据，完全避免脏读。
  • 不持有长期共享锁，写操作不会阻塞该事务，该事务也不会阻塞写操作，从根源减少锁冲突。
  • Go中需通过BeginTx传入只读选项实现，无需修改SQL语句本身。

最优实践建议 #

优先选择只读事务，除非你的业务场景完全能接受脏读（比如非核心的日志统计、临时数据查询），理由如下：

1. 数据正确性：只读事务保证读取的是一致的已提交数据，NOLOCK的脏读可能导致业务逻辑出错（比如读取到无效的订单状态、重复数据）。
2. 锁冲突解决：快照隔离彻底避免了读写锁竞争，比NOLOCK的“跳过锁检查”更可靠，不会带来潜在的数据风险。
3. 生态兼容性：Go中通过事务设置只读是标准操作，便于统一管控隔离级别，无需在SQL中硬编码NOLOCK，维护性更强。

针对你的查询语句的额外优化 #

• 替换SELECT *为业务实际需要的列，减少数据传输量和IO开销，间接缩短查询耗时。
• 确保MessageID列存在降序索引，让ORDER BY [MessageID] DESC直接利用索引排序，避免额外的排序操作，提升查询效率的同时缩短事务周期。

Go中开启只读事务的示例代码：

tx, err := db.BeginTx(context.Background(), &sql.TxOptions{
    ReadOnly: true,
})
if err != nil {
    // 处理错误逻辑
}
defer tx.Rollback() // 只读事务无需Commit，Rollback即可释放资源

rows, err := tx.Query(`
    SELECT MessageID, Content -- 替换为你需要的具体列
    FROM [pipe].[Message]
    ORDER BY [MessageID] DESC OFFSET 0 ROWS 
    FETCH NEXT 100 ROWS ONLY
`)
// 处理查询结果、关闭rows等逻辑...

内容的提问来源于stack exchange，提问作者CoderSchmoder