项目场景：

线上环境中在写库过程中出现的一次player_property死锁报警记录

其中player_property中d_last_onlin是个耳机索引

问题描述：

关键日志记录

------------------------
LATEST DETECTED DEADLOCK
------------------------
/**第一个事务*/
2021-06-09 09:41:22 7f32c3a1c700
*** (1) TRANSACTION:
TRANSACTION 354412269, ACTIVE 0 sec fetching rows
mysql tables in use 4, locked 4
// 该事务持有1650个行锁
LOCK WAIT 1084 lock struct(s), heap size 128552, 1650 row lock(s), undo log entries 412
MySQL thread id 25437818, OS thread handle 0x7f334427c700, query id 10260869621 10.154.9.41 *** Sending data
INSERT INTO insert_table_aSELECT  NAME_CONST('i_batch_no',_utf8'20210609093903' COLLATE 'utf8_general_ci'),pp.n_roleid,'rewardByCondition',NOW(), NAME_CONST('i_reward',_utf8'3_71014_30,3_8506_2,3_20_20,3_8302_2' COLLATE 'utf8_general_ci') FROM player_roles pr LEFT JOIN player_property pp ON pr.n_roleid = pp.n_roleid LEFT JOIN player_vip vip ON pr.n_roleid = vip.n_roleid WHERE pr.d_create >=  NAME_CONST('i_create_begin',_latin1'2017-01-01 00:00:00' COLLATE 'latin1_swedish_ci')  AND pr.d_create <=  NAME_CONST('i_create_end',_latin1'2021-06-09 09:41:22' COLLATE 'latin1_swedish_ci')  AND pp.n_rank >=  NAME_CONST('i_rank',0)  AND pp.n_lv >=  NAME_CONST('i_lv',30)AND pp.d_last_online >=  NAME_CONST('i_last_online',_latin1'2021-05-10 00:00:00' COLLATE 'latin1_swedish_ci') AND IFNULL(vip.n_lv,0) >=  NAME_CONST('i_vip_lv',0)/**
* lock type : RECORD LOCKS（锁的类型）
* space id : 锁对象的space id
* page no ：事务锁定页的数量，若是表锁，该值为null
* index ：锁住的索引
* table：要加锁的表
* trx id：事务id
* lock_mode : 锁的模式等待主键上S的锁释放
*/
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 45252 page no 3567 n bits 136 index `PRIMARY` of table `DATABASE1`.`player_property` trx id 354412269 lock mode S locks rec but not gap waiting
Record lock, heap no 70 PHYSICAL RECORD: n_fields 47; compact format; info bits 0/**
事务2*/
*** (2) TRANSACTION:
TRANSACTION 354412274, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
// 持有6个行锁
7 lock struct(s), heap size 1184, 6 row lock(s), undo log entries 5
MySQL thread id 25437870, OS thread handle 0x7f32c3a1c700, query id 10260869642 10.154.9.41 *** updating
update player_property set n_reinLv=3, n_age=0, n_back_ornament_id=0, n_chat_side=2248, s_longitude='108.300575', s_birthday='', s_head='1#u_1602066042', n_equip_smelt=75198, n_vcurrency=55471426, n_role_quality=6, n_constellation=0, n_head_side=1255, n_lv=341, s_latitude='22.830141', n_exploit=2053170, s_fashion='17556,70004,16158,19556', s_area='', s_vocation='5', s_last_mac='865809030070484', n_lovers_tree_id=102941290497, n_gender=2, s_role_skill='1_71521', d_last_online='2021-06-09 09:41:04', s_rank_speak='[]', s_character='1_55,2_55,3_49,4_69,5_63,6_52', s_official_slap_head='20001_1613738865', n_popular=4933148, n_exp=787543330, n_online_time=10473708, n_camp=2, s_online='1', n_last_channel=12, n_marriage_id=102941380497, n_fans=59, n_rank=17, n_charmnum=3101335, s_sign='@予我歌丶   时光静好，与君语；细水流年，与君同；繁华落尽，与君老。', n_retinue_id=15002, n_fo
// 持有主键上的X锁
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 45252 page no 3567 n bits 136 index `PRIMARY` of table `DATABASE1`.`player_property` trx id 354412274 lock_mode X locks rec but not gap
Record lock, heap no 70 PHYSICAL RECORD: n_fields 47; compact format; info bits 0/**
等待X锁释放*/
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 45252 page no 2297 n bits 136 index `PRIMARY` of table `DATABASE1`.`player_property` trx id 354412274 lock_mode X locks rec but not gap waiting
Record lock, heap no 66 PHYSICAL RECORD: n_fields 47; compact format; info bits 0// 回滚
*** WE ROLL BACK TRANSACTION (2)

原因分析：

MYSQL有两个基本锁共享锁(S锁) 排他锁(X锁)

需要注意的是:

使用主键索引需要加一把锁，使用二级索引需要在二级索引和主键索引上各加一把锁；

加了S锁的记录，允许其他事务再加S锁，不允许其他事务再加X锁；

加了X锁的记录，不允许其他事务再加S锁或者X锁。

根据死锁日志分析

1.第一个事务在执行INSERT INTO .. SELECT 的语句，所以会给SELECT 后面的表增加S锁，由于使用到了d_last_onlin这个索引，所以会在该二级索引和主键上各加一把S锁；

2.第二个事务是在执行UPDATE通过主键去修改，所以会去获取X锁，给主键加一把锁；

3.事务1在等待主键上的S锁去释放假设该条记录为 rowA

4.事务2持有主键上的X锁 rowA

5.事务2等待主键上的X锁释放 rowB

6.所以最后结论是事务1持有rowB的S锁，去获取rowA的S锁；事务2持有rowA的X锁，去获取rowB的X锁，导致死锁

记录MYSQL死锁日志分析相关推荐

如何阅读MySQL死锁日志
现象描述客户在夜间批量执行数据处理时发生了死锁现象,是由不同的会话并发删除数据引起的,这个问题原因是比较简单,但想通过这个案例让大家熟悉如何去排查死锁问题,如何去阅读死锁日志这才是目的.通过模拟用户 ...
og-bin=mysql-bin_init_connect + binlog 记录 mysql 操作日志
init_connect + binlog 记录 mysql 操作日志简介 mysql 的 init_connect 变量是每个客户端连上数据库服务器时执行的一组数据,这组数据可以是一个或者多个sq ...
查看mysql数据库的死锁日志_【MySQL】mysql死锁以及死锁日志分析
1.死锁的概念死锁:死锁一般是事务相互等待对方资源,最后形成环路造成的. 对于死锁,数据库处理方法:牺牲一个连接,保证另外一个连接成功执行. 发生死锁会返回ERROR:1213 错误提示,大部分的死 ...
【MySQL】mysql死锁以及死锁日志分析
1.死锁的概念死锁:死锁一般是事务相互等待对方资源,最后形成环路造成的. 对于死锁,数据库处理方法:牺牲一个连接,保证另外一个连接成功执行. 发生死锁会返回ERROR:1213 错误提示,大部分的死 ...
mysql 死锁日志_Mysql死锁以及死锁日志分析
死锁的概念死锁:死锁一般是事务相互等待对方资源,***形成环路造成的. 对于死锁,数据库处理方法:牺牲一个连接,保证另外一个连接成功执行. 发生死锁会返回ERROR:1213 错误提示,大部分的死锁 ...
MySQL死锁日志的查看和分析
目录一,关于MySQL的死锁二,人造一个死锁的场景三,查看最近一次死锁的日志四,死锁日志的内容 1,事务1信息 2,事务1持有的锁 3,事务1正在等待的锁 4,事务2信息 5,事务2正在持有的 ...
mysql死锁日志阅读
前言在开发中,我们经常会遇到死锁问题,我们会查看数据库的死锁日志来查看死锁出现的原因,但是死锁日志如果不会阅读的话,可能就导致我们难以进行问题的排查环境介绍 1.数据库场景 MySQL 5.6 引 ...
mysql.err日志分析_Mysql日志解析
转载:https://www.cnblogs.com/Fly-Wind/p/5674382.html 修改Mysql配置 Mysql配置地址为: C:\Program Files (x86)\MySQ ...
mysql+web日志分析工具_用Python+MySQL实现2017年web日志分析报告
日志分析在web系统中故障排查.性能分析方面有着非常重要的作用.目前,开源的ELK系统是成熟且功能强大的选择.但是部署及学习成本亦然不低,这里我实现了一个方法上相对简单(但准确度和效率是有保证的)的实 ...
mysql+web日志分析工具_WEB日志格式及分析工具
WEB日志是网站分析和网站数据数据整理最基础的数据,了解其格式和组成将有利于更好地进行数据的收集.处理和分析. 一.日志格式类型目前常见的WEB日志格式主要由两类,一类是Apache的NCSA日志格 ...

记录MYSQL死锁日志分析

项目场景：

问题描述：

原因分析：

记录MYSQL死锁日志分析相关推荐

最新文章

热门文章