摘要：
死锁：是指两个或则多个事务在同一个资源上相互占用，并请求锁定对方占用的资源，而导致恶性循环的现象；当产生死锁的时候，MySQL会回滚一个小事务的SQL，确保另一个完成。上面是死锁的概念，而在MySQL中innodb会出现死锁的情况，但是查看死锁却很不“智能”。只能通过 show engine innodb status 查看，但只保留最后一个死锁的信息，之前产生的死锁都被刷掉了。下面介绍的工具却很容易做到记录。
前提：
下载地址：wget www.percona.com/downloads/percona-toolkit/2.2.2/percona-toolkit-2.2.2.tar.gz
安装方法：perl Makefile.PL；make；make install
使用方法：
pt-deadlock-logger [OPTIONS] DSN
pt-deadlock-logger：显示指定的DSN的死锁日志信息，他能够标准输出到屏幕也可以把信息写日志文件中（--log参数）甚至可以保留到指定的表中（--dest参数），该工具默认是永久执行，除非指定--run-time 或 --iterations 。
用法：
pt-deadlock-logger --ask-pass --run-time=10 --interval=3 --create-dest-table --dest D=test,t=deadlocks u=root,P=3306,h=192.168.200.25
Enter MySQL password:
参数：
--create-dest-table ：创建指定的表。
--dest ：创建存储死锁信息的表。
--database ：-D，指定链接的数据库。
--table ：-t，指定存储的表名。
--log ：指定死锁日志信息写入到文件。
--run-time ：运行次数，默认永久
--interval ：运行间隔时间，默认30s。
u，p，h，P ：链接数据库的信息。
以上的参数，已经够用，更多的参数信息见官网说明。
测试：
运行pt-deadlock-logger，操作数据库：
session1:
root@localhost : test 04:46:11>select * from dead_tab;
+----+------+------+---------+
| id | name | age | address |
+----+------+------+---------+
| 1 | a | 33 | NULL |
| 2 | bbb | 34 | NULL |
| 3 | bbb | 35 | NULL |
+----+------+------+---------+
3 rows in set (0.00 sec) root@localhost : test 04:46:24>start transaction;
Query OK, 0 rows affected (0.00 sec) root@localhost : test 04:46:31>update dead_tab set name ='A' where id >2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
section2:
root@localhost : test 04:46:13>start transaction;
Query OK, 0 rows affected (0.01 sec) root@localhost : test 04:46:48>update dead_tab set name='AA' where id >1;
…………
…………
一直在等待着...
回到session1：
root@localhost : test 04:46:44>update dead_tab set name ='AA' where id >2;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction 死锁出现了！
看pt-deadlock-logger的运行情况：
zhoujy@zhoujy:~$ pt-deadlock-logger --ask-pass --create-dest-table --dest D=test,t=deadlocks u=root,P=3306,h=192.168.200.25
Enter MySQL password:
server ts thread txn_id txn_time user hostname ip db tbl idx lock_type lock_mode wait_hold victim query
192.168.200.25 2013-10-28T16:47:00 99 0 8 root localhost test dead_tab PRIMARY RECORD X w 0 update dead_tab set name='AA' where id >1
192.168.200.25 2013-10-28T16:47:00 100 0 16 root localhost test dead_tab PRIMARY RECORD X w 1 update dead_tab set name ='AA' where id >1
死锁被打印出来，看看是否写到表里：
root@localhost : test 04:32:45>select * from deadlocks\G;
*************************** 1. row ***************************
server: 192.168.200.25
ts: 2013-10-28 16:47:00
thread: 99
txn_id: 0
txn_time: 8
user: root
hostname: localhost
ip:
db: test
tbl: dead_tab
idx: PRIMARY
lock_type: RECORD
lock_mode: X
wait_hold: w
victim: 0
query: update dead_tab set name='AA' where id >1
*************************** 2. row ***************************
server: 192.168.200.25
ts: 2013-10-28 16:47:00
thread: 100
txn_id: 0
txn_time: 16
user: root
hostname: localhost
ip:
db: test
tbl: dead_tab
idx: PRIMARY
lock_type: RECORD
lock_mode: X
wait_hold: w
victim: 1
query: update dead_tab set name ='AA' where id >1
2 rows in set (0.00 sec)
结果表明死锁信息已经写入到了表中，记录的内容是2条产生的sql。继续同样的步骤再执行2次出现死锁的SQL来验证是之前的死锁信息否被刷写掉：
root@localhost : test 04:53:29>select count(*) from deadlocks;
+----------+
| count(*) |
+----------+
| 6 |
+----------+
1 row in set (0.02 sec)
继续被写入到表中。可以看到多个产生死锁的sql，而不仅仅是最后一条产生死锁的sql。
总结：
在检查数据库是死锁信息的时候，又多了一个选择。该工具也是通过show engine innodb status的信息来计算的。在mysql 5.6.2中，innodb_print_all_deadlocks这个设置可以看到死锁的情况。