MySql一个生产死锁案例分析
接到上级一个生产环境MySQL死锁日志信息文件，需要找出原因并解决问题。我将死锁日志部分贴出如下：
在mysql中使用命令：SHOW ENGINE INNODB STATUS;总能获取到最近一些问题信息，通过搜索deadlock 关键字即可找到死锁的相关日志信息。
2019-09-25 13:28:25 7fc0301ca700InnoDB: transactions deadlock detected, dumping detailed information.
2019-09-25 13:28:25 7fc0301ca700
*** (1) TRANSACTION:
TRANSACTION 48000896642, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 5
MySQL thread id 1585229, OS thread handle 0x7fc030e7c700, query id 36142536228 100.64.177.170 oms8 updating
update tb_elc_forecast
set capital = capital - 1.0, outbound = outbound + 1.0
where id = 1131766 and capital >= 1.0
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1697 page no 31889 n bits 120 index `PRIMARY` of table `oms8`.`tb_elc_forecast` trx id 48000896642 lock_mode X locks rec but not gap waiting
Record lock, heap no 20 PHYSICAL RECORD: n_fields 46; compact format; info bits 0
0: len 4; hex 801144f6; asc D ;;
1: len 6; hex 000b2d138e83; asc - ;;
2: len 7; hex 1b0013b0a9145c; asc \;;
3: len 30; hex 3637666533626536382d616562622d313165392d393838332d6436636337; asc 67fe3be68-aebb-11e9-9883-d6cc7; (total 37 bytes);
4: len 10; hex 4d324c50303530303030; asc M2LP050000;;
5: len 11; hex 5730323130313439393137; asc W0210149917;;
6: len 4; hex 20bcbe4c; asc L;;
7: len 4; hex 000080bf; asc ;;
8: len 4; hex 006e2f47; asc n/G;;
9: len 4; hex 005c5646; asc \VF;;
10: len 4; hex 00000000; asc ;;
11: len 7; hex 323031392d3039; asc 2019-09;;
12: len 9; hex 4252414e4453495445; asc BRANDSITE;;
13: len 14; hex 776d735f656c635f62616f7a756e; asc wms_elc_baozun;;
14: len 4; hex 80000002; asc ;;
15: len 4; hex 80000001; asc ;;
16: len 4; hex 80000000; asc ;;
17: len 5; hex 99a3b313ab; asc ;;
18: SQL NULL;
19: len 3; hex 737973; asc sys;;
20: SQL NULL;
21: len 4; hex 80019737; asc 7;;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: SQL NULL;
26: SQL NULL;
27: len 2; hex 3130; asc 10;;
28: len 12; hex 4252414e44534954455f3130; asc BRANDSITE_10;;
29: SQL NULL;
30: len 30; hex 494c4c554d494e4154494e4720464143452042415345205320374d4c2f2e; asc ILLUMINATING FACE BASE S 7ML/.; (total 88 bytes);
31: len 9; hex 4252414e4453495445; asc BRANDSITE;;
32: len 1; hex 59; asc Y;;
33: len 1; hex 59; asc Y;;
34: len 4; hex 80000000; asc ;;
35: len 0; hex ; asc ;;
36: len 4; hex 00000000; asc ;;
37: len 4; hex 00000000; asc ;;
38: len 4; hex 80000000; asc ;;
39: len 4; hex 80000000; asc ;;
40: SQL NULL;
41: SQL NULL;
42: len 4; hex 00000000; asc ;;
43: len 4; hex 00000000; asc ;;
44: SQL NULL;
45: SQL NULL; *** (2) TRANSACTION:
TRANSACTION 48000896643, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 3
MySQL thread id 1584766, OS thread handle 0x7fc0301ca700, query id 36142536229 100.64.177.168 oms8 updating
update tb_elc_forecast
set capital = capital - 1.0, outbound = outbound + 1.0
where id = 1164727 and capital >= 1.0
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1697 page no 31889 n bits 120 index `PRIMARY` of table `oms8`.`tb_elc_forecast` trx id 48000896643 lock_mode X locks rec but not gap
Record lock, heap no 20 PHYSICAL RECORD: n_fields 46; compact format; info bits 0
0: len 4; hex 801144f6; asc D ;;
1: len 6; hex 000b2d138e83; asc - ;;
2: len 7; hex 1b0013b0a9145c; asc \;;
3: len 30; hex 3637666533626536382d616562622d313165392d393838332d6436636337; asc 67fe3be68-aebb-11e9-9883-d6cc7; (total 37 bytes);
4: len 10; hex 4d324c50303530303030; asc M2LP050000;;
5: len 11; hex 5730323130313439393137; asc W0210149917;;
6: len 4; hex 20bcbe4c; asc L;;
7: len 4; hex 000080bf; asc ;;
8: len 4; hex 006e2f47; asc n/G;;
9: len 4; hex 005c5646; asc \VF;;
10: len 4; hex 00000000; asc ;;
11: len 7; hex 323031392d3039; asc 2019-09;;
12: len 9; hex 4252414e4453495445; asc BRANDSITE;;
13: len 14; hex 776d735f656c635f62616f7a756e; asc wms_elc_baozun;;
14: len 4; hex 80000002; asc ;;
15: len 4; hex 80000001; asc ;;
16: len 4; hex 80000000; asc ;;
17: len 5; hex 99a3b313ab; asc ;;
18: SQL NULL;
19: len 3; hex 737973; asc sys;;
20: SQL NULL;
21: len 4; hex 80019737; asc 7;;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: SQL NULL;
26: SQL NULL;
27: len 2; hex 3130; asc 10;;
28: len 12; hex 4252414e44534954455f3130; asc BRANDSITE_10;;
29: SQL NULL;
30: len 30; hex 494c4c554d494e4154494e4720464143452042415345205320374d4c2f2e; asc ILLUMINATING FACE BASE S 7ML/.; (total 88 bytes);
31: len 9; hex 4252414e4453495445; asc BRANDSITE;;
32: len 1; hex 59; asc Y;;
33: len 1; hex 59; asc Y;;
34: len 4; hex 80000000; asc ;;
35: len 0; hex ; asc ;;
36: len 4; hex 00000000; asc ;;
37: len 4; hex 00000000; asc ;;
38: len 4; hex 80000000; asc ;;
39: len 4; hex 80000000; asc ;;
40: SQL NULL;
41: SQL NULL;
42: len 4; hex 00000000; asc ;;
43: len 4; hex 00000000; asc ;;
44: SQL NULL;
45: SQL NULL; *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1697 page no 33024 n bits 120 index `PRIMARY` of table `oms8`.`tb_elc_forecast` trx id 48000896643 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 46; compact format; info bits 0
0: len 4; hex 8011c5b7; asc ;;
1: len 6; hex 000b2d138e82; asc - ;;
2: len 7; hex 1a0013b08b1598; asc ;;
3: len 30; hex 3638303365643664302d616562622d313165392d613830332d6436636337; asc 6803ed6d0-aebb-11e9-a803-d6cc7; (total 37 bytes);
4: len 10; hex 53383648343030303030; asc S86H400000;;
5: len 11; hex 5730323130313439393137; asc W0210149917;;
6: len 4; hex 20bcbe4c; asc L;;
7: len 4; hex 000080bf; asc ;;
8: len 4; hex 4001b448; asc @ H;;
9: len 4; hex 80c6de47; asc G;;
10: len 4; hex 00000000; asc ;;
11: len 7; hex 323031392d3039; asc 2019-09;;
12: len 9; hex 4252414e4453495445; asc BRANDSITE;;
13: len 14; hex 776d735f656c635f62616f7a756e; asc wms_elc_baozun;;
14: len 4; hex 80000002; asc ;;
15: len 4; hex 80000001; asc ;;
16: len 4; hex 80000000; asc ;;
17: len 5; hex 99a3b313b1; asc ;;
18: SQL NULL;
19: len 3; hex 737973; asc sys;;
20: SQL NULL;
21: len 4; hex 80019737; asc 7;;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: SQL NULL;
26: SQL NULL;
27: len 2; hex 3130; asc 10;;
28: len 12; hex 4252414e44534954455f3130; asc BRANDSITE_10;;
29: SQL NULL;
30: len 30; hex 494c4c554d494e4154494e4720464143452042415345205320374d4c2f2e; asc ILLUMINATING FACE BASE S 7ML/.; (total 88 bytes);
31: len 9; hex 4252414e4453495445; asc BRANDSITE;;
32: len 1; hex 59; asc Y;;
33: len 1; hex 59; asc Y;;
34: len 4; hex 80000000; asc ;;
35: len 0; hex ; asc ;;
36: len 4; hex 00000000; asc ;;
37: len 4; hex 00000000; asc ;;
38: len 4; hex 80000000; asc ;;
39: len 4; hex 80000000; asc ;;
40: SQL NULL;
41: SQL NULL;
42: len 4; hex 00000000; asc ;;
43: len 4; hex 00000000; asc ;;
44: SQL NULL;
45: SQL NULL; *** WE ROLL BACK TRANSACTION (2)
通过分析日志，我们知道如下信息：
1.发生死锁的两个事务中的SQL
事务1.update tb_elc_forecast
set capital = capital - 1.0, outbound = outbound + 1.0
where id = 1131766 and capital >= 1.0 事务2.update tb_elc_forecast
set capital = capital - 1.0, outbound = outbound + 1.0
where id = 1164727 and capital >= 1.0
2.两条SQL都使用了Record lock(locks rec but not gap)记录锁(非间隙所)
通过查看表结构定义得知tb_elc_forecast将id字段定义为主键，表结构如下(精简版)：
CREATE TABLE `tb_elc_forecast` (
`id` int(10) NOT NULL AUTO_INCREMENT COMMENT 'id自增',
`sku` varchar(50) NOT NULL COMMENT '商品',
`customerid` varchar(50) DEFAULT NULL COMMENT '货主',
`capital` float(10,2) DEFAULT '0.00' COMMENT '占用',
`outbound` float(10,2) DEFAULT '0.00' COMMENT '出库',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
通过以上信息，我们不难发现，肇事SQL会先对主键聚集索引加记录排他锁，而不是间隙锁。理论上好像怎么都不会产生死锁。因为这里只有一个临界资源，那就是聚集索引。从理论上来说，要发生死锁，必须存在至少两个临界资源，两个独立事务，且每个事务执行过程中相间执行，互锁对方需要的临界资源，从而导致死锁。示意图如下:
通过以上死锁理论理解分析，似乎光看这两个肇事SQL，不足以发生死锁的条件。那是为什么呢？我们不能孤立在这堆死锁日志里分析问题，应该去程序代码里找，找到肇事SQL所在的事务代码才行。这个死锁日志只是表达了发生死锁时涉事的两个SQL。并不一定能直接分析得出问题结论。
根据目前的情况，我做出如下假设：
1.事务A执行update tb_elc_forecast set capital = capital - 1.0, outbound = outbound + 1.0 where id = 1131766 and capital >= 1.0 前，id=1131766的记录被事务B查询了，加了共享锁在可重复读事务隔离级别下。同样事务B执行update tb_elc_forecast set capital = capital - 1.0, outbound = outbound + 1.0 where id = 1164727 and capital >= 1.0 前，id=1164727的记录被事务A查询了，加了共享锁在可重复读事务隔离级别下。最终两个事务的update语句无法获取id记录的排他锁导致死锁。
那么事情果真如此吗？通过模拟测试，结果是否定的。
事实上MySQL对于查询语句，只要查询完成就会释放共享锁，而不必等待事务结束，且和事务隔离级别无关。所以此种情况应该排除。
2.T1时刻事务A执行update tb_elc_forecast set capital = capital - 1.0, outbound = outbound + 1.0 where id = 1131766 and capital >= 1.0 事务B执行update tb_elc_forecast set capital = capital - 1.0, outbound = outbound + 1.0 where id = 1164727
and capital >= 1.0
T2时刻事务A执行update tb_elc_forecast set capital = capital - 1.0, outbound = outbound + 1.0 where id = 1164727 and capital >= 1.0 事务B执行update tb_elc_forecast set capital = capital - 1.0, outbound = outbound + 1.0 where id = 1131766
and capital >= 1.0。每个事务通过执行两个update操作，这样形成了死锁条件。
那么事情果真如此吗？通过模拟测试，结果是肯定的。
结合死锁图示，这里的临界资源1是id=1164727的记录锁，临界资源是id=1131766 的记录锁。update操作会占用各自id的记录锁资源。
通过一番查找，比较容易找到程序里对应的事务代码（使用了肇事SQL的业务逻辑代码），贴出部分如下：
for (ElcForecastTran entity : insertList) {
ElcForecast elcForecast = new ElcForecast();
String period = new SimpleDateFormat("yyyy-MM").format(request.getOrderTime());
elcForecast.setCustomerid(entity.getCustomerid());
elcForecast.setSku(entity.getSku());
elcForecast.setPeriod(period);
elcForecast.setTp(entity.getTp());
elcForecast.setChannel(entity.getChannel());
elcForecast.setDepth(2); // 子代理
elcForecast.setIsActive(1); // 已发布
Integer id = elcForecastMapper.selectId(elcForecast);
if(id == null){
isCapitalForecastFail = true;
builder.append(entity.getSku()).append(",");
logger.error("updateCapital fail,update forecast:{},request:{}",elcForecast,request);
continue;
}
elcForecast.setId(id);
elcForecast.setCapital(entity.getCapital()); // 占用额度
cnt = elcForecastMapper.updateCapitalOutbound(elcForecast);
}
通过上下业务环境得知，此处事务方法，会存在同时被多线程调用问题，且代码：elcForecastMapper.updateCapitalOutbound(elcForecast);置于循环语句中，更新的对象elcForecast再不同线程中可能会存在重复的对象，故形成上述2死锁猜想条件。
那么怎么解决呢？可能有多种方法，一种是将事务拆分成小事务，不要把整个循环置于一个事务中。二是对此处事务加分布式锁，保证一次只允许一个线程调用即可。具体方案视业务情况来定。
接下来我通过一个具体的死锁实验来讲述以上死锁发生的原理
首先打开两个MySQL客户端，并执行set SESSION autocommit=0;关闭事务自动提交功能
准备两条测试SQL：update tb_elc_forecast set capital = capital - 1.0 where id=5133;和update tb_elc_forecast set capital = capital - 1.0 where id=5137;
分别在两个客户端执行事务启动语句：START TRANSACTION;
客户端A执行：update tb_elc_forecast set capital = capital - 1.0 where id=5133;
客户端B执行：update tb_elc_forecast set capital = capital - 1.0 where id=5137;
客户端A执行：update tb_elc_forecast set capital = capital - 1.0 where id=5137;
客户端B执行：update tb_elc_forecast set capital = capital - 1.0 where id=5133;
此时你该看到客户端B死锁发生了，并牺牲了自己，让客户端A事务存活。
客户端A执行：commit;
客户端B执行：commit;
实验如图：
分别为客户端A和B截图
客户端执行：SHOW ENGINE INNODB STATUS;
可以看到MySQL最近的死锁信息记录如下：
=====================================
2019-09-25 19:32:10 0x3a88 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 10 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 44 srv_active, 0 srv_shutdown, 4905 srv_idle
srv_master_thread log flush and writes: 4949
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 40
OS WAIT ARRAY INFO: signal count 41
RW-shared spins 0, rounds 78, OS waits 35
RW-excl spins 0, rounds 39, OS waits 1
RW-sx spins 2, rounds 60, OS waits 2
Spin rounds per wait: 78.00 RW-shared, 39.00 RW-excl, 30.00 RW-sx
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-09-25 19:31:55 0x52c4
*** (1) TRANSACTION:
TRANSACTION 304429, ACTIVE 37 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 13, OS thread handle 27608, query id 12406 localhost ::1 root updating
update tb_elc_forecast set capital = capital - 1.0 where id=5137
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 467 page no 6 n bits 120 index PRIMARY of table `test`.`tb_elc_forecast` trx id 304429 lock_mode X locks rec but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 44; compact format; info bits 0
0: len 4; hex 80001411; asc ;;
1: len 6; hex 00000004a52e; asc .;;
2: len 7; hex 22000002f72374; asc " #t;;
3: len 30; hex 39643231346264652d656532312d343034612d393862632d396261356232; asc 9d214bde-ee21-404a-98bc-9ba5b2; (total 36 bytes);
4: len 10; hex 304d4d30303130303030; asc 0MM0010000;;
5: len 7; hex 59534c44303031; asc YSLD001;;
6: len 4; hex 0000a041; asc A;;
7: len 4; hex 000080bf; asc ;;
8: len 4; hex 000040c0; asc @ ;;
9: len 4; hex 00000000; asc ;;
10: len 4; hex 00000000; asc ;;
11: len 7; hex 323031392d3033; asc 2019-03;;
12: len 9; hex 4252414e4453495445; asc BRANDSITE;;
13: len 14; hex 776d735f656c635f62616f7a756e; asc wms_elc_baozun;;
14: len 4; hex 80000002; asc ;;
15: len 4; hex 80000000; asc ;;
16: len 4; hex 80000000; asc ;;
17: len 5; hex 99a282e9bb; asc ;;
18: SQL NULL;
19: len 6; hex 363739303539; asc 679059;;
20: SQL NULL;
21: len 4; hex 8000140d; asc ;;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: SQL NULL;
26: SQL NULL;
27: len 2; hex 3031; asc 01;;
28: len 12; hex 4252414e44534954455f3031; asc BRANDSITE_01;;
29: SQL NULL;
30: len 30; hex 4c4f43204332204242205741544552e280bbe580a9e7a2a7e6b481e99da2; asc LOC C2 BB WATER ; (total 45 bytes);
31: len 9; hex 4252414e4453495445; asc BRANDSITE;;
32: len 1; hex 59; asc Y;;
33: len 1; hex 59; asc Y;;
34: len 4; hex 80000000; asc ;;
35: SQL NULL;
36: len 4; hex 00000000; asc ;;
37: len 4; hex 00000000; asc ;;
38: len 4; hex 80000000; asc ;;
39: len 4; hex 80000000; asc ;;
40: SQL NULL;
41: SQL NULL;
42: len 4; hex 00000000; asc ;;
43: len 4; hex 00000000; asc ;; *** (2) TRANSACTION:
TRANSACTION 304430, ACTIVE 30 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 14, OS thread handle 21188, query id 12407 localhost ::1 root updating
update tb_elc_forecast set capital = capital - 1.0 where id=5133
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 467 page no 6 n bits 120 index PRIMARY of table `test`.`tb_elc_forecast` trx id 304430 lock_mode X locks rec but not gap
Record lock, heap no 6 PHYSICAL RECORD: n_fields 44; compact format; info bits 0
0: len 4; hex 80001411; asc ;;
1: len 6; hex 00000004a52e; asc .;;
2: len 7; hex 22000002f72374; asc " #t;;
3: len 30; hex 39643231346264652d656532312d343034612d393862632d396261356232; asc 9d214bde-ee21-404a-98bc-9ba5b2; (total 36 bytes);
4: len 10; hex 304d4d30303130303030; asc 0MM0010000;;
5: len 7; hex 59534c44303031; asc YSLD001;;
6: len 4; hex 0000a041; asc A;;
7: len 4; hex 000080bf; asc ;;
8: len 4; hex 000040c0; asc @ ;;
9: len 4; hex 00000000; asc ;;
10: len 4; hex 00000000; asc ;;
11: len 7; hex 323031392d3033; asc 2019-03;;
12: len 9; hex 4252414e4453495445; asc BRANDSITE;;
13: len 14; hex 776d735f656c635f62616f7a756e; asc wms_elc_baozun;;
14: len 4; hex 80000002; asc ;;
15: len 4; hex 80000000; asc ;;
16: len 4; hex 80000000; asc ;;
17: len 5; hex 99a282e9bb; asc ;;
18: SQL NULL;
19: len 6; hex 363739303539; asc 679059;;
20: SQL NULL;
21: len 4; hex 8000140d; asc ;;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: SQL NULL;
26: SQL NULL;
27: len 2; hex 3031; asc 01;;
28: len 12; hex 4252414e44534954455f3031; asc BRANDSITE_01;;
29: SQL NULL;
30: len 30; hex 4c4f43204332204242205741544552e280bbe580a9e7a2a7e6b481e99da2; asc LOC C2 BB WATER ; (total 45 bytes);
31: len 9; hex 4252414e4453495445; asc BRANDSITE;;
32: len 1; hex 59; asc Y;;
33: len 1; hex 59; asc Y;;
34: len 4; hex 80000000; asc ;;
35: SQL NULL;
36: len 4; hex 00000000; asc ;;
37: len 4; hex 00000000; asc ;;
38: len 4; hex 80000000; asc ;;
39: len 4; hex 80000000; asc ;;
40: SQL NULL;
41: SQL NULL;
42: len 4; hex 00000000; asc ;;
43: len 4; hex 00000000; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 467 page no 6 n bits 120 index PRIMARY of table `test`.`tb_elc_forecast` trx id 304430 lock_mode X locks rec but not gap waiting
Record lock, heap no 54 PHYSICAL RECORD: n_fields 44; compact format; info bits 0
0: len 4; hex 8000140d; asc ;;
1: len 6; hex 00000004a52d; asc -;;
2: len 7; hex 21000002d522ea; asc ! " ;;
3: len 30; hex 34326237346466332d383133372d346639372d393435382d613939613266; asc 42b74df3-8137-4f97-9458-a99a2f; (total 36 bytes);
4: len 10; hex 304d4d30303130303030; asc 0MM0010000;;
5: len 7; hex 59534c44303031; asc YSLD001;;
6: len 4; hex 00004842; asc HB;;
7: len 4; hex 000080bf; asc ;;
8: len 4; hex 000040c0; asc @ ;;
9: SQL NULL;
10: len 4; hex 00004842; asc HB;;
11: len 7; hex 323031392d3033; asc 2019-03;;
12: SQL NULL;
13: SQL NULL;
14: len 4; hex 80000001; asc ;;
15: len 4; hex 80000002; asc ;;
16: len 4; hex 80000001; asc ;;
17: len 5; hex 99a282e9bb; asc ;;
18: len 5; hex 99a288b39e; asc ;;
19: len 6; hex 363739303539; asc 679059;;
20: SQL NULL;
21: SQL NULL;
22: SQL NULL;
23: SQL NULL;
24: SQL NULL;
25: SQL NULL;
26: SQL NULL;
27: len 2; hex 3031; asc 01;;
28: len 12; hex 4252414e44534954455f3031; asc BRANDSITE_01;;
29: SQL NULL;
30: len 30; hex 4c4f43204332204242205741544552e280bbe580a9e7a2a7e6b481e99da2; asc LOC C2 BB WATER ; (total 45 bytes);
31: len 9; hex 4252414e4453495445; asc BRANDSITE;;
32: len 1; hex 59; asc Y;;
33: len 1; hex 59; asc Y;;
34: len 4; hex 80000000; asc ;;
35: SQL NULL;
36: len 4; hex 00006041; asc `A;;
37: len 4; hex 00000000; asc ;;
38: len 4; hex 80000002; asc ;;
39: len 4; hex 80000001; asc ;;
40: len 21; hex 4f4d53e5ba93e5ad98e69fa5e8afa2e68890e58a9f; asc OMS ;;
41: len 30; hex 61303730393438612d633531642d346331362d616433392d393434393038; asc a070948a-c51d-4c16-ad39-944908; (total 36 bytes);
42: len 4; hex 00000000; asc ;;
43: len 4; hex 00000000; asc ;; *** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------
Trx id counter 304432
Purge done for trx's n:o < 304432 undo n:o < 0 state: running but idle
History list length 13
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 283332952971320, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283332952973936, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283332952973064, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283332952972192, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283332952968704, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283332952967832, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 283332952966960, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 304429, ACTIVE 52 sec
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2
MySQL thread id 13, OS thread handle 27608, query id 12406 localhost ::1 root
---TRANSACTION 304408, ACTIVE 4442 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 9, OS thread handle 14984, query id 12411 localhost 127.0.0.1 root starting
show ENGINE INNODB STATUS
---TRANSACTION 304407, ACTIVE 4450 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 8, OS thread handle 25856, query id 12278 localhost 127.0.0.1 root
--------
FILE I/O
--------
I/O thread 0 state: wait Windows aio (insert buffer thread)
I/O thread 1 state: wait Windows aio (log thread)
I/O thread 2 state: wait Windows aio (read thread)
I/O thread 3 state: wait Windows aio (read thread)
I/O thread 4 state: wait Windows aio (read thread)
I/O thread 5 state: wait Windows aio (read thread)
I/O thread 6 state: wait Windows aio (write thread)
I/O thread 7 state: wait Windows aio (write thread)
I/O thread 8 state: wait Windows aio (write thread)
I/O thread 9 state: wait Windows aio (write thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: 0; buffer pool: 0
609 OS file reads, 1233 OS file writes, 226 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 207, seg size 209, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 2267, node heap has 0 buffer(s)
Hash table size 2267, node heap has 1 buffer(s)
Hash table size 2267, node heap has 0 buffer(s)
Hash table size 2267, node heap has 0 buffer(s)
Hash table size 2267, node heap has 0 buffer(s)
Hash table size 2267, node heap has 0 buffer(s)
Hash table size 2267, node heap has 0 buffer(s)
Hash table size 2267, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 412469041
Log flushed up to 412469041
Pages flushed up to 412469041
Last checkpoint at 412469032
0 pending log flushes, 0 pending chkp writes
118 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 8585216
Dictionary memory allocated 128725
Buffer pool size 512
Free buffers 255
Database pages 256
Old database pages 0
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 580, created 672, written 1023
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 256, unzip_LRU len: 0
I/O sum[10]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=27356, Main thread ID=21352, state: sleeping
Number of rows inserted 13258, updated 11, deleted 0, read 108651
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
关于死锁测试，最好使用MySQL自带的Console客户端实验，不要使用第三方可视化工具，效果不太好。
MySql一个生产死锁案例分析的更多相关文章
- [转]MySQL批量更新死锁案例分析
文章出处:http://blog.csdn.net/aesop_wubo/article/details/8286215 问题描述 在做项目的过程中,由于写SQL太过随意,一不小心就抛了一个死锁异常, ...
- MySQL批量更新死锁案例分析--转载
问题描述 在做项目的过程中,由于写SQL太过随意,一不小心就抛了一个死锁异常,如下: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackE ...
- MySQL死锁案例分析与解决方案
MySQL死锁案例分析与解决方案 现象: 数据库查询: SQL语句分析: mysql. 并发delete同一行记录,偶发死锁. delete from x_table where id=? ...
- 170301、使用Spring AOP实现MySQL数据库读写分离案例分析
使用Spring AOP实现MySQL数据库读写分离案例分析 原创 2016-12-29 徐刘根 Java后端技术 一.前言 分布式环境下数据库的读写分离策略是解决数据库读写性能瓶颈的一个关键解决方案 ...
- 161220、使用Spring AOP实现MySQL数据库读写分离案例分析
一.前言 分布式环境下数据库的读写分离策略是解决数据库读写性能瓶颈的一个关键解决方案,更是最大限度了提高了应用中读取 (Read)数据的速度和并发量. 在进行数据库读写分离的时候,我们首先要进行数据库 ...
- mysql转ElasticSearch的案例分析
前言 最近工作中在进行一些技术优化,为了减少对数据库的压力,对于只读操作,在程序与db之间加了一层-ElasticSearch.具体实现是db与es通过bin-log进行同步,保证数据一致性,代码调用 ...
- 使用Spring AOP实现MySQL数据库读写分离案例分析
一.前言 分布式环境下数据库的读写分离策略是解决数据库读写性能瓶颈的一个关键解决方案,更是最大限度了提高了应用中读取 (Read)数据的速度和并发量. 在进行数据库读写分离的时候,我们首先要进行数据库 ...
- MySQL实例crash的案例分析
[作者] 王栋:携程技术保障中心数据库专家,对数据库疑难问题的排查和数据库自动化智能化运维工具的开发有强烈的兴趣. [问题描述] 我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21 ...
- MySQL排序原理与案例分析
前言 排序是数据库中的一个基本功能,MySQL也不例外.用户通过Order by语句即能达到将指定的结果集排序的目的,其实不仅仅是Order by语句,Group by语句,Distinct ...
随机推荐
- Codeforces Round #506 (Div. 3) 1029 F. Multicolored Markers
CF-1029F 题意: a,b个小正方形构造一个矩形,大小为(a+b),并且要求其中要么a个小正方形是矩形,要么b个小正方形是矩形. 思路: 之前在想要分a,b是否为奇数讨论,后来发现根本不需要.只 ...
- CodeForces-768B-Code For 1+DFS类似线段树思想
Code For 1 题意:对于一个n,可以将它分解为n/2,n%2,n/2三个数字,重复上述操作知道虽有值为1或0为止: 求L---R区间数列的和: 思路:首先画着画着可以发现这是一个类似线段数的结 ...
- lightoj 1173 - The Vindictive Coach（dp）
题目链接:http://www.lightoj.com/volume_showproblem.php?problem=1173 题解:像这种题目显然可以想到n为几时一共有几种排列可以递推出来.然后就是 ...
- lightoj 1134 - Be Efficient（组合数）
题目链接:http://www.lightoj.com/volume_showproblem.php?problem=1134 题解:简单的一道组合题,现求一下前缀和,然后只要找前缀和膜m的结果相同的 ...
- 牛客第五场 G max 思维
链接:https://www.nowcoder.com/acm/contest/143/G来源:牛客网 Give two positive integer c, n. You need to find ...
- codeforces E. Trains and Statistic（线段树+dp）
题目链接:http://codeforces.com/contest/675/problem/E 题意:你可以从第 i 个车站到 [i + 1, a[i]] 之间的车站花一张票.p[i][j]表示从 ...
- Java连载28-内存分析
一.方法在执行过程中是如何分配内存的,内存是如何变化的? 1.方法只定义,不调用,是不会执行的,并且在JVM中也不会给该方法分配”运行所属“的内存空间,只有在调用这个方法的时候,才会动态的给这个方法分 ...
- mariadb数据库galera下添加新的服务器节点
昨天经过各种努力,终于完成了两台服务器集成的搭建,今天再新开一台服务器,在想如何加入呢?网上度娘了很久结果没搜到相关文章:哎,索性直接照着前两台服务配置,在第三台(新服务器)上配置完成后重启maria ...
- Vue中如何使用less
最近发现好多小伙伴在面试的过程中会问到vue如何使用less和scss,所以我绝对更新.复习一下less:废话不多说直接进主题: 依赖下载 1.首先使用npm下载依赖: npm install --s ...
- Go语言标准库之fmt
fmt标准库是我们在学习Go语言过程中接触最早最频繁的一个了,本文介绍了fmtb包的一些常用函数. fmt fmt包实现了类似C语言printf和scanf的格式化I/O.主要分为向外输出内容和获取输 ...