怎么判断数据库是不是锁了？有哪些常用排查方法？

在数据库管理与运维过程中,锁是一个无法回避的核心概念，它既是保障数据一致性与并发控制的关键机制，也可能成为性能瓶颈的罪魁祸首，当应用程序响应缓慢、操作超时或大量请求堆积时，排查数据库是否存在锁等待，往往是定位问题的首要步骤，本文将系统性地介绍如何判断数据库是否被锁，并提供主流数据库的具体排查方法。

理解数据库锁的本质

数据库锁的本质是一种并发控制机制,用于管理对共享资源的访问，当一个事务（或会话）正在修改某份数据时，它会申请一个锁，以防止其他事务同时修改相同的数据，从而避免数据损坏或不一致，常见的锁类型包括共享锁和排他锁，问题通常不在于锁的存在，而在于锁的等待与争用，即一个事务长时间持有锁，导致其他事务被迫等待，形成阻塞链。

主流数据库的锁查询方法

不同的数据库管理系统提供了不同的工具和视图来查询锁状态,掌握这些命令是数据库管理员的基本功。

MySQL

对于广泛使用的InnoDB存储引擎,可以通过查询information_schema库下的几张表来获取锁信息。

查看当前事务等待关系：
```
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
```
这张表清晰地展示了哪个事务正在等待另一个事务释放锁,通过requesting_trx_id（请求锁的事务ID）和blocking_trx_id（持有锁的事务ID）可以快速定位阻塞源头。
查看具体的锁信息：
```
SELECT * FROM information_schema.INNODB_LOCKS;
```
此表列出了当前所有未被释放的锁的详细信息,包括锁所在的数据表、锁的类型（如S, X）、锁住的索引记录等。
使用SHOW ENGINE INNODB STATUS：
这是一个非常强大的诊断命令，其输出结果中的“LATEST DETECTED DEADLOCK”部分会记录最近一次的死锁信息，而“TRANSACTIONS”部分则会展示当前活跃事务和锁等待的详细情况。

PostgreSQL

PostgreSQL提供了pg_locks系统视图，它是查询锁状态的核心。

查看所有锁信息：
```
SELECT * FROM pg_locks;
```
pg_locks视图中的granted字段是关键，如果为false，则表示该进程正在等待锁。pid字段是进程ID，可以与pg_stat_activity视图关联，以获取执行锁操作的SQL语句。

定位阻塞会话与被阻塞会话：
一个实用的查询是将pg_locks与自身进行关联，找出等待关系：

SELECT blocked_locks.pid AS blocked_pid,
       blocked_activity.usename AS blocked_user,
       blocking_locks.pid AS blocking_pid,
       blocking_activity.usename AS blocking_user,
       blocked_activity.query AS blocked_statement,
       blocking_activity.query AS current_statement_in_blocking_process
FROM pg_catalog.pg_locks blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

SQL Server

SQL Server提供了动态管理视图（DMV）和系统存储过程来监控锁。

使用sys.dm_tran_locks视图：
这是查看锁信息的首选方法，它返回当前活动的锁管理器资源信息。
```
SELECT resource_type, resource_associated_entity_id, request_mode, request_session_id
FROM sys.dm_tran_locks;
```
request_mode表示锁的类型（如S, X, IX），request_session_id是会话ID。

结合sys.dm_exec_sessions和sys.dm_exec_sql_text：
为了获取更完整的信息，如会话登录名、执行的SQL文本等，可以进行关联查询：

SELECT t1.resource_type,
       t1.resource_database_id,
       t1.request_mode,
       t1.request_session_id,
       t2.login_name,
       t3.text
FROM sys.dm_tran_locks AS t1
INNER JOIN sys.dm_exec_sessions AS t2
    ON t1.request_session_id = t2.session_id
CROSS APPLY sys.dm_exec_sql_text(t2.most_recent_sql_handle) AS t3;

使用表格快速对比

为了方便快速查阅,下表小编总结了上述数据库的核心查询工具：

数据库类型	核心查询命令/视图	关键信息
MySQL (InnoDB)	`information_schema.INNODB_LOCKS` / `INNODB_LOCK_WAITS`	事务ID、锁模式、锁定的表、阻塞关系
PostgreSQL	`pg_locks`	进程ID、锁模式、是否已授予
SQL Server	`sys.dm_tran_locks`	资源类型、请求模式、会话ID

发现锁之后怎么办？

定位到锁只是第一步,更重要的是解决问题，通常的流程是：

识别“元凶”：通过上述查询，找到持有锁且阻塞了其他会话的那个进程或事务。
分析原因：查看该进程正在执行的SQL语句，是事务未及时提交？是执行了全表扫描？还是业务逻辑本身就需要长时间运行？
谨慎决策：如果确认该会话可以终止，可以使用KILL命令（如MySQL的KILL [process_id]）来强制释放锁，但在生产环境中，这通常是最后手段，最好先与应用开发人员沟通，评估影响，长远来看，优化SQL、减少事务执行时间、合理设计索引才是治本之策。

怎么判断数据库是不是锁了？有哪些常用排查方法？

理解数据库锁的本质