Mysql诊断案例一则

  昨晚报警捕获的信息如下： 
   Mysql show processlist
  
 可以看到存在阻塞的情况，同时我们来看看IO情况

写的会比较多，由此可以知道该db的write比较多，出现lock contention可能是锁粒度比较粗，猜测可能使用了MyISAM表。验证猜测如下:
mysql> show create table account\G;
*************************** 1. row ***************************
       Table: account
Create Table: CREATE TABLE `account` (
  `id` int(11) unsigned NOT NULL,
  `account` char(32) NOT NULL,
   此处略去N多行
  `  PRIMARY KEY  (`account`),
  UNIQUE KEY `index_id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
MyISAM表和INNODB表最大的区别在于锁的粒度不一样，INNODB是row level lock，而MyISAM是table level lock.所以也决定了MyISAM只适用于并发读或者串行的写的操作。
从瞬间捕获到的信息来看，应用实际上是存在并发写的。所以在这个过程中难免造成锁资源竞争比较激烈，也就是常说的lock contention。对于dml比较多的数据而言采用
Innodb是一个比较好的选择。以下是high performance mysql 对locked的状态的理解：
Locked
The thread is waiting for a table lock to be granted at the server level. Locks that are implemented by the storage engine, such as InnoDB’s row locks, do not cause the thread to
enter the Locked state. This thread state is the classic symptom of MyISAM locking, but it can occur in other storage engines that don’t have rowlevel locking, too.


当然这个表设计当中还是存在其他缺陷的，你看出来了吗？