锁是锁的索引块  并不是锁数据行如果一个update锁定第1,2,3索引块   第二个update也需要锁定第1,2,3索引块则第二个如果锁的顺序是3,2,1   则可能和第一个update产生死锁

解决方案 »

  1.   

    那我如何判断具体的索引块?
    是where条件下的字段吗?
      

  2.   

    刚才又出现了,查询到一直在更新中的语句是:
    update body_1 set status=2
    where order_id=12346546
    这条语句调用的地方,只有唯一一个不带事务的方法,order_id是另外一个表的主键,但是没有做实际的外键关联.事务中的方法的执行顺序是
    update order_1 set status_x=1,status_y=2 
    where order_id = 12346546
    update body_1 set status=3
    where order_id=12346546
    update xxx set xxx1=1111
    update yyy set xxx2=1111
    update zzz set xxx3=1111
    大概就是这样的结构,触发顺序是:事务先执行,然后锁表的那个update也顺利瞬间完成了执行,然后到了第二条订单,事务执行顺利完成,然后到锁表的update就锁住了,就是这样的
    求高手分析!
      

  3.   

    show process 看一下是和哪个进程产生冲突。
      

  4.   

    是show processlist? 这个在本地不好重现的,在服务器上才有,我几次在服务器上都是一个update,在那里卡着,没有其他语句,这个怎么看呢?
      

  5.   

    show innodb status可以看上一次死锁的原因
      

  6.   


    show innodb status;[SQL] show innodb status;
    [Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'innodb status' at line 1
      

  7.   

    mysql5.5之后 show engine innodb status\G
      

  8.   


    show engine innodb status\G
    [SQL] show engine innodb status\G[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\G' at line 1show engine innodb status
    [SQL] show engine innodb statusAffected rows: 0
    Time: 1.110mstype   name  status
    InnoDB       
      

  9.   

    不好意思,带大家走进了误区,刚看了,其实不是死锁了,那句update是updating状态的,刚查到是:正在搜索匹配的记录,并且修改它们. 这个意思,但是这个过程很长,一直持续到这条语句失败.长达十多秒
      

  10.   

    你的语句是什么? 表的create table 语句是什么? show index from xxx 也一同贴出以供分析。
      

  11.   

    查看最后一次死锁的命令行:
    show engine innodb status;