如何分析分析当前的死锁

liyihongcug

如何分析分析当前的死锁》

（我用 show innodb status得到以下信息）
------------------------
LATEST DETECTED DEADLOCK
------------------------
100518 7:45:19
*** (1) TRANSACTION:
TRANSACTION 0 2834447885, ACTIVE 0 sec, process no 27899, OS thread id 1080899904 inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 368
MySQL thread id 351632, query id 13435675066 online2b 192.168.10.10 betbrain update
INSERT INTO Out_table
values
(6627877045,13287509,186575405,45,2,0,1115,1117,null,0.0,7.0,'C','N','Y'),
(6627878008,13287509,186575405,8,2,1,1117,null,null,1.0,null,'C','N','Y'),
(6627879045,13287509,186575405,45,2,0,1115,1117,null,3.0,1.0,'C','N','Y'),(6627880045,13287509,186575405,45,2,0,1115,1117,null,2.0,0.0,'C','N','Y'),(6627881045,13287509,186575405,45,2,0,1115,1117,null,3.0,2.0,'C','N','Y'),(6627882045,13287509,186575405,45,2,0,1115,1117,null,2.0,5.0,'C','N','Y'),(6627883009,13287509,186575405,9,2,0,1115,null,null,null,null,'C','N','Y'),(6627884045,13287509,186575405,45,2,0,1115,1117,null,3.0,0.0,'C','N','Y'),(6627885045,13287509,186575405,45,2,0,1115,1117,null,6.0,0.0,'C','N','Y'),(6627886045,13287509,186575405,45,2,0,1115,1117,null,8.0,1.0,'C','N','Y'),(6627887045,13287509,186575405,45,2,0,1115,1117,null,0.0,6.0,'C','N','Y'),(6627888045,13287509,186575405,45,2,0,1115,1117,null,7.0,0.0,'C','N','Y'),
(6627893045,13287509,186575405,45,2,0,1115,1117,null,2.0,8.0,'C','N','Y')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 781492 n bits 120 index `PRIMARY` of table `db/Out_table` trx id 0 2834447885 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 0 2834447884, ACTIVE 0 sec, process no 27899, OS thread id 1186797888 inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
3 lock struct(s), heap size 368
MySQL thread id 351758, query id 13435675088 online2a 192.168.10.20 betbrain update
INSERT INTO Out_table
values
(6627827045,13287508,186575405,45,2,0,1115,1117,null,8.0,2.0,'C','N','Y'),
(6627828045,13287508,186575405,45,2,0,1115,1117,null,0.0,3.0,'C','N','Y'),
(6627829045,13287508,186575405,45,2,0,1115,1117,null,6.0,1.0,'C','N','Y'),
(6627830045,13287508,186575405,45,2,0,1115,1117,null,8.0,0.0,'C','N','Y'),
(6627831045,13287508,186575405,45,2,0,1115,1117,null,0.0,8.0,'C','N','Y'),
(6627832045,13287508,186575405,45,2,0,1115,1117,null,3.0,4.0,'C','N','Y'),
(6627833045,13287508,186575405,45,2,0,1115,1117,null,3.0,3.0,'C','N','Y'),
(6627834045,13287508,186575405,45,2,0,1115,1117,null,5.0,1.0,'C','N','Y'),
(6627835045,13287508,186575405,45,2,0,1115,1117,null,5.0,0.0,'C','N','Y'),
(6627836045,13287508,186575405,45,2,0,1115,1117,null,1.0,1.0,'C','N','Y'),
(6627837009,13287508,186575405,9,2,0,null,null,null,null,null,'C','N','Y'),(6627838045,13287508,186575405,45,2,0,1115,1117,null,7.0,1.0,'C','N','Y'),(6627839045,13287508,186575405,45,2,0,1115,1117,null,4.0,2.0,'C','N','Y'),(6627840045,13287508,186575405,45,2,0,1115,1117,null,2.0,6.0,'C','N','Y'),(6627841045,13287508,186575405,45,2,0,1115,1117,null,2.0,7.0,'C','N','Y'),(6627842045,13287508,186575405,45,2,0,1115,1117,null,2.0,1.0,'C','N','Y'),(6627843045,13287508,186575405,45,2,0,1115,1117,null,9.0,0.0,'C','N','Y'),(6627844045,13287508,186575405,45,2,0,1115,1117,null,5.0,3.0,'C','N','Y'),(6627845045,13287508,186575405,45,2,0,1115,1117,null,1.0,8.0,'C','N','Y'),(6627846045,13287508,186575405,45,2,0,1115,1117,null,0.0,4.0,'C','N','Y'),(6627847047,13287508,186575405,47,2,3,null,null,null,3.5,null,'C','N','Y'),(6627848045,13287508,186575405,45,2,0,1115,1117,null,0.0,1.0,'C','N','Y'),(6627849045,13287508,186575405,45,2,0,1115,1117,null,4.0,1.0,'C','N','Y'),(6627850045,13287508,186575405,45,2,0,1115,1117,null,2.0,3.0,'C','N','Y'),(6627851045,13287508,186575405,45,2,0,1115,1117,null,1.0,5.0,'C','N','Y'),(6627852045,13287508,186575405,45,2,0,1115,1117,null,2.0,2.0,'C','N','Y'),(6627853045,13287508,186575405,45,2,0,1115,1117,null,0.0,0.0,'C','N','Y'),(6627854045,13287508,186575405,45,2,0,1115,1117,null,4.0,4.0,'C','N','Y'),(6627855045,13287508,186575405,45,2,0,1115,1117,null,1.0,0.0,'C','N','Y'),(6627856045,13287508,186575405,45,2,0,1115,1117,null,4.0,0.0,'C','N','Y'),(6627857047,13287508,186575405,47,2,4,null,null,null,3.5,null,'C','N','Y'),(6627858045,13287508,186575405,45,2,0,1115,1117,null,1.0,3.0,'C','N','Y'),(6627859045,13287508,186575405,45,2,0,1115,1117,null,1.0,7.0,'C','N','Y'),(6627860045,13287508,186575405,45,2,0,1115,1117,null,2.0,4.0,'C','N','Y'),(6627861045,13287508,186575405,45,2,0,1115,1117,null,9.0,1.0,'C','N','Y'),(6627862009,13287508,186575405,9,2,0,1117,null,null,null,null,'C','N','Y'),(6627863045,13287508,186575405,45,2,0,1115,1117,null,0.0,2.0,'C','N','Y'),
(6627864069,13287508,186575405,43,2,1,1115
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 781492 n bits 120 index `PRIMARY` of table `db/Out_table` trx id 0 2834447884 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 781492 n bits 120 index `PRIMARY` of table `db/Out_table` trx id 0 2834447884 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;;

liyihongcug

index `PRIMARY` of table `db/Out_table
提示是这个 主键的问题

可以把他修改为 normal index 就可以解决问题

liyihongcug

Out_table 的 PRIMARY为 （id+ messid） id 和messid 2个字段组成联合主键

现在质疑为什么不把他改为唯一索引 。为什么设置这2个字段为主键 而不是建立唯一索引 ？？？？

liyihongcug

引是一种特殊的文件（InnoDB数据表上的索引是表空间的一个组成部分），它们包含着对数据表里所有记录的引用指针。索引不是万能的，索引可以加快数据检索操作，但会使数据修改操作变慢。每修改数据记录，索引就必须刷新一次。为了在某种程序上弥补这一缺陷，许多SQL命令都有一个 DELAY_KEY_WRITE项。这个选项的作用是暂时制止MySQL在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行。在需要把许多新记录插入某个数据表的场合，DELAY_KEY_WRITE选项的作用将非常明显。另外，索引还会在硬盘上占用相当大的空间。因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
　　从理论上讲，完全可以为数据表里的每个字段分别建一个索引，但MySQL把同一个数据表里的索引总数限制为16个。
　　1、InnoDB数据表的索引
　　与InnoDB数据表相比，在InnoDB数据表上，索引对InnoDB数据表的重要性要在得多。在InnoDB数据表上，索引不仅会在搜索数据记录时发挥作用，还是数据行级锁定机制的苊、基础。“数据行级锁定”的意思是指在事务操作的执行过程中锁定正在被处理的个别记录，不让其他用户进行访问。这种锁定将影响到（但不限于）SELECT、LOCKINSHAREMODE、SELECT、 FORUPDATE命令以及INSERT、UPDATE和DELETE命令。出于效率方面的考虑，InnoDB数据表的数据行级锁定实际发生在它们的索引上，而不是数据表自身上。显然，数据行级锁定机制只有在有关的数据表有一个合适的索引可供锁定的时候才能发挥效力。
　　2、限制
　　如果WEHERE子句的查询条件里有不等号（WHEREcoloum!=），MySQL将无法使用索引。类似地，如果WHERE子句的查询条件里使用了函数（WHEREDAY（column）=），MySQL也将无法使用索引。在JOIN操作中（需要从多个数据表提取数据时），MySQL只有在主键和外键的数据类型相同时才能使用索引。
　　如果WHERE子句的查询条件里使用比较操作符LIKE和REGEXP，MySQL只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。比如说，如果查询条件是LIKE'abc%‘，MySQL将使用索引；如果查询条件是 LIKE'%abc’，MySQL将不使用索引。
　　在ORDERBY操作中，MySQL只有在排序条件不是一个查询条件表达式的情况下才使用索引。（虽然如此，在涉及多个数据表查询里，即使有索引可用，那些索引在加快ORDERBY方面也没什么作用）。如果某个数据列里包含许多重复的值，就算为它建立了索引也不会有很好的效果。比如说，如果某个数据列里包含的净是些诸如“0/1”或“Y/N”等值，就没有必要为它创建一个索引。
　　MySQL 普通索引、唯一索引和主索引
　　1、普通索引
　　普通索引（由关键字KEY或INDEX定义的索引）的唯一任务是加快对数据的访问速度。因此，应该只为那些最经常出现在查询条件（WHEREcolumn=）或排序条件（ORDERBYcolumn）中的数据列创建索引。只要有可能，就应该选择一个数据最整齐、最紧凑的数据列（如一个整数类型的数据列）来创建索引。
　　2、唯一索引
　　普通索引允许被索引的数据列包含重复的值。比如说，因为人有可能同名，所以同一个姓名在同一个“员工个人资料”数据表里可能出现两次或更多次。
　　如果能确定某个数据列将只包含彼此各不相同的值，在为这个数据列创建索引的时候就应该用关键字 UNIQUE把它定义为一个唯一索引。这么做的好处：一是简化了MySQL对这个索引的管理工作，这个索引也因此而变得更有效率；二是MySQL会在有新记录插入数据表时，自动检查新记录的这个字段的值是否已经在某个记录的这个字段里出现过了；如果是，MySQL将拒绝插入那条新记录。也就是说，唯一索引可以保证数据记录的唯一性。事实上，在许多场合，人们创建唯一索引的目的往往不是为了提高访问速度，而只是为了避免数据出现重复。
　　3、主索引
　　在前面已经反复多次强调过：必须为主键字段创建一个索引，这个索引就是所谓的“主索引”。主索引与唯一索引的唯一区别是：前者在定义时使用的关键字是PRIMARY而不是UNIQUE。
　　4、外键索引
　　如果为某个外键字段定义了一个外键约束条件，MySQL就会定义一个内部索引来帮助自己以最有效率的方式去管理和使用外键约束条件。
　　5、复合索引
　　索引可以覆盖多个数据列，如像INDEX（columnA，columnB）索引。这种索引的特点是MySQL可以有选择地使用一个这样的索引。如果查询操作只需要用到columnA数据列上的一个索引，就可以使用复合索引 INDEX（columnA,columnB）。不过，这种用法仅适用于在复合索引中排列在前的数据列组合。比如说，INDEX（A，B，C）可以当做A 或（A,B）的索引来使用，但不能当做B、C或（B，C）的索引来使用。
　　6、索引的长度
　　在为CHAR和VARCHAR类型的数据列定义索引时，可以把索引的长度限制为一个给定的字符个数（这个数字必须小于这个字段所允许的最大字符个数）。这么做的好处是可以生成一个尺寸比较小、检索速度却比较快的索引文件。在绝大多数应用里，数据库中的字符串数据大都以各种各样的名字为主，把索引的长度设置为10~15个字符已经足以把搜索范围缩小到很少的几条数据记录了。在为BLOB和TEXT类型的数据列创建索引时，必须对索引的长度做出限制；MySQL所允许的最大索引全文索引文本字段上的普通索引只能加快对出现在字段内容最前面的字符串（也就是字段内容开头的字符）进行检索操作。如果字段里存放的是由几个、甚至是多个单词构成的较大段文字，普通索引就没什么作用了。这种检索往往以的形式出现，这对MySQL来说很复杂，如果需要处理的数据量很大，响应时间就会很长。
　　这类场合正是全文索引（full-textindex）可以大显身手的地方。在生成这种类型的索引时，MySQL将把在文本中出现的所有单词创建为一份清单，查询操作将根据这份清单去检索有关的数据记录。全文索引即可以随数据表一同创建，也可以等日后有必要时再使用下面这条命令添加：
　　ALTERTABLEtablenameADDFULLTEXT（column1，column2）有了全文索引，就可以用SELECT查询命令去检索那些包含着一个或多个给定单词的数据记录了。下面是这类查询命令的基本语法：
　　SELECT*FROMtablename
　　WHEREMATCH（column1,column2）AGAINST（‘word1','word2','word3’）
　　上面这条命令将把column1和column2字段里有word1、word2和word3的数据记录全部查询出来。
　　注解：InnoDB数据表不支持全文索引。
[编辑本段]
MySQL文件优化
　　[2]查询和索引的优化
　　只有当数据库里已经有了足够多的测试数据时，它的性能测试结果才有实际参考价值。如果在测试数据库里只有几百条数据记录，它们往往在执行完第一条查询命令之后就被全部加载到内存里，这将使后续的查询命令都执行得非常快--不管有没有使用索引。只有当数据库里的记录超过了1000条、数据总量也超过了MySQL服务器上的内存总量时，数据库的性能测试结果才有意义。
　　在不确定应该在哪些数据列上创建索引的时候，人们从EXPLAINSELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键字，MySQL将不是去执行那条 SELECT命令，而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引等信息列出来。
　　在EXPLAIN命令的输出结果里，第1列是从数据库读取的数据表的名字，它们按被读取的先后顺序排列。type列指定了本数据表与其它数据表之间的关联关系（JOIN）。在各种类型的关联关系当中，效率最高的是system，然后依次是 const、eq_ref、ref、range、index和All（All的意思是：对应于上一级数据表里的每一条记录，这个数据表里的所有记录都必须被读取一遍——这种情况往往可以用一索引来避免）。
　　possible_keys数据列给出了MySQL在搜索数据记录时可选用的各个索引。 key数据列是MySQL实际选用的索引，这个索引按字节计算的长度在key_len数据列里给出。比如说，对于一个INTEGER数据列的索引，这个字节长度将是4。如果用到了复合索引，在key_len数据列里还可以看到MySQL具体使用了它的哪些部分。作为一般规律，key_len数据列里的值越小越好。
　　ref数据列给出了关联关系中另一个数据表里的数据列的名字。row数据列是MySQL在执行这个查询时预计会从这个数据表里读出的数据行的个数。row数据列里的所有数字的乘积可以大致了解这个查询需要处理多少组合。
　　最后，extra数据列提供了与JOIN操作有关的更多信息，比如说，如果MySQL在执行这个查询时必须创建一个临时数据表，就会在extra列看到usingtemporary字样。

0vk0

引是一种特殊的文件（InnoDB数据表上的索引是表空间的一个组成部分），它们包含着对数据表里所有记录的引用指针。索引不是万能的，索引可以加快数据检索操作，但会使数据修改操作变慢。每修改数据记录，索引就必须刷新一次。为了在某种程序上弥补这一缺陷，许多SQL命令都有一个 DELAY_KEY_WRITE项。这个选项的作用是暂时制止MySQL在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行。在需要把许多新记录插入某个数据表的场合，DELAY_KEY_WRITE选项的作用将非常明显。另外，索引还会在硬盘上占用相当大的空间。因此

这和索引有关？

liyihongcug

已经找到原因
将pk（id+ messid） 去掉 换成普通索引

yejr

下次类似问题，请同时贴上完整的 DDL，便于大家分析

chinafenghao

这个死锁，应该是mysql处理可重复读的隔离级别下，两条线程同时获取同一个不存在的ID的X锁，然后插入导致的，修改pk为index当然可以解决，最好还是用其他方法。这个解决方法不上上上之策。