MySQL的死锁分析

最新推荐文章于 2023-10-25 13:40:16 发布
最新推荐文章于 2023-10-25 13:40:16 发布
阅读量956 收藏 1
点赞数
文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_46875212/article/details/112427720
版权

一，关于MySQL的死锁
MySQL的死锁指的是两个事务互相等待的场景，这种循环等待理论上不会有尽头。
比如事务A持有行1的锁，事务B持有行2的锁，
然后事务A试图获取行2的锁，事务B试图获取行1的锁，
这样事务A要等待事务B释放行2的锁，事务B要等待事务A释放行1的锁，
两个事务互相等待，谁也提交不了。

这种情况下MySQL会选择中断并回滚其中一个事务，使得另一个事务可以提交。
MySQL会记录死锁的日志。

二，人造一个死锁的场景
新建一个表，添加两条数据：

创建两个事务，事务执行的sql分别是：
事务A：

  1. set autocommit=0;
  3. update medicine_control set current_count=1 where id=‘1’;
  5. update medicine_control set current_count=1 where id=‘2’;
  7. COMMIT;
    事务B：
  8. set autocommit=0;
  10. update medicine_control set current_count=2 where id=‘2’;
  12. update medicine_control set current_count=2 where id=‘1’;
  14. COMMIT;
    可见，事务A先改id=1的数据再改id=2的数据，事务B相反，先改id=2的数据再改id=1的数据。
    两个事务sql的执行顺序如下：
    步骤 事务A 事务A
    1 set autocommit=0;
    2 update medicine_control
    set current_count=1
    where id=‘1’;
    3 set autocommit=0;
    4 update medicine_control
    set current_count=2
    where id=‘2’;
    5 update medicine_control
    set current_count=1
    where id=‘2’;
    6 update medicine_control
    set current_count=2
    where id=‘1’;
    对每一步的说明：
    1，事务A开始事务。
    2，事务A修改id=1的数据，持有了该行的锁。
    3，事务B开始事务。
    4，事务B修改id=2的数据，持有了该行的锁。
    5，事务A试图修改id=2的数据，此行的锁被事务B持有，于是事务A等待事务B释放锁。
    事务B提交或回滚都能释放锁。
    6，事务B试图修改id=1的数据，此行的锁被事务A持有，于是事务B等待事务A释放锁。
    事务A提交或回滚都能释放锁。当执行到这一步时，MySQL会立即检测到死锁，并且中断并回滚其中一个事务。此次回滚的是事务B，执行SQL的返回信息是这样的：
    [SQL]update medicine_control set current_count=2 where id=‘1’;
    [Err] 1213 - Deadlock found when trying to get lock; try restarting transaction

三，查看最近一次死锁的日志
执行sql命令：
SHOW ENGINE INNODB STATUS;
执行结果如下：

其中的status字段里包含了最近一次死锁的日志。

四，死锁日志的内容
上面制造的死锁，其死锁日志的内容是这样的：

  1. =====================================
  2. 2020-09-15 14:46:28 0x7f732fcff700 INNODB MONITOR OUTPUT
  3. =====================================
  4. Per second averages calculated from the last 37 seconds
  6. BACKGROUND THREAD
  8. srv_master_thread loops: 609 srv_active, 0 srv_shutdown, 23969851 srv_idle
  9. srv_master_thread log flush and writes: 0
  11. SEMAPHORES
  13. OS WAIT ARRAY INFO: reservation count 100
  14. OS WAIT ARRAY INFO: signal count 98
  15. RW-shared spins 0, rounds 0, OS waits 0
  16. RW-excl spins 29, rounds 870, OS waits 25
  17. RW-sx spins 1, rounds 30, OS waits 0
  18. Spin rounds per wait: 0.00 RW-shared, 30.00 RW-excl, 30.00 RW-sx
  20. LATEST DETECTED DEADLOCK
  22. 2020-09-15 14:46:15 0x7f7350cf3700
  23. *** (1) TRANSACTION:
  24. TRANSACTION 10298, ACTIVE 11 sec starting index read
  25. mysql tables in use 1, locked 1
  26. LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
  27. MySQL thread id 7623, OS thread handle 140132789073664, query id 6006191 127.0.0.1 root updating
  28. update medicine_control set current_count=1 where id=‘2’
  30. *** (1) HOLDS THE LOCK(S):
  31. RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10298 lock_mode X locks rec but not gap
  32. Record lock, heap no 21 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
  33. 0: len 1; hex 31; asc 1;;
  34. 1: len 6; hex 00000000283a; asc (:;;
  35. 2: len 7; hex 020000012510db; asc % ;;
  36. 3: len 6; hex e5a5b6e5a5b6; asc ;;
  37. 4: len 12; hex e79b98e5b0bce8a5bfe69e97; asc ;;
  38. 5: len 4; hex 80000001; asc ;;
  39. 6: len 4; hex 80000005; asc ;;
  40. 7: len 4; hex 80000000; asc ;;
  41. 8: len 5; hex 6a65656367; asc jeecg;;
  42. 9: len 5; hex 99a60eadf7; asc ;;
  43. 10: len 3; hex 6a6f62; asc job;;
  44. 11: len 5; hex 99a75e0780; asc ^ ;;
  47. *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
  48. RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10298 lock_mode X locks rec but not gap waiting
  49. Record lock, heap no 4 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
  50. 0: len 1; hex 32; asc 2;;
  51. 1: len 6; hex 00000000283b; asc (;;;
  52. 2: len 7; hex 01000002012bd8; asc + ;;
  53. 3: len 6; hex e788b7e788b7; asc ;;
  54. 4: len 6; hex e69f90e69f90; asc ;;
  55. 5: len 4; hex 80000002; asc ;;
  56. 6: len 4; hex 80000002; asc ;;
  57. 7: len 4; hex 80000000; asc ;;
  58. 8: len 5; hex 6c6979616e; asc liyan;;
  59. 9: len 5; hex 99a67b3730; asc {70;;
  60. 10: len 3; hex 6a6f62; asc job;;
  61. 11: len 5; hex 99a75e0780; asc ^ ;;
  64. *** (2) TRANSACTION:
  65. TRANSACTION 10299, ACTIVE 7 sec starting index read
  66. mysql tables in use 1, locked 1
  67. LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
  68. MySQL thread id 7625, OS thread handle 140133576603392, query id 6006195 127.0.0.1 root updating
  69. update medicine_control set current_count=2 where id=‘1’
  71. *** (2) HOLDS THE LOCK(S):
  72. RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10299 lock_mode X locks rec but not gap
  73. Record lock, heap no 4 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
  74. 0: len 1; hex 32; asc 2;;
  75. 1: len 6; hex 00000000283b; asc (;;;
  76. 2: len 7; hex 01000002012bd8; asc + ;;
  77. 3: len 6; hex e788b7e788b7; asc ;;
  78. 4: len 6; hex e69f90e69f90; asc ;;
  79. 5: len 4; hex 80000002; asc ;;
  80. 6: len 4; hex 80000002; asc ;;
  81. 7: len 4; hex 80000000; asc ;;
  82. 8: len 5; hex 6c6979616e; asc liyan;;
  83. 9: len 5; hex 99a67b3730; asc {70;;
  84. 10: len 3; hex 6a6f62; asc job;;
  85. 11: len 5; hex 99a75e0780; asc ^ ;;
  88. *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
  89. RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10299 lock_mode X locks rec but not gap waiting
  90. Record lock, heap no 21 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
  91. 0: len 1; hex 31; asc 1;;
  92. 1: len 6; hex 00000000283a; asc (:;;
  93. 2: len 7; hex 020000012510db; asc % ;;
  94. 3: len 6; hex e5a5b6e5a5b6; asc ;;
  95. 4: len 12; hex e79b98e5b0bce8a5bfe69e97; asc ;;
  96. 5: len 4; hex 80000001; asc ;;
  97. 6: len 4; hex 80000005; asc ;;
  98. 7: len 4; hex 80000000; asc ;;
  99. 8: len 5; hex 6a65656367; asc jeecg;;
  100. 9: len 5; hex 99a60eadf7; asc      ;;

  101. 10: len 3; hex 6a6f62; asc job;;

  102. 11: len 5; hex 99a75e0780; asc   ^  ;;
  104. *** WE ROLL BACK TRANSACTION (2)
  106. TRANSACTIONS
  108. Trx id counter 10301
  109. Purge done for trx’s n:o < 10301 undo n:o < 0 state: running but idle
  110. History list length 61
  111. LIST OF TRANSACTIONS FOR EACH SESSION:
  112. —TRANSACTION 421608706154464, not started
  113. 0 lock struct(s), heap size 1136, 0 row lock(s)
  114. —TRANSACTION 421608706153592, not started
  115. 0 lock struct(s), heap size 1136, 0 row lock(s)
  116. —TRANSACTION 421608706152720, not started
  117. 0 lock struct(s), heap size 1136, 0 row lock(s)
  118. —TRANSACTION 421608706151848, not started
  119. 0 lock struct(s), heap size 1136, 0 row lock(s)
  120. —TRANSACTION 421608706150976, not started
  121. 0 lock struct(s), heap size 1136, 0 row lock(s)
  122. —TRANSACTION 421608706150104, not started
  123. 0 lock struct(s), heap size 1136, 0 row lock(s)
  124. —TRANSACTION 421608706148360, not started
  125. 0 lock struct(s), heap size 1136, 0 row lock(s)
  126. —TRANSACTION 421608706147488, not started
  127. 0 lock struct(s), heap size 1136, 0 row lock(s)
  128. —TRANSACTION 421608706146616, not started
  129. 0 lock struct(s), heap size 1136, 0 row lock(s)
  130. —TRANSACTION 421608706145744, not started
  131. 0 lock struct(s), heap size 1136, 0 row lock(s)
  132. —TRANSACTION 421608706144872, not started
  133. 0 lock struct(s), heap size 1136, 0 row lock(s)
  134. —TRANSACTION 421608706144000, not started
  135. 0 lock struct(s), heap size 1136, 0 row lock(s)
  136. —TRANSACTION 10298, ACTIVE 24 sec
  137. 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2
  138. MySQL thread id 7623, OS thread handle 140132789073664, query id 6006198 127.0.0.1 root
  140. FILE I/O
  142. I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
  143. I/O thread 1 state: waiting for completed aio requests (log thread)
  144. I/O thread 2 state: waiting for completed aio requests (read thread)
  145. I/O thread 3 state: waiting for completed aio requests (read thread)
  146. I/O thread 4 state: waiting for completed aio requests (read thread)
  147. I/O thread 5 state: waiting for completed aio requests (read thread)
  148. I/O thread 6 state: waiting for completed aio requests (write thread)
  149. I/O thread 7 state: waiting for completed aio requests (write thread)
  150. I/O thread 8 state: waiting for completed aio requests (write thread)
  151. I/O thread 9 state: waiting for completed aio requests (write thread)
  152. Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
  153. ibuf aio reads:, log i/o's:, sync i/o's:
  154. Pending flushes (fsync) log: 0; buffer pool: 0
  155. 2048 OS file reads, 24777 OS file writes, 11472 OS fsyncs
  156. 0.00 reads/s, 0 avg bytes/read, 0.59 writes/s, 0.54 fsyncs/s
  158. INSERT BUFFER AND ADAPTIVE HASH INDEX
  160. Ibuf: size 1, free list len 0, seg size 2, 0 merges
  161. merged operations:
  162. insert 0, delete mark 0, delete 0
  163. discarded operations:
  164. insert 0, delete mark 0, delete 0
  165. Hash table size 34679, node heap has 1 buffer(s)
  166. Hash table size 34679, node heap has 3 buffer(s)
  167. Hash table size 34679, node heap has 1 buffer(s)
  168. Hash table size 34679, node heap has 1 buffer(s)
  169. Hash table size 34679, node heap has 1 buffer(s)
  170. Hash table size 34679, node heap has 1 buffer(s)
  171. Hash table size 34679, node heap has 2 buffer(s)
  172. Hash table size 34679, node heap has 5 buffer(s)
  173. 0.00 hash searches/s, 0.27 non-hash searches/s
  175. LOG
  177. Log sequence number 2246453180
  178. Log buffer assigned up to 2246453180
  179. Log buffer completed up to 2246453180
  180. Log written up to 2246453180
  181. Log flushed up to 2246453180
  182. Added dirty pages up to 2246453180
  183. Pages flushed up to 2246453180
  184. Last checkpoint at 2246453180
  185. 9242 log i/o’s done, 0.14 log i/o’s/second
  187. BUFFER POOL AND MEMORY
  189. Total large memory allocated 137363456
  190. Dictionary memory allocated 835752
  191. Buffer pool size 8192
  192. Free buffers 6046
  193. Database pages 2131
  194. Old database pages 788
  195. Modified db pages 0
  196. Pending reads 0
  197. Pending writes: LRU 0, flush list 0, single page 0
  198. Pages made young 0, not young 0
  199. 0.00 youngs/s, 0.00 non-youngs/s
  200. Pages read 1923, created 208, written 13739
  201. 0.00 reads/s, 0.00 creates/s, 0.00 writes/s
  202. Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
  203. Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
  204. LRU len: 2131, unzip_LRU len: 0
  205. I/O sum[0]:cur[0], unzip sum[0]:cur[0]
  207. ROW OPERATIONS
  209. 0 queries inside InnoDB, 0 queries in queue
  210. 0 read views open inside InnoDB
  211. Process ID=920, Main thread ID=140133220153088 , state=sleeping
  212. Number of rows inserted 416, updated 2599, deleted 440, read 821958
  213. 0.00 inserts/s, 0.08 updates/s, 0.00 deletes/s, 0.11 reads/s
  215. END OF INNODB MONITOR OUTPUT
  216. ============================

其中：

2020-09-15 14:46:28 0x7f732fcff700 INNODB MONITOR OUTPUT

这段记录的是查询死锁日志的时间

LATEST DETECTED DEADLOCK

这段后面记录的就是此次死锁的信息，分为几部分
1，事务1信息
也就是这一部分：
*** (1) TRANSACTION:
TRANSACTION 10298, ACTIVE 11 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 7623, OS thread handle 140132789073664, query id 6006191 127.0.0.1 root updating
update medicine_control set current_count=1 where id=‘2’
其中：
TRANSACTION 10298，是此事务的id。
ACTIVE 11 sec，活跃时间11秒。
starting index read，事务当前正在根据索引读取数据。
starting index read这个描述还有其他情况：

  1. fetching rows 表示事务状态在row_search_for_mysql中被设置，表示正在查找记录。
  2. updating or deleting 表示事务已经真正进入了Update/delete的函数逻辑（row_update_for_mysql）
  3. thread declared inside InnoDB 说明事务已经进入innodb层。通常而言 不在innodb层的事务大部分是会被回滚的。
    mysql tables in use 1, locked 1，表示此事务修改了一个表，锁了一行数据。
    MySQL thread id 7623，这是线程id
    query id 6006191，这是查询id
    127.0.0.1 root updating，数据库ip地址，账号，更新语句。
    update medicine_control set current_count=1 where id=‘2’，这是正在执行的sql。

2，事务1持有的锁
也就是这段：
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10298 lock_mode X locks rec but not gap
Record lock, heap no 21 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
0: len 1; hex 31; asc 1;;
1: len 6; hex 00000000283a; asc (:;;
2: len 7; hex 020000012510db; asc % ;;
3: len 6; hex e5a5b6e5a5b6; asc ;;
4: len 12; hex e79b98e5b0bce8a5bfe69e97; asc ;;
5: len 4; hex 80000001; asc ;;
6: len 4; hex 80000005; asc ;;
7: len 4; hex 80000000; asc ;;
8: len 5; hex 6a65656367; asc jeecg;;
9: len 5; hex 99a60eadf7; asc ;;
10: len 3; hex 6a6f62; asc job;;
11: len 5; hex 99a75e0780; asc ^ ;;
其中：
RECORD LOCKS，表示持有的是行级锁。
index PRIMARY，表示锁的是主键索引。
table jeecg-boot.medicine_control，表示锁的具体是哪个表。
trx id 10298，事务id，和上面的TRANSACTION相同。
lock_mode X locks，锁模式：排它锁。（X：排他锁，S：共享锁）
but not gap，非间隙锁
后面的0至11，代表锁的具体哪一行，0至11指的是表的第1至第12个字段，0开头的这行表示id列，可见锁的是id=1的那一行，可知这里的事务1就是上面的事务A。

3，事务1正在等待的锁
也就是这段：
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10298 lock_mode X locks rec but not gap waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
0: len 1; hex 32; asc 2;;
1: len 6; hex 00000000283b; asc (;;;
2: len 7; hex 01000002012bd8; asc + ;;
3: len 6; hex e788b7e788b7; asc ;;
4: len 6; hex e69f90e69f90; asc ;;
5: len 4; hex 80000002; asc ;;
6: len 4; hex 80000002; asc ;;
7: len 4; hex 80000000; asc ;;
8: len 5; hex 6c6979616e; asc liyan;;
9: len 5; hex 99a67b3730; asc {70;;
10: len 3; hex 6a6f62; asc job;;
11: len 5; hex 99a75e0780; asc ^ ;;
其中：
index PRIMARY，表示等待的是主键的锁。
table jeecg-boot.medicine_control，表示等待的表。
trx id 10298，当前事务1的id。注意这里不是持有目标锁的事务的id，而是当前事务id。
lock_mode X locks，表示目标锁是排它锁。
but not gap，表示非间隙锁。
waiting，表示当前事务正在等待。
后面的0至11，表示等待的行，可见等待的是id=2的行的锁。

4，事务2信息
也就是这一段：
*** (2) TRANSACTION:
TRANSACTION 10299, ACTIVE 7 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 7625, OS thread handle 140133576603392, query id 6006195 127.0.0.1 root updating
update medicine_control set current_count=2 where id=‘1’
格式和事务1信息相同。
TRANSACTION 10299，表示事务id是10299。
update medicine_control set current_count=2 where id=‘1’，表示事务2正在执行的sql。

5，事务2正在持有的锁
也就是这段：
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10299 lock_mode X locks rec but not gap
Record lock, heap no 4 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
0: len 1; hex 32; asc 2;;
1: len 6; hex 00000000283b; asc (;;;
2: len 7; hex 01000002012bd8; asc + ;;
3: len 6; hex e788b7e788b7; asc ;;
4: len 6; hex e69f90e69f90; asc ;;
5: len 4; hex 80000002; asc ;;
6: len 4; hex 80000002; asc ;;
7: len 4; hex 80000000; asc ;;
8: len 5; hex 6c6979616e; asc liyan;;
9: len 5; hex 99a67b3730; asc {70;;
10: len 3; hex 6a6f62; asc job;;
11: len 5; hex 99a75e0780; asc ^ ;;
可见事务2持有id=2的行锁，也就是说这里的事务2就是上面的事务B。

6，事务2正在等待的锁
也就是这段：
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 4 n bits 88 index PRIMARY of table jeecg-boot.medicine_control trx id 10299 lock_mode X locks rec but not gap waiting
Record lock, heap no 21 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
0: len 1; hex 31; asc 1;;
1: len 6; hex 00000000283a; asc (:;;
2: len 7; hex 020000012510db; asc % ;;
3: len 6; hex e5a5b6e5a5b6; asc ;;
4: len 12; hex e79b98e5b0bce8a5bfe69e97; asc ;;
5: len 4; hex 80000001; asc ;;
6: len 4; hex 80000005; asc ;;
7: len 4; hex 80000000; asc ;;
8: len 5; hex 6a65656367; asc jeecg;;
9: len 5; hex 99a60eadf7; asc ;;
10: len 3; hex 6a6f62; asc job;;
11: len 5; hex 99a75e0780; asc ^ ;;
可见事务2正在等待id=1的行锁。

7，死锁处理结果
也就是这段：
*** WE ROLL BACK TRANSACTION (2)
表示MySQL最终决定回滚事务2，也就是上面的事务B，这和上面事务B返回的死锁信息是一致的。

另外，日志里还记录的当前SESSION和事务列表，也就是这段：

TRANSACTIONS

Trx id counter 10301
Purge done for trx’s n:o < 10301 undo n:o < 0 state: running but idle
History list length 61
LIST OF TRANSACTIONS FOR EACH SESSION:
—TRANSACTION 421608706154464, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706153592, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706152720, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706151848, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706150976, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706150104, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706148360, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706147488, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706146616, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706145744, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706144872, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 421608706144000, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
—TRANSACTION 10298, ACTIVE 24 sec
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2
MySQL thread id 7623, OS thread handle 140132789073664, query id 6006198 127.0.0.1 root
可见多数的SESSION下的事务都没开始，注意最后的这段：
— TRANSACTION 10298, ACTIVE 24 sec
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2
表示id为10298的事务（也就是事务1）还没提交。

五，关于mysql的八种锁
1，行锁（Record Locks）
行锁是作用在索引上的。
2，间隙锁（Gap Locks）
间隙锁是锁住一个区间的锁。
这个区间是一个开区间，范围是从某个存在的值向左直到比他小的第一个存在的值，所以间隙锁包含的内容就是在查询范围内，而又不存在的数据区间。
比如有id分别是1,10,20，要修改id<15的数据，那么生成的间隙锁有以下这些：(-∞,1)，(1,10)，(10,20)，此时若有其他事务想要插入id=11的数据，则需要等待。
间隙锁是不互斥的。
作用是防止其他事务在区间内添加记录，而本事务可以在区间内添加记录，从而防止幻读。
在可重复读这种隔离级别下会启用间隙锁，而在读未提交和读已提交两种隔离级别下，即使使用select … in share mode或select … for update，也不会有间隙锁，无法防止幻读。
3，临键锁（Next-key Locks）
临键锁=间隙锁+行锁，于是临键锁的区域是一个左开右闭的区间。
隔离级别是可重复读时，select … in share mode或select … for update会使用临键锁，防止幻读。普通select语句是快照读，不能防止幻读。
4，共享锁/排他锁（Shared and Exclusive Locks）
共享锁和排它锁都是行锁。共享锁用于事务并发读取，比如select … in share mode。排它锁用于事务并发更新或删除。比如select … for update
5，意向共享锁/意向排他锁（Intention Shared and Exclusive Locks）
意向共享锁和意向排他锁都是表级锁。
官方文档中说，事务获得共享锁前要先获得意向共享锁，获得排它锁前要先获得意向排它锁。
意向排它锁互相之间是兼容的。
6，插入意向锁（Insert Intention Locks）
插入意向锁锁的是一个点，是一种特殊的间隙锁，用于并发插入。
插入意向锁和间隙锁互斥。插入意向锁互相不互斥。
7，自增锁（Auto-inc Locks）
自增锁用于事务中插入自增字段。5.1版本前是表锁，5.1及以后版本是互斥轻量锁。
自增所相关的变量有：
auto_increment_offset，初始值
auto_increment_increment，每次增加的数量
innodb_autoinc_lock_mode，自增锁模式
其中：
innodb_autoinc_lock_mode=0，传统方式，每次都产生表锁。此为5.1版本前的默认配置。
innodb_autoinc_lock_mode=1，连续方式。产生轻量锁，申请到自增锁就将锁释放，simple insert会获得批量的锁，保证连续插入。此为5.2版本后的默认配置。
innodb_autoinc_lock_mode=2，交错锁定方式。不锁表，并发速度最快。但最终产生的序列号和执行的先后顺序可能不一致，也可能断裂。

六，关于死锁的解锁
InnoDB存储引擎会选择回滚undo量最小的事务

本文完

tonggekuan
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql死锁分析
03-01
### MySQL死锁分析 #### 死锁问题背景 在MySQL的使用过程中，死锁是一个较为常见的现象，尤其是在并发量较大的应用场景下。死锁的发生往往会给系统带来不可预知的影响，严重时甚至会导致整个数据库服务不可用。...
spring 事务问题：Transaction rolled back because it has been marked as rollback-only
热门推荐
sunayn的博客
08-11 2万+
问题描述： 同事测试时使用异常数据，代码报错但是并不是异常产生的错误，而出现： Transaction rolled back because it has been marked as rollback-only 中文翻译就是： 事务已回滚，因为它被标记成了只回滚 代码片段： // 我的代码 @Transactional(readOnly = true, rollbackFor = Exception.class) public String select(Stri
Transaction rolled back because it has been marked as rollback-only
最新发布
青鸟飞鱼
10-25 8818
那么现在有A和B两个方法，这两个方法都开启了事务，A方法中调用B方法（因为都使用事务，默认的事务传播级别是PROPAGATION_REQUIRED，所以这过程中会使用同一个事务）；当执行B方法的时候，B方法抛出异常，这个时候事务就会被标记为仅回滚（因为在B方法中抛出异常，B方法这事务本该是要回滚，所以会将B方法的事务标记为rollback-only）；字面上的意思就是：事务已回滚，因为它已被标记为仅回滚，那为什么会标记为仅回滚呢？
spring事务报错Transaction rolled back because it has been marked as rollback-only
暗星涌动
05-11 9935
之前经常报"Transaction rolled back because it has been marked as-only"这个异常字面意思是"了，因为它被标记了必须回滚"，最开始完全不懂事务的嵌套，每次出现这个错误都想知道为什么，但是总是不能重现，后面反复折腾终于弄明白了怎么回事。
Spring事务理解和配置
Student108的博客
09-07 2487
文章目录1 Spring事务1.1 事务简介1.1.1 什么是事务1.1.2 事物的特性1.1.3 不考虑事物会引发的安全问题1.1.4 事务隔离级别1.2 事务的传播行为1.3 编程式事务(需要手动写代码,了解)1.3.1 配置平台事务管理器1.3.2 Spring提供了事务管理的模板类1.3.3 在业务层注入事务管理的模板1.3.4 编写事务管理的代码1.4 声明式事务(xml配置)1.4.1 配置事务管理器1.4.2 配置增强1.4.3 AOP的配置1.5 声明式事务(注解)1.5.1 配置事务管理器
一个最不可思议的MySQL死锁分析1
08-03
最后，总结一下，死锁的分析和解决是一个综合性的任务，需要结合MySQL的事务处理、锁机制以及并发控制等多方面的知识。通过深入理解和解析死锁日志，我们可以更好地诊断和预防此类问题，从而提高数据库的性能和稳定...
一次离奇的 MySQL 死锁分析
12-14
MySQL中的死锁问题是一个复杂而微妙的议题，尤其是在高并发的业务环境中，死锁可能导致服务的不稳定甚至数据的不一致。在2016年11月15日的这个生产bug中，我们看到的问题核心在于两个事务间的资源争夺，最终导致了...
一次MYSQL死锁分析案例1
08-03
在MySQL数据库中，死锁是一种常见的并发问题，当两个或多个事务互相等待对方释放资源时，就会发生死锁。本案例中的死锁发生在“pop购药”系统的订单支付状态更新操作中，涉及到了两个事务，我们分别称之为Session1和...
一个mysql死锁场景实例分析
09-09
MySQL数据库在可重复读（Repeatable-Read）隔离级别下可能会遇到死锁的问题，这是一个典型的现象，我们将通过一个具体的死锁实例进行深入分析。在这个场景中，有两个会话（Session A 和 Session B），它们分别执行一...
Springboot注解@Transactional(propagation = Propagation.REQUIRED)
justlpf的专栏
06-12 1266
【代码】Springboot注解@Transactional(propagation = Propagation.REQUIRED)
Spring声明式事务@Transactional注解详解（事务）
Java后端技术栈
08-30 7009
前面讲过了如何使用使用xml中实现声明式事务，详见博客：Spring5_狂神（IOC，AOP，SpringMybatis，事务）https://blog.csdn.net/weixin_45433031/article/details/115976938 通过xml配置文件很不方便，那么现在我们来学习通过@Transactional注解实现Spring声明式事务 文章目录 一. 使用位置 二. 参数说明 三. 事务传播行为 四. 隔离级别 1. SQL标准规范 .
@Transactional事务回滚异常：Transaction rolled back because it has been marked as rollback-only
程序员Forlan的博客
01-08 7198
本文主要探讨了一个常见的Spring框架中的事务管理问题，即事务回滚异常@Transactional。首先，通过问题描述，让读者了解这个问题的现象和影响。然后，通过原因分析，深入解析了导致这个问题的几种可能原因，包括异常示例代码和查看源码。最后，通过解决方案部分，给出了解决这个问题的几种方法，并推荐了最佳实践。通过本文，读者可以更好地理解Spring框架中的事务管理机制，并学会如何解决常见的事务回滚异常问题。
Spring事务传播
小灰灰的博客
07-15 727
1.事务传播特性 2.实测 教员说过，实践是检验真理的唯一标准。 2.1 建表 mysql数据库 CREATE TABLE `student` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(45) NOT NULL DEFAULT '', PRIMARY KEY (`id`) ) ENGINE=Inn...
Spirng中事务的传播性
qq_62698326的博客
02-19 1550
Spring的事务传播
@Transactional 使用说明
weixin_44175409的博客
11-12 5164
Tranasctional注解是Spring 框架提供的声明式注解事务解决方案，我们在开发中使用事务保证方法对数据库操作的原子性，要么全部成功，要么全部失败，在使用@Transactional注解时需要注意以下问题:1. @Transactional 注解只能用在public 方法上，如果用在protected或者private的方法上，不会报错，但是该注解不会生效。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值