你说的没错——Oracle普通SELECT查询默认不会被行级写锁阻塞，因为它靠**一致性读（Consistent Read）**从undo段构建查询启动时的数据快照，不用等锁释放。但如果碰到表级锁（比如正在执行ALTER TABLE这类DDL），或是特殊锁场景，还是可能出现阻塞。既然你不关心实时数据，只需要正确的快照，这几个方法绝对能帮到你：

1. 开启只读事务 #

这是最直接的方案：一旦启动只读事务，整个事务内的所有查询都会基于事务开始时的数据快照，完全不受后续写操作干扰，同时不会给表加任何锁，不影响其他业务。

用法非常简单：

-- 开启只读事务
SET TRANSACTION READ ONLY;

-- 运行你的多条查询
SELECT * FROM your_table WHERE ...;
SELECT COUNT(*) FROM your_table WHERE ...;

-- 结束事务（只读事务必须提交/回滚，不会产生数据变更）
COMMIT;

这个方法的优势是，同事务内的所有查询共享同一个时间点的快照，数据一致性有保障。

2. 闪回查询（Flashback Query） #

如果不想开启事务，或者需要指定某个特定时间点的快照，闪回查询是绝佳选择。它允许你直接查询过去某一时刻的表数据，完全独立于当前写操作，不会被任何锁阻塞。

用法示例：

-- 查询10分钟前的数据快照
SELECT * FROM your_table AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' MINUTE;

-- 用SCN（系统变更号，更精确）查询
SELECT * FROM your_table AS OF SCN 123456789;

你可以按需调整时间间隔（比如INTERVAL '1' HOUR就是1小时前的快照）。如果需要获取当前SCN，可执行SELECT CURRENT_SCN FROM V$DATABASE;。

3. 排查阻塞根源（可选） #

如果你想确认是不是真的有锁在阻塞查询，可以先查一下当前的阻塞会话：

-- 查询当前阻塞关系及对应SQL
SELECT
  blocking_session AS 阻塞会话ID,
  session_id AS 当前会话ID,
  username AS 会话用户,
  sql_text AS 执行SQL
FROM v$session
WHERE blocking_session IS NOT NULL;

这样就能快速定位是不是有其他长事务持有锁导致你的查询被卡。

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