MySQL中SELECT默认是快照读，仅在REPEATABLE READ隔离级别下且无锁提示、不涉及更新时成立；READ COMMITTED下每次语句级快照，READ UNCOMMITTED可能读脏数据，加FOR UPDATE等则变为当前读。
MySQL 中 SELECT 默认是快照读还是当前读？
默认是快照读（Snapshot Read），但**仅限于可重复读（REPEATABLE READ）隔离级别下，且不带锁提示、不涉及更新语句时才成立**。它读的是事务启动瞬间的已提交数据版本，不阻塞其他事务写，也不被其他事务写阻塞。
容易踩的坑：SELECT 看似“无害”，但在 READ COMMITTED 下每次执行都重新获取最新快照；在 READ UNCOMMITTED 下甚至可能读到未提交的脏数据；而只要加了 FOR UPDATE 或 LOCK IN SHARE MODE，立刻变成当前读（Current Read），触发行锁或间隙锁。
-
REPEATABLE READ下，普通SELECT→ 快照读（依赖 undo log） -
SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE→ 当前读（查最新版 + 加锁） - 所有
UPDATE/DELETE/INSERT语句内部都会先做当前读 - 快照读不加锁，但不是“完全无代价”——MVCC 版本链遍历、undo log 清理压力仍存在
PostgreSQL 怎么实现类似 MySQL 的快照读？
PostgreSQL 没有“快照读/当前读”的显式概念，但**所有标准 SELECT 在默认隔离级别（READ COMMITTED）下，本质上就是语句级快照读**：每条 SELECT 执行时取一个事务快照，只看到该时刻前已提交的数据。
与 MySQL 关键差异在于：PG 不支持可重复读级别的“事务内多次 SELECT 结果一致”，它的 REPEATABLE READ 实际等价于串行化（SERIALIZABLE）的弱化版，遇到写冲突会报错 could not serialize access due to concurrent update，而不是静默返回旧值。
- PG 的
SELECT从不加锁（除非显式写FOR UPDATE），也不依赖 undo log，靠 tuple 的xmin/xmax系统字段判断可见性 - 想在 PG 中模拟 MySQL 的“事务级一致性快照”，必须用
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ，但要接受冲突失败风险 - PG 的 vacuum 机制直接影响快照有效性：长期不清理的死元组可能导致事务 ID 回卷或快照失效
Oracle 的 SELECT 为什么总像“快照读”？
Oracle 默认行为最接近“无条件快照读”：**只要没加 FOR UPDATE，所有 SELECT 都读取 SCN（系统变更号）对应的一致性读（CR）版本，不管隔离级别如何设置**。这是由其多版本并发控制（MVC）底层设计决定的，不是隔离级别开关控制的。
这意味着你在 READ COMMITTED 下执行两次 SELECT，可能得到不同结果（因为每次取最新 SCN）；而在 SERIALIZABLE 下，整个事务绑定到第一个查询的 SCN，后续 SELECT 都复用它——这才是真正事务级快照。
- Oracle 不提供 MySQL 那种“
REPEATABLE READ下自动事务快照”，得靠SERIALIZABLE显式开启 - 长时间运行的查询可能遭遇
ORA-01555: snapshot too old，本质是 undo 数据被覆盖，说明快照不可用了 - 即使没锁，长事务仍会阻止 undo 段回收，间接影响其他事务性能
跨数据库写业务逻辑时最容易忽略的一点
开发者常以为“不加锁的 SELECT 就安全”，但实际是否读到一致数据，取决于三个隐性变量：隔离级别、事务生命周期、底层 MVCC 实现机制。MySQL 的快照绑定在事务启动点，PG 绑定在语句启动点，Oracle 则分情况绑定在语句或事务起始 SCN —— 同一条 SQL，在不同库中可能产生完全不同的可见性行为。
尤其当业务依赖“两次读取结果相同”来判断状态时（比如先查余额再扣款），必须显式确认当前数据库的快照边界在哪，而不是只看有没有写 FOR UPDATE。
