场景

mysql 5.7
InnoDB存储引擎
jdk 8 springboot
hikari 连接池

spring:application:name: productdatasource:url: jdbc:mysql://123456:3306/productdb?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8&allowMultiQueries=trueuserName: password: driver-class-name: com.mysql.cj.jdbc.Driverhikari:#连接只读数据库时配置为true， 保证安全readOnly: false#等待连接池分配连接的最大时长（毫秒），超过这个时长还没可用的连接则发生SQLException， 缺省:30秒connectionTimeout: 3000000#一个连接idle状态的最大时长（毫秒），超时则被释放（retired），缺省:10分钟idleTimeout: 600000#一个连接的生命时长（毫秒），超时而且没被使用则被释放（retired），缺省:30分钟，建议设置比数据库超时时长少30秒，参考MySQL wait_timeout参数（show variables like '%timeout%';，一般为8小时）#maxLifetime: 600000#连接池中允许的最大连接数。缺省值：10；推荐的公式：((core_count * 2) + effective_spindle_count)maximumPoolSize: 200pool-name: pool-lxlconnectionTestQuery: SELECT 1minimum-idle: 50

导入号和修改手机号场景，高并发情况下频繁修改数据库同一张表。
先通过手机号搜索出数据。
再通过uin搜索出相关的数据，如果搜索出的数据大于1则删除后再添加通过手机号搜索出的数据。
语句是delete，通过uin删除数据，当前情景下uin无索引。
同样的执行操作，并发场景：
登录失败时删除
用户手动删除数据

问题

mysql删除语句
delete from device where uin = xxxxxxxxxx

等待锁

index PRIMARY of table productdb.device trx id 27264001 lock_mode X locks rec but not gap waiting

等待锁类型¹
X locks rec but not gap waiting

死锁日志²

^{------------------------
LATEST DETECTED DEADLOCK
------------------------
2020-06-29 12:16:52 0x7f03c2cfd700*** (1) TRANSACTION:
TRANSACTION 27264001, ACTIVE 5 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 73 lock struct(s), heap size 8400, 16 row lock(s), undo log entries 9
MySQL thread id 3248046, OS thread handle 139658719131392, query id 201165398 172.31.242.1 root updating
delete from devicewhere uin = 1107000000*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 224 page no 75 n bits 208 index PRIMARY of table `productdb`.`device` trx id 27264001 lock_mode X locks rec but not gap waiting
Record lock, heap no 104 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 11; hex 3134353231393836343539; asc 14521986459;;1: len 6; hex 0000019fd14c; asc      L;;2: len 7; hex a70000014d0110; asc     M  ;;3: SQL NULL;4: len 19; hex 777869645f7979683937336d7036746c6d3232; asc wxid_yyh973mp6tlm22;;5: len 8; hex 6161313233313233; asc aa123123;;6: len 15; hex 363637323838383135323635373838; asc 667288815265788;;7: len 16; hex 41313561643064316434666661636332; asc A15ad0d1d4ffacc2;;8: len 8; hex 8000000014f0d0c3; asc         ;;*** (2) TRANSACTION:TRANSACTION 27264064, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
24 lock struct(s), heap size 3520, 3 row lock(s), undo log entries 1
MySQL thread id 3248058, OS thread handle 139654130030336, query id 201165376 172.31.242.1 root updating
delete from devicewhere uin = 576000000*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 224 page no 75 n bits 208 index PRIMARY of table `productdb`.`device` trx id 27264064 lock_mode X locks rec but not gap
Record lock, heap no 104 PHYSICAL RECORD: n_fields 9; compact format; info bits 00: len 11; hex 3134353231393836343539; asc 14521986459;;1: len 6; hex 0000019fd14c; asc      L;;2: len 7; hex a70000014d0110; asc     M  ;;3: SQL NULL;4: len 19; hex 777869645f7979683937336d7036746c6d3232; asc wxid_yyh973mp6tlm22;;5: len 8; hex 6161313233313233; asc aa123123;;6: len 15; hex 363637323838383135323635373838; asc 667288815265788;;7: len 16; hex 41313561643064316434666661636332; asc A15ad0d1d4ffacc2;;8: len 8; hex 8000000014f0d0c3; asc         ;;*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 224 page no 75 n bits 208 index PRIMARY of table `productdb`.`device` trx id 27264064 lock_mode X locks rec but not gap waiting
Record lock, heap no 23 PHYSICAL RECORD: n_fields 9; compact format; info bits 320: len 11; hex 3134353739323835393638; asc 14579285968;;1: len 6; hex 000001a00401; asc       ;;2: len 7; hex 25000007132c16; asc %    , ;;3: SQL NULL;4: len 19; hex 777869645f32706b646a62636c6e3432663232; asc wxid_2pkdjbcln42f22;;5: len 11; hex 6d696e796f6e6763687539; asc minyongchu9;;6: len 15; hex 363830303638323834323632393936; asc 680068284262996;;7: len 16; hex 41653031623564613061616366363433; asc Ae01b5da0aacf643;;8: len 8; hex 8000000030a54cf0; asc     0 L ;;*** WE ROLL BACK TRANSACTION (2)}

^{锁类型与隔离级别}

^{InnerDB 锁：}

^{共享锁（S Lock）：允许事务读取一行数据，多个事务可以拿到一把S锁（即读读并行）；}
^{排他锁（X Lock）：允许事务删除或更新一行数据，多个事务有且只有一个事务可以拿到X锁（即写写/写读互斥）；}
^{意向共享锁（IS Lock）：事务想要获得一张表中某几行的共享锁；}
^{意向排他锁（IX Lock）：事务想要获得一张表中某几行的排他锁；}
^{插入意向锁（Insert Intention Lock）：插入意向锁是间隙锁的一种，专门针对insert操作的。即多个事务在同一个索引、同一个范围区间内插入记录时，如果插入的位置不冲突，则不会阻塞彼此}
^{自增锁（Auto-inc Locks）：自增锁是一种特殊的表级别锁，专门针对事务插入AUTO-INCREMENT类型的列。即一个事务正在往表中插入记录时，其他事务的插入必须等待，以便第1个事务插入的行得到的主键值是连续的。}
^{记录锁（Record Locks）- locks rec but not gap

记录锁是的单个行记录上的锁，会阻塞其他事务对其插入、更新、删除；}
^{间隙锁(Gap Lock) ：间隙锁锁定记录的一个间隔，但不包含记录本身。}
^{临键锁（Next-Key Lock）= Gap Lock + Record Lock

临建锁是记录锁与间隙锁的组合，即：既包含索引记录，又包含索引区间，主要是为了解决幻读}

^参考³

mysql事务

事务隔离级别⁴	脏	不可重复读	幻读
读未提交（read-uncommitted）	是	是	是
不可重复读（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

解决方案

1、对于引起的条件语句添加索引：
uin

2、设置数据库的事务隔离级别（并发数据量大大场景作用不明显，需要小心脏数据）：
read commit

> select @@global.tx_isolation,@@tx_isolation;> set 作用域 transaction isolation level 事务隔离级别;

3、针对业务场景，更新为使用redis记录uin与登录账号

mysql锁 ↩︎
死锁日志分析 ↩︎
记录一次MySQL死锁的分析与解决过程 ↩︎
MySQL的四种事务隔离级别 ↩︎

mysql 执行delete引发死锁问题相关推荐

mysql delete in死锁_mysql 执行delete引发死锁问题
关于mysql事务引发的死锁异常解决场景问题死锁日志[^2] 锁类型与隔离级别 InnerDB 锁: mysql事务解决方案场景 mysql 5.7 InnoDB存储引擎 jdk 8 spr ...
mysql 执行delete的时候没走索引
在项目中需要删除表里的过期数据,表设置了key为gmt_created, 但是在执行"delete from table_name where to_days(gmt_created) & ...
mysql slave lock 跳过_slave开启MTS时执行mysqldump引发死锁案例
出现这种问题除非手动干预,杀掉FTWRL的session,复制线程方可以继续进行.版本社区版5.7.26. 二.堵塞图如果分析上面的堵塞可以画图如下: 三.关于woker线程w1和w3的等待这里我 ...
mysql当执行delete语句时备份_mysql中,执行delete语句时出现Lock wait timeout exceeded问题...
问题描述: 当我插入一条记录时,在调用save方法的时候出现了异常(记录重复了),导致了后面的commit语句不能执行了.这时我在数据库中删除重复记录时发现该表已经被锁上了.即出现错误.但过了一会再 ...
mysql从库执行delete停止_MySQL主库大表执行delete语句，Ctrl+C具体发生了什么分析...
MySQL主库大表执行delete语句,Ctrl+C具体发生了什么分析 1.查看表结构 localhost.qt>show create table doctor_stats_backup\G ...
为什么 MySQL 执行完 Delete 操作之后，空间没有释放？
为什么 MySQL 执行完 Delete 操作之后,空间没有释放? 文章目录为什么 MySQL 执行完 Delete 操作之后,空间没有释放? Mysql数据结构表文件大小未更改和mysql设计有 ...
mysql workbench 执行delete语句
转载:https://www.cnblogs.com/xh831213/p/5145137.html 一开始删了半天没删掉,惭愧. 首先,当前操作的数据库会被黑色加粗. 右键表名,select row ...
MySQL Innodb表导致死锁日志情况分析与归纳
案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志. 两个sql语句如下: (1)insert into back ...
mysql锁场景_MySQL死锁系列-常见加锁场景分析
在上一篇文章<锁的类型以及加锁原理>主要总结了 MySQL 锁的类型和模式以及基本的加锁原理,今天我们就从原理走向实战,分析常见 SQL 语句的加锁场景.了解了这几种场景,相信小伙伴们也能 ...
深入理解MySQL执行过程及执行顺序
MySQL在我们的开发中基本每天都要面对的,作为开发中的数据的来源,MySQL承担者存储数据和读写数据的职责.因为学习和了解MySQL是至关重要的,那么当我们在客户端发起一个SQL到出现详细的查询数据 ...

mysql 执行delete引发死锁问题

关于mysql事务引发的死锁异常解决

场景

问题

死锁日志²

^{锁类型与隔离级别}

^{InnerDB 锁：}

mysql事务

解决方案

mysql 执行delete引发死锁问题相关推荐

最新文章

热门文章

mysql 执行delete引发死锁问题

关于mysql事务引发的死锁异常解决

场景

问题

死锁日志2

锁类型与隔离级别

InnerDB 锁：

mysql事务

解决方案

mysql 执行delete引发死锁问题相关推荐

最新文章

热门文章

死锁日志²

^{锁类型与隔离级别}

^{InnerDB 锁：}