一、基本概念：MySQL 的两种“读”法

在 Mysql 中，并非所有 SELECT 都一样。根据是否加锁、是否读最新数据，分为两类：

快照读（Snapshot Read）

• 定义：读取事务开始时（或语句开始时）的一致性视图（Read View），不加任何锁。

• 典型语句：

  SELECT * FROM orders WHERE user_id = 1001;

• 底层机制：基于 MVCC（多版本并发控制），通过 undo log 构建历史版本。

• 特点：

• 读不阻塞写，写不阻塞读；

• 在 RR 隔离级别下，整个事务看到同一快照（可重复读）；

• 在 RC 级别下，每次 SELECT 都生成新快照（不可重复读）

当前读（Current Read）

• 定义：读取数据库中最新的、已提交的数据，并加锁以防止其他事务修改。

• 典型语句：

  SELECT * FROM orders WHERE user_id = 1001 FOR UPDATE;        -- 排他锁
  SELECT * FROM orders WHERE user_id = 1001 LOCK IN SHARE MODE; -- 共享锁（MySQL 8.0+ 可用 FOR SHARE）
  UPDATE orders SET status = 'paid' WHERE id = 123;
  DELETE FROM orders WHERE id = 123;

• 底层机制：直接访问聚簇索引或二级索引的最新记录，并根据隔离级别加 记录锁 / 间隙锁(RR) / Next-Key Lock。

• 特点：

• 会阻塞其他写操作（甚至读操作，取决于锁类型）

• 是实现“悲观锁”和防止并发冲突的关键手段。
  
  

快照读 = 安静地看历史；当前读 = 大声宣布“我要改这里，请别动！”

二、使用场景：什么时候该用哪种读？

场景 1：只读查询 → 用快照读

• 用户查看订单列表、商品详情等；

• 对数据一致性要求不高，或能接受“稍旧”数据；

• 优势：零锁开销，高并发无压力。

场景 2：先查后改（Check-Then-Act）→ 必须用当前读！

// 伪代码：错误示范（快照读）
Order order = select("SELECT * FROM orders WHERE id = 123"); // 快照读
if (order.status == "unpaid") {
    update("UPDATE orders SET status = 'paid' WHERE id = 123");
}

 问题：两个线程同时执行，都看到 status=unpaid，导致重复支付！

正确做法（当前读）：

-- 加锁读取最新状态（仅用来体现当前读的作用，高并发场景下不建议使用 FOR UPDATE）
SELECT * FROM orders WHERE id = 123 FOR UPDATE;
-- 再判断并更新

三、避坑指南

问题 1：FOR UPDATE 导致大量阻塞甚至死锁

• 原因：范围查询未走索引，InnoDB 在 RR 下对主键全表加间隙锁；

• 案例：

  SELECT * FROM orders WHERE create_time > '2024-01-01' FOR UPDATE; -- create_time 无索引

• 快照读 让读操作如丝般顺滑；

• 当前读 为写操作筑起安全防线。

但在实际开发中，最大的风险不是技术本身，而是“不知道自己在用哪种读”。

下次当你写下 SELECT 时，不妨多想一步 “我需要的是历史快照，还是此刻的真实？”

参考文章：原文链接​