Oracle数据库的锁机制本身是为了保证数据一致性而设计的，但在实际生产环境中，锁却经常成为业务卡顿甚至系统瘫痪的罪魁祸首。一条没有提交的UPDATE语句，可能让后续所有访问该行的请求全部挂起；一个缺失索引的外键，可能在并发删除时把整张子表锁死。要避免Oracle数据库表被锁定，首先要理解锁的底层机制，然后从应用设计、SQL写法和运维监控三个层面系统性地预防。
一、先搞清楚Oracle的锁机制：为什么表会被锁住
Oracle的锁按照粒度主要分为两类：行级锁（TX锁）和表级锁（TM锁）。Oracle在执行DML操作时，从不会因为行数太多而直接升级为块锁或页锁，这一点和SQL Server不同。Oracle锁定的最小单位就是行，通过事务槽（ITL）中记录的事务ID来实现。当用户执行UPDATE或DELETE时，被修改的行会被加上行级锁，同时对应的表上会加一个Row Exclusive模式的表级锁。
真正的问题往往不是行级锁本身，而是事务未提交。行级锁会一直持有到事务结束（COMMIT或ROLLBACK），如果应用代码开启了事务却长时间不提交，比如某个程序逻辑卡死、网络断开后会话挂起，其他会话要修改同一行就必须排队等待。默认情况下等待是没有超时的，于是前端表现就是请求一直转圈，数据库里出现大量会话处于ACTIVE或INACTIVE但持有锁的状态。
另一个容易忽视的机制是锁的兼容性矩阵。表级锁共有六种模式：Row Share、Row Exclusive、Share、Share Row Exclusive、Exclusive等。常见的问题场景是：某个会话执行了LOCK TABLE ... IN SHARE MODE，或者通过未建索引的外键触发了对子表的表级锁，导致其他会话的DML被阻塞。理解这些模式之间的兼容关系，是排查锁冲突的基础。
二、导致锁表的四大常见场景及规避方法
1. 长事务未提交，行级锁长期持有
这是生产环境中最常见的锁表原因。典型情况是应用里某个循环批量更新数据，整个循环包在一个大事务里，更新了百万行才提交一次。期间所有涉及这些行的并发请求全部阻塞，最终出现大面积超时。规避方法是缩短事务边界：把大事务拆成小批次，每处理500到1000行就提交一次。这样即使中间失败，回滚代价也小，锁持有时间也大幅缩短。
-- 反例：一次性更新百万行，锁持有时间极长
UPDATE orders SET status = 'CLOSED' WHERE create_date < SYSDATE - 365;
-- 正例：分批提交，每次1000行
DECLARE
v_rows NUMBER := 1000;
BEGIN
LOOP
UPDATE orders
SET status = 'CLOSED'
WHERE status != 'CLOSED'
AND create_date < SYSDATE - 365
AND ROWNUM <= 1000;
EXIT WHEN SQL%ROWCOUNT = 0;
COMMIT; -- 每批提交一次，及时释放行锁
END LOOP;
COMMIT;
END;
/2. 外键没有索引，引发子表级锁冲突
这是一个非常经典的坑。当父表和子表之间存在外键约束，而子表的外键列上没有索引时，对父表主键执行DELETE或UPDATE，会导致Oracle对子表执行全表扫描来检查约束，期间会对子表加上Share模式的表级锁，直接阻塞子表上的一切DML。解决方法很简单：给所有外键列建立索引。可以用下面的SQL找出缺失索引的外键列：
-- 查找没有对应索引的外键列
SELECT c.table_name,
cc.column_name,
c.constraint_name
FROM user_constraints c
JOIN user_cons_columns cc
ON c.constraint_name = cc.constraint_name
WHERE c.constraint_type = 'R'
AND NOT EXISTS (
SELECT 1
FROM user_ind_columns ic
WHERE ic.table_name = c.table_name
AND ic.column_name = cc.column_name
AND ic.column_position = cc.position);
3. SELECT FOR UPDATE使用不当
应用中常用SELECT ... FOR UPDATE来锁定要修改的行，防止并发修改。但如果加上FOR UPDATE后长时间不提交，同样会阻塞其他会话。在高并发场景下，推荐使用FOR UPDATE NOWAIT或SKIP LOCKED：NOWAIT表示拿不到锁立即报错返回，让应用有机会重试；SKIP LOCKED则直接跳过被锁定的行，非常适合多进程消费任务队列的场景。
-- 拿不到锁立即返回错误，避免会话无限等待 SELECT * FROM task_queue WHERE status = 'PENDING' AND ROWNUM <= 10 ORDER BY id FOR UPDATE SKIP LOCKED;
4. DDL操作与在线业务冲突
执行ALTER TABLE、CREATE INDEX等DDL语句时，Oracle需要先获取表的排他锁。如果此时有未提交的事务持有该表的锁，DDL语句会等待；反过来，DDL一旦开始排队，后续所有针对该表的DML也会被挂起，形成连锁阻塞。规避方法：DDL操作安排在业务低峰期执行；建索引用ONLINE关键字减少锁影响；执行前先用DDL_LOCK_TIMEOUT参数控制等待行为，避免DDL无限期排队。
-- 设置DDL锁等待超时为10秒，拿不到锁就报错而不是无限等待 ALTER SESSION SET DDL_LOCK_TIMEOUT = 10; -- 在线索引创建，不阻塞DML CREATE INDEX idx_orders_cust ON orders(customer_id) ONLINE;
三、锁表发生了怎么办：定位与处理的实战方法
预防做得再好，也难免出现突发锁表。快速定位的关键是几个动态性能视图。v$session里的blocking_session字段直接告诉你谁在阻塞谁，这是最直接的入口。v$locked_object结合dba_objects可以看到哪些对象被哪些会话锁定。查询锁等待链的常用SQL如下：
-- 查询当前被阻塞的会话及其阻塞源
SELECT s.sid,
s.serial#,
s.username,
s.machine,
s.status,
s.last_call_et / 60 AS wait_minutes,
s.blocking_session,
s.sql_id,
q.sql_text
FROM v$session s
LEFT JOIN v$sql q ON s.sql_id = q.sql_id
WHERE s.blocking_session IS NOT NULL
ORDER BY wait_minutes DESC;
找到阻塞源头后，如果确认该会话是僵死连接或异常事务，可以用ALTER SYSTEM KILL SESSION终止它。杀会话前务必确认：这个会话对应的应用能否安全中断，是否是主库上的关键任务。如果会话被杀后状态长期为KILLED且锁未释放，说明事务还在回滚中，需要等待回滚完成，此时切不可强行重启数据库，回滚时间取决于事务修改的数据量。
-- 杀掉阻塞源会话，sid和serial#来自上面的查询 ALTER SYSTEM KILL SESSION '1025, 33001' IMMEDIATE;
四、从事后处理到事前预防：建立长效防护机制
运维层面，建议部署定期的锁监控脚本，通过DBMS_SCHEDULER每分钟扫描v$session中blocking_session非空的会话，发现锁等待超过阈值（比如5分钟）就告警并自动记录现场，包括阻塞SQL、会话信息、锁类型，方便事后复盘。
应用层面，要建立几个开发规范：第一，所有事务必须在方法结束时显式提交或回滚，禁止依赖连接关闭时的隐式处理；第二，禁止在事务中间调用外部接口或执行耗时逻辑，外部调用一律放到事务外；第三，外键列建索引纳入数据库设计评审 checklist；第四，批量操作必须分批提交并写入操作日志，便于中断续跑。
架构层面，如果业务并发极高且锁冲突集中在热点行，可以考虑改造方案：用队列把对热点数据的修改串行化，或者在应用层用Redis做分布式锁替代数据库行锁，让数据库只承担数据存储而非并发控制。对于OLAP类的大批量查询，使用SET TRANSACTION READ ONLY或闪回查询（AS OF TIMESTAMP）代替长事务，读操作完全不加锁，从根源上消除读写阻塞。
总结来说，避免Oracle表被锁定，核心思路是让锁的持有时间尽可能短、锁的范围尽可能小。理解TX锁和TM锁的工作方式，管好事务边界，补上外键索引，规范DDL操作窗口，再配上一套快速定位锁等待的运维脚本，绝大多数锁表故障都可以提前化解。