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