数据库锁表原因、排查、解决

• 一.场景
  • 场景1
  • 场景2
• 二.原因
• 三.排查
• 四.解决方案

 

---

一.场景

场景1

锁表通常发生在DML（ insert 、update 、delete ）

A操作进行全量数据同步，对整个表的粒度进行上锁，导致B操作只能等待A操作完成才能进入插入数据。此时就出现了锁表问题。

场景2

DDL也会发生锁表
例如在 MySql 操作一张大表，利用 alter 语句修改或新增字段的时候，恰巧有一个长事务（包括读）在操作此表，会触发修改等待，造成锁表。

二.原因

当多个事务处理对多个资源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状态，从而造成其对资源需求的死锁，导致锁表。

三.排查

MYSQL 为例

执行 sql：

select * from information_schema.processlist where command not in (‘Sleep’) ORDER BY time desc

通过此命令也可以查询到 mysql 的慢 sql 语句，进行优化，info 字段即为具体执行的 sql 语句。

四.解决方案

以我遇到过的场景为例：cdc 全量同步锁表问题

CDC 全量同步锁表问题是指在使用 CDC 技术进行数据库同步时，为了保证数据的一致性，需要在全量同步阶段对源数据库的表或者整个数据库进行加锁，防止在同步过程中发生数据的变更。这种锁表问题可能会影响源数据库的性能和可用性，所以需要谨慎选择同步方案和时机。

CDC 全量同步锁表问题的解决方法可能因不同的 CDC 工具而有所不同，但一般都是通过以下几种方式：

1. 选择支持无锁全量同步的 CDC 工具，例如 Flink CDC 2.0，它可以通过并发读取、checkpoint、快照隔离等技术实现无锁全量同步，提高性能和可靠性。
2. 选择合适的锁级别和范围，例如 Debezium，它可以根据源数据库的类型和版本选择使用全局锁或者表锁，也可以通过配置参数来控制锁的范围和持续时间。
3. 选择合适的同步时机，例如在源数据库的低峰期或者维护期进行全量同步，避免影响正常的业务访问。
4. 选择合适的同步策略，例如只进行增量同步或者只进行全量同步，根据数据的变化频率和一致性要求来决定。