死锁show engine innodb status\G; 后结果

Question

系统经常报死锁，
show engine innodb status\G;结果如下：
大家帮忙看什么原因。*** (1) TRANSACTION:
TRANSACTION 150723D9, ACTIVE 3 sec, process no 13185, OS thread id 1234966848 inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 3
MySQL thread id 12263, query id 3238989565 192.168.1.5 app update
insert into hrm_orderroomtypebean           (orderroomtypebeanid  , orderid    , keyidnodate   , keyidnodateratetype    , keyidnodatenoallotmenttype    , memberid   , membername   , customerid   , customername    , hotelid   , hotelname   , roomtypeid   , roomtypename   , roomtypenameratetype   , pricingtype   , allotmenttype   , supplierid   , suppliername   , ratetype   , includebreakfastqty2        , checkindate   , checkoutdate    , roomqty   , days                                           , currency   , rate            , latestarrivaltime   , checkinpersons              , orderroomtypebeanidorg   , orderroomtypebeanidedit   , modifytype         , active  )            values (NULL  ,835445  ,'411141211154'  ,'41114121154'  ,'4111412154'  ,39073  ,'刘丽 01058602288'  ,15639  ,'阳光旅行网'  ,41  ,'香港如心铜锣湾海景酒店'  ,114  ,'标准房'  ,'标准房'  ,12  ,11  ,54  ,'香港如心铜锣湾海景酒店'  ,1  ,13  ,'2013-01-14 00
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 4577347 n bits 992 index `fk_reference_85` of table `jltour`.`hrm_orderroomtypebean` trx id 150723D9 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;*** (2) TRANSACTION:
TRANSACTION 1507236E, ACTIVE 7 sec, process no 13185, OS thread id 1235233088 starting index read
mysql tables in use 1, locked 1
427 lock struct(s), heap size 47544, 992 row lock(s), undo log entries 68
MySQL thread id 12222, query id 3238990436 192.168.2.234 app Updating
UPDATE sequence_copy 
SET current_value = current_value + 1 
WHERE NAME =  NAME_CONST('today2',_utf8'130111ordercd' COLLATE 'utf8_general_ci')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 4577347 n bits 992 index `fk_reference_85` of table `jltour`.`hrm_orderroomtypebean` trx id 1507236E lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;Record lock, heap no 921 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 800cbf74; asc    t;;
 1: len 4; hex 800dd994; asc     ;;*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 2342920 n bits 400 index `sequence.name` of table `jltour`.`sequence_copy` trx id 1507236E lock_mode X locks rec but not gap waiting
Record lock, heap no 329 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 13; hex 3133303131316f726465726364; asc 130111ordercd;;
 1: len 6; hex 0000150723d9; asc     # ;;
 2: len 7; hex 71004480260902; asc q D &  ;;
 3: len 4; hex 8000063e; asc    >;;
 4: len 4; hex 80000001; asc     ;;*** WE ROLL BACK TRANSACTION (1)

Answer 1

第二个表的name字段有索引吗 没有索引的话是锁定整张表的

Answer 2

http://bbs.csdn.net/topics/390344074这个是程序报的错，死锁

Answer 3

合理的解释是inset锁定的索引块和update锁定的索引块相互成环  造成死锁这需要程序判断每次执行sql语句是否成功  没有成功则重新执行

Answer 4

1：楼主的2个SQL语句，都是封装在事务里的吧？两个事务启动后，相互等待另外一个事务的锁，才会出现死锁。建议楼主在代码里找找这2个SQL的处理方式，看从业务上能不能让他们依次执行2：UPDATE sequence_copy 
 SET current_value = current_value + 1 
 WHERE NAME =  NAME_CONST('today2',_utf8'130111ordercd' COLLATE 'utf8_general_ci')
这个SQL如果在Name字段上没有索引，会引起全表扫描。
show create table sequence_copy ;看看

Answer 5

问题找到了，出在程序上，数据库没问题。
原先的担心：不同渠道下单，是否会互相影响的问题，经断点调试，不会出生，会取下一个PK ID，如果上一个未提交的PK最后抛异常，则该PK被放弃。不影响下一个。