Chinaunix首页 | 论坛 | 博客
  • 博客访问: 643317
  • 博文数量: 66
  • 博客积分: 15
  • 博客等级: 民兵
  • 技术积分: 2204
  • 用 户 组: 普通用户
  • 注册时间: 2010-10-26 21:43
个人简介

曾就职于阿里巴巴担任Oracle DBA,MySQL DBA,目前在新美大担任SRE。[是普罗米修斯还是一块石头,你自己选择!] 欢迎关注微信公众号 “自己的设计师”,不定期有原创运维文章推送。

文章分类

全部博文(66)

文章存档

2017年(2)

2016年(3)

2015年(7)

2014年(12)

2013年(42)

分类: Mysql/postgreSQL

2013-12-17 11:03:55

  昨晚报警捕获的信息如下: 
   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.


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

阅读(3332) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~