11
我通过“SHOW INNODB STATUS”收到了以下死锁日志。有人可以关心解释交易被中止的原因吗？看起来，事务2持有锁，但也被阻止请求相同的锁（除了“等待”部分），当事务1需要它时导致死锁。需要Mysql死锁解释
=====================================
091205 6:25:01 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 39 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 233826, signal count 229982
Mutex spin waits 0, rounds 1569878, OS waits 4740
RW-shared spins 517345, OS waits 227127; RW-excl spins 4390, OS waits 1945
------------------------
LATEST DETECTED DEADLOCK
------------------------
091205 6:19:35
*** (1) TRANSACTION:
TRANSACTION 0 479286429, ACTIVE 0 sec, process no 17618, OS thread id 2963139472 fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 176 lock struct(s), heap size 11584
MySQL thread id 330396, query id 97467367 64-71-26-218.static.wiline.com 64.71.26.218 autotaggeruser Sorting result
SELECT api_key,completed,compute_units,created,deleted,flags,func_name,group_id,hostname,is_meta,jid,label,language,num_children,parent_ujid,priority,process_id,restartable,status,type,uid,ujid,version,wid FROM jobs WHERE status='new' and is_meta=0 ORDER BY priority asc,jid asc FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 17549 n bits 128 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286429 lock_mode X waiting
Record lock, heap no 61 PHYSICAL RECORD: n_fields 26; compact format; info bits 0
0: len 8; hex 800000000000277c; asc '|;; 1: len 6; hex 00001c915499; asc T ;; 2: len 7; hex 00000006e21e2a; asc *;; 3: len 8; hex 8000000000000002; asc ;; 4: len 8; hex 8000000000000845; asc E;; 5: SQL NULL; 6: len 8; hex 8000000000002773; asc 's;; 7: len 1; hex 80; asc ;; 8: len 8; hex 8000000000000002; asc ;; 9: len 16; hex 636f72656f66746865627261696e2d75; asc coreofthebrain-u;; 10: len 4; hex 80000eb8; asc ;; 11: len 1; hex 01; asc ;; 12: len 30; hex 322e362e32202872656c6561736532362d6d61696e742c20417072203139; asc 2.6.2 (release26-maint, Apr 19;...(truncated); 13: len 30; hex 5f5f6d61696e5f5f2e3c6c616d6264613e206174203c737464696e3e3a31; asc __main__.<lambda> at <stdin>:1;; 14: len 5; hex 8000000001; asc ;; 15: len 0; hex ; asc ;; 16: len 4; hex 80000000; asc ;; 17: len 4; hex 80000005; asc ;; 18: len 4; hex 4b19fb58; asc K X;; 19: len 4; hex 4b19fb77; asc K w;; 20: len 1; hex 07; asc ;; 21: len 1; hex 80; asc ;; 22: len 4; hex 80000000; asc ;; 23: len 4; hex 80000000; asc ;; 24: len 1; hex 80; asc ;; 25: len 4; hex 80001415; asc ;;
*** (2) TRANSACTION:
TRANSACTION 0 479286425, ACTIVE 0 sec, process no 17618, OS thread id 2971134864 starting index read, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
7 lock struct(s), heap size 1024, undo log entries 3
MySQL thread id 330430, query id 97467371 64-71-26-218.static.wiline.com 64.71.26.218 autotaggeruser Updating
UPDATE jobs SET status='done' WHERE jid=10099
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 17549 n bits 128 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286425 lock_mode X locks rec but not gap
Record lock, heap no 61 PHYSICAL RECORD: n_fields 26; compact format; info bits 0
0: len 8; hex 800000000000277c; asc '|;; 1: len 6; hex 00001c915499; asc T ;; 2: len 7; hex 00000006e21e2a; asc *;; 3: len 8; hex 8000000000000002; asc ;; 4: len 8; hex 8000000000000845; asc E;; 5: SQL NULL; 6: len 8; hex 8000000000002773; asc 's;; 7: len 1; hex 80; asc ;; 8: len 8; hex 8000000000000002; asc ;; 9: len 16; hex 636f72656f66746865627261696e2d75; asc coreofthebrain-u;; 10: len 4; hex 80000eb8; asc ;; 11: len 1; hex 01; asc ;; 12: len 30; hex 322e362e32202872656c6561736532362d6d61696e742c20417072203139; asc 2.6.2 (release26-maint, Apr 19;...(truncated); 13: len 30; hex 5f5f6d61696e5f5f2e3c6c616d6264613e206174203c737464696e3e3a31; asc __main__.<lambda> at <stdin>:1;; 14: len 5; hex 8000000001; asc ;; 15: len 0; hex ; asc ;; 16: len 4; hex 80000000; asc ;; 17: len 4; hex 80000005; asc ;; 18: len 4; hex 4b19fb58; asc K X;; 19: len 4; hex 4b19fb77; asc K w;; 20: len 1; hex 07; asc ;; 21: len 1; hex 80; asc ;; 22: len 4; hex 80000000; asc ;; 23: len 4; hex 80000000; asc ;; 24: len 1; hex 80; asc ;; 25: len 4; hex 80001415; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 17548 n bits 144 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286425 lock_mode X locks rec but not gap waiting
Record lock, heap no 73 PHYSICAL RECORD: n_fields 26; compact format; info bits 0
0: len 8; hex 8000000000002773; asc 's;; 1: len 6; hex 00001c9151f5; asc Q ;; 2: len 7; hex 800000003c0110; asc < ;; 3: len 8; hex 8000000000000002; asc ;; 4: len 8; hex 800000000000083d; asc =;; 5: SQL NULL; 6: SQL NULL; 7: len 1; hex 81; asc ;; 8: len 8; hex 8000000000000002; asc ;; 9: len 16; hex 636f72656f66746865627261696e2d75; asc coreofthebrain-u;; 10: len 4; hex 80000eb8; asc ;; 11: len 1; hex 01; asc ;; 12: len 30; hex 322e362e32202872656c6561736532362d6d61696e742c20417072203139; asc 2.6.2 (release26-maint, Apr 19;...(truncated); 13: len 30; hex 5f5f6d61696e5f5f2e3c6c616d6264613e206174203c737464696e3e3a31; asc __main__.<lambda> at <stdin>:1;; 14: len 5; hex 8000000001; asc ;; 15: len 0; hex ; asc ;; 16: len 4; hex 80000000; asc ;; 17: len 4; hex 80000005; asc ;; 18: len 4; hex 4b19fb58; asc K X;; 19: SQL NULL; 20: len 1; hex 02; asc ;; 21: len 1; hex 80; asc ;; 22: len 4; hex 80000014; asc ;; 23: len 4; hex 80000000; asc ;; 24: len 1; hex 80; asc ;; 25: SQL NULL;
*** WE ROLL BACK TRANSACTION (1)
感谢您的快速响应。我确实确定了这两个查询，并且我发现更新与更新冲突。我的问题更符合以下几点：为什么UPDATE查询不能完成？它的交易已经持有适当的锁定。 另外，READ COMMITTED不是一个可能的解决方案，因为我不能从SELECT查询中得到陈旧的结果。 – BrainCore 2009-12-05 08:27:50
@BrainCore：在LOCK IN SHARE MODE中设置锁定，当事务被提交或回滚时释放FOR UPDATE读取。 – 2009-12-05 08:36:10
@OMG小马：过去我已经看到过无数次这种说法。这听起来是否合理：事务2获得这些锁“lock_mode X锁定rec但不是间隙”在桌上。然后，事务1等待事务2拥有的该表的“lock_mode X waiting”。事务2然后执行另一个需要“lock_mode X锁定rec而不是间隙等待”的查询（正在等待实际的锁类型？） 。既然它已经有这些锁，为什么它不只是使用它们？它是否陷入了事务1的请求，即FIFO队列？ – BrainCore 2009-12-05 09:01:55