2. 首页 > 国产数据库教程 > GoldenDB教程 > 正文

GoldenDB教程FG024-GoldenDB锁机制-事务阻塞-死锁分析与解决

教程整理：风哥教程  |  更新时间：2026-02-01  |  教程分类：GoldenDB教程  |  文档学习：1

本文主要介绍GoldenDB数据库的锁机制、事务阻塞以及死锁的分析与解决方法。风哥教程参考GoldenDB官方文档GoldenDB8系统管理员手册、GoldenDB8性能调优等相关文档。

通过本文的学习，您将掌握GoldenDB锁机制的工作原理，学会如何识别和处理事务阻塞，以及如何分析和解决死锁问题。

本教程适用于GoldenDB数据库管理员和开发人员，帮助您在生产环境中有效地管理事务和锁，提高系统的并发性能和稳定性。

目录大纲

Part01-基础概念与理论知识

Part02-生产环境规划与建议

Part03-生产环境项目实施方案

Part04-生产案例与实战讲解

Part05-风哥经验总结与分享

Part01-基础概念与理论知识

1.1 GoldenDB锁机制概述

GoldenDB的锁机制是保证数据一致性和并发控制的重要手段，主要包括：

  • 共享锁（S锁）：允许多个事务读取同一资源，但不允许修改
  • 排他锁（X锁）：只允许一个事务访问资源，其他事务既不能读取也不能修改
  • 意向锁：表级锁，用于指示事务对表中的行将要施加的锁类型
  • 行锁：对表中的行进行锁定，粒度较细，并发度高
  • 表锁：对整个表进行锁定，粒度较粗，并发度低

GoldenDB支持MVCC（多版本并发控制），可以在一定程度上减少锁的竞争。

更多视频教程www.fgedu.net.cn

1.2 事务隔离级别与锁的关系

GoldenDB支持四种事务隔离级别：

  • READ UNCOMMITTED：读取未提交的数据，可能导致脏读
  • READ COMMITTED：读取已提交的数据，避免脏读，但可能导致不可重复读和幻读
  • REPEATABLE READ：可重复读，避免脏读和不可重复读，但可能导致幻读
  • SERIALIZABLE：串行化，避免所有并发问题，但性能最低

不同的隔离级别对锁的使用策略不同，隔离级别越高，使用的锁越多，并发度越低。

学习交流加群风哥微信: itpux-com

1.3 死锁产生的原因与预防

死锁是指两个或多个事务相互等待对方释放锁，导致所有事务都无法继续执行的状态。

死锁产生的必要条件：

  • 互斥条件：资源不能被共享，一次只能被一个事务使用
  • 请求与保持条件：事务已经保持了至少一个资源，又提出新的资源请求
  • 不剥夺条件：资源只能由持有它的事务主动释放
  • 循环等待条件：若干事务之间形成头尾相接的循环等待关系

预防死锁的方法：

  • 按顺序访问资源
  • 减少事务持有锁的时间
  • 使用合理的事务隔离级别
  • 设置锁超时时间

学习交流加群风哥QQ113257174

Part02-生产环境规划与建议

2.1 锁策略规划

在生产环境中，锁策略规划需要考虑以下因素：

  • 业务特点：根据业务的并发特性选择合适的锁策略
  • 数据访问模式：分析数据的访问模式，优化锁的粒度
  • 性能要求：在数据一致性和性能之间取得平衡
  • 系统负载：根据系统负载调整锁策略

风哥提示：对于高并发系统，建议使用行级锁，减少锁的竞争，提高并发度。

2.2 事务设计建议

事务设计的最佳实践：

  • 保持事务简短：减少事务持有锁的时间
  • 避免长事务：长事务会占用资源，增加死锁的风险
  • 合理使用索引：索引可以减少锁的范围
  • 按顺序操作资源：避免循环等待
  • 使用适当的隔离级别：根据业务需求选择合适的隔离级别

更多学习教程公众号风哥教程itpux_com

2.3 监控与告警配置

配置锁监控与告警，及时发现锁问题：

  • 锁等待监控：监控锁等待时间和等待次数
  • 死锁监控：监控死锁的发生频率
  • 长事务监控：监控长事务的执行情况
  • 告警配置：设置合理的告警阈值

from GoldenDB视频:www.itpux.com

Part03-生产环境项目实施方案

3.1 锁监控与分析

监控和分析GoldenDB的锁情况：

# 登录GoldenDB数据库
$ mysql -h 192.168.1.10 -P 3306 -u fgedu -p

Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1001
Server version: 8.0.28 GoldenDB 8.0.28-1.0.0-log

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql>

# 查看当前锁情况
mysql> SHOW GLOBAL STATUS LIKE ‘%lock%’;

+——————————————+——-+
| Variable_name | Value |
+——————————————+——-+
| Com_lock_tables | 0 |
| Com_unlock_tables | 0 |
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
| Locked_connects | 0 |
+——————————————+——-+
8 rows in set (0.00 sec)

# 查看当前正在执行的事务
mysql> SHOW ENGINE INNODB STATUS\G

*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=======================================
2024-01-01 10:00:00 0x7f8b1c000000 INNODB MONITOR OUTPUT
=======================================
Per second averages calculated from the last 30 seconds
—————–
BACKGROUND THREAD
—————–
srv_master_thread loops: 100 srv_active, 0 srv_shutdown, 800 srv_idle
srv_master_thread log flush and writes: 900
——————–
SEMAPHORES
——————–
OS WAIT ARRAY INFO: reservation count 1000
OS WAIT ARRAY INFO: signal count 800
RW-shared spins 0, rounds 100, OS waits 50
RW-excl spins 0, rounds 200, OS waits 100
RW-sx spins 0, rounds 300, OS waits 150
Spin rounds per wait: 1.00 RW-shared, 2.00 RW-excl, 3.00 RW-sx
——————–
LATEST DETECTED DEADLOCK
——————–
2024-01-01 09:50:00 0x7f8b1c000000
*** (1) TRANSACTION:
TRANSACTION 12345, ACTIVE 10 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 100, OS thread handle 140234567890123, query id 5000 192.168.1.20 fgedu updating
UPDATE fgedu_user SET name = ‘test’ WHERE id = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `fgedudb`.`fgedu_user` trx id 12345 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000003039; asc 09;;
2: len 7; hex b6000001234567; asc #Eg;;
3: len 5; hex 7465737431; asc test1;;
4: len 4; hex 8000001e; asc ;;

*** (2) TRANSACTION:
TRANSACTION 12346, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 101, OS thread handle 140234567890456, query id 5001 192.168.1.20 fgedu updating
UPDATE fgedu_user SET age = 30 WHERE id = 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `fgedudb`.`fgedu_user` trx id 12346 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000003039; asc 09;;
2: len 7; hex b6000001234567; asc #Eg;;
3: len 5; hex 7465737431; asc test1;;
4: len 4; hex 8000001e; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `fgedudb`.`fgedu_user` trx id 12346 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000003039; asc 09;;
2: len 7; hex b6000001234567; asc #Eg;;
3: len 5; hex 7465737431; asc test1;;
4: len 4; hex 8000001e; asc ;;
*** WE ROLL BACK TRANSACTION (2)

3.2 事务阻塞处理

处理事务阻塞的方法：

# 查看当前正在执行的进程
mysql> SHOW PROCESSLIST;

+—–+——+—————–+———+———+——+———-+——————+
| Id | User | Host | db | Command | Time | State | Info |
+—–+——+—————–+———+———+——+———-+——————+
| 100 | fgedu| 192.168.1.20:12345 | fgedudb | Query | 10 | updating | UPDATE fgedu_user SET name = ‘test’ WHERE id = 1 |
| 101 | fgedu| 192.168.1.20:12346 | fgedudb | Query | 15 | updating | UPDATE fgedu_user SET age = 30 WHERE id = 1 |
| 102 | fgedu| 192.168.1.20:12347 | fgedudb | Sleep | 5 | | NULL |
+—–+——+—————–+———+———+——+———-+——————+

# 查看事务等待情况
mysql> SELECT * FROM information_schema.innodb_trx;

+——–+———–+———————+———————–+——————+————+———————+—————————————-+
| trx_id | trx_state | trx_started | trx_requested_lock_id | trx_wait_started | trx_weight | trx_mysql_thread_id | trx_query |
+——–+———–+———————+———————–+——————+————+———————+—————————————-+
| 12345 | LOCK WAIT | 2024-01-01 10:00:00 | 12345:123:456:2 | 2024-01-01 10:00:05 | 2 | 100 | UPDATE fgedu_user SET name = ‘test’ WHERE id = 1 |
| 12346 | LOCK WAIT | 2024-01-01 10:00:05 | 12346:123:456:2 | 2024-01-01 10:00:10 | 2 | 101 | UPDATE fgedu_user SET age = 30 WHERE id = 1 |
+——–+———–+———————+———————–+——————+————+———————+—————————————-+

# 终止阻塞的事务
mysql> KILL 101;

Query OK, 0 rows affected (0.00 sec)

3.3 死锁检测与解决

GoldenDB会自动检测死锁，并回滚其中一个事务以解除死锁。

配置死锁检测参数：

# 查看死锁检测配置
mysql> SHOW VARIABLES LIKE ‘innodb_deadlock_detect’;

+————————+——-+
| Variable_name | Value |
+————————+——-+
| innodb_deadlock_detect | ON |
+————————+——-+

# 查看死锁发生次数
mysql> SHOW GLOBAL STATUS LIKE ‘Innodb_deadlocks’;

+——————+——-+
| Variable_name | Value |
+——————+——-+
| Innodb_deadlocks | 5 |
+——————+——-+

Part04-生产案例与实战讲解

4.1 锁等待分析实战

案例：分析和解决锁等待问题

# 模拟锁等待场景
# 会话1：开启事务并更新数据
mysql> START TRANSACTION;
mysql> UPDATE fgedu_user SET name = ‘test1’ WHERE id = 1;

Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.01 sec)

# 会话2：尝试更新同一行数据
mysql> UPDATE fgedu_user SET age = 31 WHERE id = 1;

# 此时会话2会被阻塞

# 会话3：查看锁等待情况
mysql> SELECT * FROM information_schema.innodb_trx;

+——–+———–+———————+———————–+——————+————+———————+—————————————-+
| trx_id | trx_state | trx_started | trx_requested_lock_id | trx_wait_started | trx_weight | trx_mysql_thread_id | trx_query |
+——–+———–+———————+———————–+——————+————+———————+—————————————-+
| 12347 | RUNNING | 2024-01-01 10:10:00 | NULL | NULL | 2 | 102 | UPDATE fgedu_user SET name = ‘test1’ WHERE id = 1 |
| 12348 | LOCK WAIT | 2024-01-01 10:10:10 | 12348:123:456:2 | 2024-01-01 10:10:10 | 2 | 103 | UPDATE fgedu_user SET age = 31 WHERE id = 1 |
+——–+———–+———————+———————–+——————+————+———————+—————————————-+

# 会话1：提交事务
mysql> COMMIT;

Query OK, 0 rows affected (0.00 sec)

# 此时会话2的更新操作会执行完成
# 会话2输出：
Query OK, 1 row affected (10.23 sec)

4.2 死锁分析与解决实战

案例：模拟死锁场景并分析

# 会话1：开启事务，更新id=1的记录
mysql> START TRANSACTION;
mysql> UPDATE fgedu_user SET name = ‘test1’ WHERE id = 1;

Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.01 sec)

# 会话2：开启事务，更新id=2的记录
mysql> START TRANSACTION;
mysql> UPDATE fgedu_user SET name = ‘test2’ WHERE id = 2;

Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.01 sec)

# 会话1：尝试更新id=2的记录
mysql> UPDATE fgedu_user SET age = 31 WHERE id = 2;

# 此时会话1会等待会话2释放id=2的锁

# 会话2：尝试更新id=1的记录
mysql> UPDATE fgedu_user SET age = 32 WHERE id = 1;

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

# 查看死锁信息
mysql> SHOW ENGINE INNODB STATUS\G

*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=======================================
2024-01-01 10:20:00 0x7f8b1c000000 INNODB MONITOR OUTPUT
=======================================
Per second averages calculated from the last 30 seconds
—————–
BACKGROUND THREAD
—————–
srv_master_thread loops: 100 srv_active, 0 srv_shutdown, 800 srv_idle
srv_master_thread log flush and writes: 900
——————–
SEMAPHORES
——————–
OS WAIT ARRAY INFO: reservation count 1000
OS WAIT ARRAY INFO: signal count 800
RW-shared spins 0, rounds 100, OS waits 50
RW-excl spins 0, rounds 200, OS waits 100
RW-sx spins 0, rounds 300, OS waits 150
Spin rounds per wait: 1.00 RW-shared, 2.00 RW-excl, 3.00 RW-sx
——————–
LATEST DETECTED DEADLOCK
——————–
2024-01-01 10:20:00 0x7f8b1c000000
*** (1) TRANSACTION:
TRANSACTION 12349, ACTIVE 10 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 102, OS thread handle 140234567890123, query id 5002 192.168.1.20 fgedu updating
UPDATE fgedu_user SET age = 31 WHERE id = 2
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `fgedudb`.`fgedu_user` trx id 12349 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 00000000303a; asc 0:;;
2: len 7; hex b6000001234568; asc #Eh;;
3: len 5; hex 7465737432; asc test2;;
4: len 4; hex 8000001f; asc ;;

*** (2) TRANSACTION:
TRANSACTION 12350, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 103, OS thread handle 140234567890456, query id 5003 192.168.1.20 fgedu updating
UPDATE fgedu_user SET age = 32 WHERE id = 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `fgedudb`.`fgedu_user` trx id 12350 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 00000000303a; asc 0:;;
2: len 7; hex b6000001234568; asc #Eh;;
3: len 5; hex 7465737432; asc test2;;
4: len 4; hex 8000001f; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `fgedudb`.`fgedu_user` trx id 12350 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000003039; asc 09;;
2: len 7; hex b6000001234567; asc #Eg;;
3: len 5; hex 7465737431; asc test1;;
4: len 4; hex 8000001e; asc ;;
*** WE ROLL BACK TRANSACTION (2)

风哥提示：死锁发生后，GoldenDB会自动回滚其中一个事务。在这个案例中，事务2被回滚，事务1可以继续执行。

4.3 事务优化实战

案例：优化事务，减少锁竞争

— 优化前：长事务，持有锁时间长
START TRANSACTION;
UPDATE fgedu_order SET status = ‘processing’ WHERE order_id = 1001;
— 业务逻辑处理（耗时操作）
DO SLEEP(10);
UPDATE fgedu_order SET status = ‘completed’ WHERE order_id = 1001;
COMMIT;

— 优化后：将耗时操作移出事务
— 1. 更新订单状态为处理中
UPDATE fgedu_order SET status = ‘processing’ WHERE order_id = 1001;
— 2. 执行业务逻辑处理（耗时操作）
DO SLEEP(10);
— 3. 更新订单状态为完成
UPDATE fgedu_order SET status = ‘completed’ WHERE order_id = 1001;

# 优化后，每个更新操作都是独立的短事务，减少了锁的持有时间

Part05-风哥经验总结与分享

5.1 锁管理最佳实践

  • 减少锁的范围：使用行级锁而非表级锁，减少锁的竞争
  • 缩短事务时间：减少事务持有锁的时间，避免长事务
  • 合理使用索引：索引可以减少锁的范围，提高并发度
  • 按顺序访问资源：避免循环等待，减少死锁的发生
  • 使用适当的隔离级别：根据业务需求选择合适的隔离级别
  • 监控锁情况：定期监控锁等待和死锁情况，及时发现问题

5.2 常见锁问题与解决方案

  • 锁等待时间过长：
    • 原因：事务持有锁时间过长，或者锁竞争激烈
    • 解决方案：优化事务，减少锁持有时间；增加索引，减少锁的范围；考虑使用更细粒度的锁
  • 死锁频繁发生：
    • 原因：事务之间循环等待资源
    • 解决方案：按顺序访问资源；减少事务持有锁的时间；使用合理的事务隔离级别
  • 表锁导致并发度低：
    • 原因：没有使用索引，导致全表扫描，触发表锁
    • 解决方案：为查询条件创建索引，使用行级锁

5.3 性能优化建议

  • 优化SQL语句：使用索引，避免全表扫描，减少锁的范围
  • 优化事务设计：保持事务简短，避免长事务
  • 调整系统参数：根据业务需求调整事务隔离级别和锁超时时间
  • 增加硬件资源：对于高并发系统，增加CPU和内存资源
  • 使用分区表：对于大表，使用分区表减少锁的范围
  • 实施读写分离：将读操作和写操作分离，减少锁的竞争

风哥提示：锁管理是数据库性能优化的重要组成部分，合理的锁策略可以显著提高系统的并发性能和稳定性。

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息