您如何读取 MySQL InnoDB Monitor 输出？

Question

我是数据库管理的新手。我试图找出死锁异常的原因，但我无法理解日志。

日志显示“事务 1 已回滚”。为什么会这样？赌注表与帐户表有外键关系，但它（运行插入的反式）无法获得 S 锁并因此因死锁而死亡是否“正常”？我的意思是，考虑到它只是验证参照完整性的读取，这似乎很糟糕。

第二笔交易也在写入赌注表，但没有更新。那么是用于创建 auto-inc 键的“机制”还是索引机制或两者都导致死锁？为什么它们不会以连续的方式发生？或者可能是他们，但某种等待时间太短了。

任何帮助，指针，进一步阅读如何使用下面的日志来解决死锁问题表示赞赏。

111031 17:39:26
*** (1) TRANSACTION:
TRANSACTION 0 984899905, ACTIVE 180 sec, process no 10882, OS thread id 1104619856 inserting
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 3024, undo log entries 86
MySQL thread id 122, query id 28932942 localhost 127.0.0.1 bt update

INSERT INTO wager (amount_won, confirmation, created_by_partner, creation_date, description, fantasy_league, 
     first_game_start, image_thumb, image_wide, kind, last_game_start, last_update_version, locked, name, 
     num_future, num_past, num_present, partner, partner_wager_id, percent, progressive_num, result, status, 
     sub_kind, teaser_type, user_account, wager_amount, win_amount) 
 VALUES (null, 2, 1, '2011-10-31 17:39:26', 'Straight Bet', null, null, 'http://iphonebet_s.png', 
     'http://iphonebet_l.png', 9, null, 0, 1, 'NFL: KC +4, -140', 0, 0, 0, 26, '39812820-1', 
     null, null, 1, 1, null, null, 2176, '7000', '5000')

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 2712 n bits 264 index `PRIMARY` of table `bt/user_account` trx id 0 984899905 lock mode S locks rec but not gap waiting
Record lock, heap no 126 


*** (2) TRANSACTION:
TRANSACTION 0 984900638, ACTIVE 61 sec, process no 10882, OS thread id 1076607312 setting auto-inc lock
mysql tables in use 1, locked 1
38 lock struct(s), heap size 6752, undo log entries 147
MySQL thread id 121, query id 28932947 localhost 127.0.0.1 bt update
INSERT INTO wager (amount_won, confirmation, created_by_partner, creation_date, description, fantasy_league, 
     first_game_start, image_thumb, image_wide, kind, last_game_start, last_update_version, locked, name, 
     num_future, num_past, num_present, partner, partner_wager_id, percent, progressive_num, result, status, 
     sub_kind, teaser_type, user_account, wager_amount, win_amount) 
 VALUES (null, 2, 1, '2011-10-31 17:39:26', 'Straight Bet', null, null, 'http://iphonebet_s.png', 
     'http://iphonebet_l.png', 9, null, 0, 1, 'NFL: SD/KC o +7.5', 0, 0, 0, 26, '39812916-1', 
     null, null, 1, 1, null, null, 2045, '260', '200')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 2712 n bits 264 index `PRIMARY` of table `bt/user_account` trx id 0 984900638 lock_mode X locks rec but not gap
Record lock, heap no 72 
Record lock, heap no 107 
Record lock, heap no 126 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `bt/wager` trx id 0 984900638 lock mode AUTO-INC waiting
*** WE ROLL BACK TRANSACTION (1)

Answer 1

请看一下你问题中的这句话

*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 2712 n bits 264 index `PRIMARY` of table `bt/user_account` trx id 0 984899905 lock mode S locks rec but not gap waiting 
Record lock, heap no 126  

它说事务 1 中index PRIMARY有一个共享锁 ( )lock mode S

现在，看看你的问题中的这个短语

*** (2) HOLDS THE LOCK(S):     
RECORD LOCKS space id 0 page no 2712 n bits 264 index `PRIMARY` of table `bt/user_account` trx id 0 984900638 lock_mode X locks rec but not gap     
Record lock, heap no 72       
Record lock, heap no 107       
Record lock, heap no 126       

它说事务 2 中index PRIMARY有一个独占锁 ( lock mode X)。持有三个这种类型的锁。

我过去回答过这样的问题，甚至是 4 天前

• 无法破译 innodb 状态日志中的死锁（2011 年 6 月 6 日）
• 这两个查询如果依次执行会不会导致死锁？（2011 年 6 月 8 日）
• 偶尔查询缓慢的原因是什么？（2011 年 6 月 14 日）
• InnoDB 死锁是 INSERT/UPDATE/DELETE 独有的吗？（2011 年 8 月 8 日）
• 限制mysql并发更新（2011年10月28日）

底线是：在事务中批量插入或执行多个单个 INSERT 时，聚集索引（内部称为gen_clust_index ）中包含的 PRIMARY KEY 可能会遇到间歇性锁定。应用程序应设计为在每次插入后执行手动提交。如果由于应用程序的性质不允许这样做，请重新设计应用程序以在填充投注表之前批量插入临时表。

作为旁注，这些东西不以串行方式运行的原因是由于默认的事务隔离以及您的应用程序在插入时的设计。

以下是四 (4) 种可能的模式：

• 未提交的读
• 已提交读
• 可重复读取（默认）
• 可串行化

我已经说过的事情可能还有更深层次的解释。如果有人有任何进一步的解释或我错过的信息，请插话。