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

发布时间:2024年01月14日


?


一.场景

场景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. 选择合适的同步策略,例如只进行增量同步或者只进行全量同步,根据数据的变化频率和一致性要求来决定。
文章来源:https://blog.csdn.net/qq_58148854/article/details/135585930
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。