type
status
date
slug
summary
tags
category
icon
password
整理定义
本章为死锁实践，主要是对于 Day85 的死锁概念进行一些拓展。
复述展开
数据准备：
创建两个表，Animals 和 Birds，各插入一条数据，并且设置 innodb_print_all_deadlocks 为开启状态
开始操作
Session A
Session B
对于Session A 与 Session B 的两个查找语句的性能展示
可以看到：
- 事务
421291106147544给 表 Animals 加的是 共享锁，和行锁，还有意向共享锁的表锁
- 事务
421291106148352给 表 Birds 加的是 共享锁，和行锁，还有意向共享锁的表锁
继续操作
Session B
Session B 继续执行更新操作，但是需要等待。
查看下锁：
InnoDB仅在事务尝试修改数据库时使用
顺序事务id。因此，前一个只读事务id从421291106148352更改为43260。这时，如果 Session A要操作：
就会出现死锁：
Session A 和 Session B 互相持有 表 Birds 与 Animals 的 行锁，而又需要同时去更新，这时都被锁住，导致无法继续。
InnoDB回滚导致死锁的事务。来自客户端B的第一个更新现在可以继续了。
The Information Schema 包含死锁的数量：
InnoDB status包含有关死锁和事务的下列信息。它还显示只读事务id 421291106147544更改为顺序事务id 43261。
The error log 的信息
理解体会
从上面可以看出，我们用 Session A 与 Session B构造了一个死锁的示例，然后从
performance_schema.data_lock_waits performance_schema.data_locks 可以看出数据等待锁以及数据锁。
如果想看更细致的内容，可以使用命令：
SHOW ENGINE INNODB STATUS;SELECT @@log_error;快速跳转链接
【概念解析】启动
【概念解析】Day 1 - 10
【概念解析】Day 11 - 20
【概念解析】Day 21 - 30
.png?table=block&id=0af3d43f-8aae-4c4a-b6c8-7266fccd6991&width=800&t=0aa172ae-180c-4cc6-b47f-3ccb84e7c8d8&cache=v2)
【概念解析】Day 31 - 40
【概念解析】Day 41 - 50
【概念解析】Day 51 - 60
【概念解析】Day 61 - 70
【概念解析】Day 71 - 80
【概念解析】Day 81 - 90
- 作者:eachenkuang
- 链接:https://kuangyichen.com/article/industry-day87
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。