探讨数据库事务并发时，锁机制始终是无法回避的核心议题。GBase 8s 借助多种锁粒度来协调并发访问，防止多个事务同时操作同一份数据时产生冲突，进而保障数据一致性。接下来，我们将详细拆解它的锁体系。
锁粒度的操作方式
GBase 8s 支持从行级到表级的多种锁级别，每种级别均对应不同的操作手段。
- 行级锁：粒度最细，专为高并发写入场景设计。设置方法十分简便：
ALTER TABLE tab1 LOCK MODE (ROW);
或在建表时直接指定：
CREATE TABLE tab1 (...) LOCK MODE ROW; - 页面锁：以数据库页面为锁定单位，粒度较行锁稍粗，但系统开销更低。同样支持动态修改或建表时指定：
ALTER TABLE tab1 LOCK MODE (PAGE);
CREATE TABLE tab1 (...) LOCK MODE PAGE; - 表级锁：分为自动与手动两种方式。自动上锁：在访问表数据时，数据库默认会给表加锁（读操作可能添加读锁，也可能不加），目的是防止其他事务修改表结构。手动上锁：通过显式的
LOCK TABLE语句实现控制，例如：
BEGIN WORK;
LOCK TABLE tab1 IN EXCLUSIVE MODE;
LOCK TABLE tab2 IN SHARE MODE;
UNLOCK TABLE tab1; - 索引键锁：属于自动行为，无法人为干预。前提条件是查询的表包含索引，且执行计划实际使用了该索引。索引键锁用于保护索引键值及其区间，有效避免幻读和一致性问题。
锁粒度的选择策略
不同粒度的锁各有其适用场景，合理选择能大幅提升并发性能。
- 库锁：独占式锁，用于数据库维护场景，例如备份、迁移等需要独占数据库的操作。
- 表级锁：适合批量更新或DDL操作，能有效规避并发冲突，但并发度较低。
- 页级锁：在并发性与管理开销之间取得平衡，适用于顺序访问较多的场景。
- 行级锁：OLTP系统的高并发利器，仅锁定被修改的行，最大限度提升并发能力。
- 索引键锁：保障索引操作完整性，防止并发插入或修改导致幻读，是数据库在索引层面施加的重要保护机制。
异常的锁等待情况
锁使用不当时，会出现两种典型的异常等待：活锁与死锁。
- 活锁：某个事务长时间等待锁资源，因为锁总是被其他事务抢先获取。解决办法十分简单——采用先来先服务（FIFO）排队机制，让等待者按顺序获取锁。
- 死锁：两个事务互相等待对方持有的资源，形成循环等待。例如：事务T1锁住资源R1，等待R2；事务T2锁住资源R2，等待R1。死锁的四个必要条件（互斥、持有并等待、不可剥夺、循环等待）必须同时满足才会发生。解决思路主要有两种：
- 预防与避免：破坏四个条件之一，常用资源分配图算法检测安全状态。
- 检测与恢复：定期检测死锁，一旦发现即选择牺牲一个事务（回滚），让另一个事务继续执行。
深入理解这些锁机制后，再遇到并发问题时，便能更从容地选择应对策略，避免数据混乱。
