myisam MySQL 锁问题
(点击上方公众号,可快速关注)
来源:阿里云 RDS - 数据库内核组
前言
最近一段时间处理了较多锁的问题,包括锁等待导致业务连接堆积或超时,死锁导致业务失败等,这类问题对业务可能会造成严重的影响,没有处理经验的用户往往无从下手。下面将从整个数据库设计,开发,运维阶段介绍如何避免锁问题的发生,提供一些最佳实践供RDS的用户参考。
设计阶段
在数据库设计阶段,引擎选择和索引设计不当可能导致后期业务上线后出现较为严重的锁或者死锁问题。
1. 表引擎选择使用myisam,引发table level lock wait。
从5.5版本开始,MySQL官方就把默认引擎由myisam转为innodb,这两种引擎的主要区别:
由于myisam引擎只支持table lock,在使用myisam引擎表过程中,当数据库中出现执行时间较长的查询后就会堵塞该表上的更新动作,所以经常会碰到线程会话处于表级锁等待(Waiting for table level lock)的情况,严重的情况下会出现由于实例连接数被占满而应用无法正常连接的情况
CREATE TABLE `t_myisam` (
`id` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Query |111 | User sleep | select id,sleep(100) from t_myisam |
Query |108 | Waiting for table level lock | update t_myisam set id=2 where id=1|
Query | 3 | Waiting for table level lock | update t_myisam set id=2 where id=1|
从上述的案例中可以看到,t_myisam表为myisam存储引擎,当该表上有执行时间较长的查询语句在执行的时候,该表上其他的更新全被堵塞住了,这个时候应用或者数据库的连接很快耗完,导致应用请求失败。这个时候快速的恢复方法为将线程id:111 kill掉即可(可以执行show processlist查看到当前数据库所有连接状态)。另外myisam存储引擎的表索引在实例异常关闭的情况下会导致索引损坏,这个时候必须要对表进行repair操作,该操作同样会阻塞该表上的所有请求。
2. 表索引设计不当,导致数据库出现死锁。
索引设计是数据库设计非常重要的一环,不仅仅关系到后续业务的性能,如果设计不当还可导致业务上的死锁。下面的一则案例就出现在线上系统,数据库在并发更新的时候出现了死锁,通过排查定位于update更新使用了两个索引导致,死锁信息如下:
*** (1) TRANSACTION:
TRANSACTION 29285454235, ACTIVE 0.001 sec fetching rows
mysql tables in use 3, locked 3
LOCK WAIT 6 lock struct(s), heap size 1184, 4 row lock(s)
MySQL thread id 6641616, OS thread handle 0x2b165c4b1700, query id 28190427937 10.103.180.86 test_ebs Searching rows for update
UPDATE test SET is_deleted = 1 WHERE group_id = 1332577 and test_id = 4580605
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 132 page no 37122 n bits 352 index `PRIMARY` of table `testdriver`.`test` trx id 29285454235 lock_mode X locks rec but not gap waiting
Record lock, heap no 179 PHYSICAL RECORD: n_fields 8; compact format; info bits 0
*** (2) TRANSACTION:
TRANSACTION 29285454237, ACTIVE 0.001 sec fetching rows, thread declared inside InnoDB 4980
mysql tables in use 3, locked 3 5 lock struct(s), heap size 1184, 3 row lock(s)
MySQL thread id 6639213, OS thread handle 0x2b1694cc2700, query id 28190427939 10.103.180.113 test_ebs Searching rows for update
UPDATE test SET is_deleted = 1 WHERE group_id = 1332577 and test_id = 4212859
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 132 page no 37122 n bits 352 index `PRIMARY` of table `testdriver`.`test` trx id 29285454237 lock_mode X locks rec but not gap
Record lock, heap no 179 PHYSICAL RECORD: n_fields 8; compact format;
表结构:
CREATE TABLE `test` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
`test_id` bigint(20) DEFAULT NULL,
`group_id` bigint(20) DEFAULT NULL COMMENT ‘Id,对应test_group.id’,
`gmt_created` datetime DEFAULT NULL COMMENT ‘创建时间’,
`gmt_modified` datetime DEFAULT NULL COMMENT ‘修改时间’,
`is_deleted` tinyint(4) DEFAULT ‘0’ COMMENT ‘删除。’,
PRIMARY KEY (`id`),
KEY `idx_testid` (`test_id`),
KEY `idx_groupid` (`group_id`)
) ENGINE=InnoDB AUTO_INCREMENT=7429111 ;
SQL执行计划:
mysql>explain UPDATE test SET is_deleted = 1 WHERE group_id = 1332577 and test_id = 4212859
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
| 1 | SIMPLE | test | index_merge | idx_testid,idx_groupid | idx_testid,idx_groupid | 9,9 | | 1 | Using intersect(idx_testid,idx_groupid); Using where; Using temporary |
所以第一个事务先根据group_id索引,已经锁住primary id,然后再根据test_id索引,锁定primary id;第二个事务先根据test_id索引,已经锁住primary id,然后再根据group_id索引,去锁primary id;所以这样并发更新就可能出现死索引。
MySQL官方也已经确认了此bug:77209,解决方法有两种:
加test_id + group_id的组合索引,这样就可以避免掉index merge;
将优化器的index merge优化关闭。
开发阶段
事务处理时间过长,导致并发出现锁等待。
并发事务处理在数据库中经常看到的应用场景,在这种场景下,需要避免大事务,长事务,复杂事务导致事务在数据库中的运行时间加长,事务时间变长则导致事务中锁的持有时间变长,影响整体的数据库吞吐量。下面的一则案例中,用户的业务数据库中出现大量的update等待,导致大量的业务超时报错:
问题排查:
1. 通过show processlist确定出现锁等待的线程以及SQL信息:
|Query|37|updating|UPDATE test_warning SET ... WHERE test_id = '46a9b'
2. 通过innodb的information_schema数据库中的锁等待以及事务试图,查出相关的锁信息:
select r.trx_mysql_thread_id waiting_thread, r.trx_id waiting_trx_id,r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_query blocking_query,b.trx_mysql_thread_id blocking_thread,b.trx_ started,b.trx_wait_started from information_schema.innodb_lock_waits w inner join information_schema.innodb_trx b on b.trx_id =w.blocking_trx_id inner join
information_schema.innodb_trx r on r.trx_id=w.requesting_trx_id G
waiting_thread: 318984063
waiting_trx_id: 26432631
waiting_query: UPDATE test_warning SET ........ WHERE test_id = '46a9b'
blocking_trx_id: 26432630
blocking_query: NULL
blocking_thread: 235202017
trx_started: 2016-03-01 13:54:39
从述的锁等待信息中发现,事务26432631被26432630阻塞了,那么我们就可以从general log中去排查一下事务26432630做了哪些操作。
3. 从提前打开数据库的general log中查找到上述被blcok 的update语句在日志中的位置,发现了update被blcok的根本原因: 日志中有两条不同的SQL同时并发更新同一条记录,所以后更新的SQL会等待前更新的SQL,如果SQL1所在的事务1直没有提交,那么事务2将会一直等待,这样就出现上述updating的状态
235202017 Query UPDATE test_warning ..... WHERE test_id = '46a9b'
318984063 Query UPDATE test_warning ..... task_order_id = '' WHERE test_id = '46a9b'
所以我们就可以在看一下这个事务的上下文:
thread id=235202017 的SQL上下文:
235202017 Query SET autocommit=0
235202017 (13:54:39) Query UPDATE test_warning SET .... WHERE test_id = '46a9b'
235202017 Query commit
thread id=318984063 的SQL上下文:
318984063 Query SET autocommit=1
318984063 (13:54:39)Query SELECT .... FROM test_waybill WHERE (test_id IN ('46a9b'))
318984063 Query SELECT......FROM test_waybill WHERE test_id = '46a9b'
318984063 Query UPDATE test_warning SET ..... WHERE test_id = '46a9b'
318984063 (13:55:31)Query UPDATE test_waybill_current t ..... WHERE t.test_id IN ('46a9b')
318984063 Query SET autocommit=0
可以看到事务1 从13:54:39开始,直到13:55:30结束,事务2 中有更新事务1中的同一条记录,所以直到事务1 提交后,事务2才得以执行完毕,有了这样的日志,将此信息发给用户很快就找到了问题,在事务1中由于还存在其他的业务逻辑,导致事务1的提交迟迟没有完成,进而导致了其他业务锁的发生。
维护阶段
DDL操作被大查询block。
当应用上线进入维护阶段,则开始会有较多的数据库变更操作,比如:添加字段,添加索引等操作,这一类操作导致的锁故障也是非常频繁的,下面将会介绍一则案例,一个DDL操作被查询block,导致数据库连接堆积:
Query |6 | User sleep | select id ,sleep(50) from t
Query |4 | Waiting for table metadata lock | alter table t add column gmt_create datetime
Query |2 | Waiting for table metadata lock | select * from t where id=1
Query |1 | Waiting for table metadata lock | select * from t where id=2
Query |1 | Waiting for table metadata lock | update t set id =2 where id=1
Metadata lock wait 的含义:为了在并发环境下维护表元数据的数据一致性,在表上有活动事务(显式或隐式)的时候,不可以对元数据进行写入操作。因此 MySQL 引入了 metadata lock ,来保护表的元数据信息。因此在对表进行上述操作时,如果表上有活动事务(未提交或回滚),请求写入的会话会等待在 Metadata lock wait。
导致 Metadata lock wait 等待的常见因素包括:活动事务,当前有对表的长时间查询,显示或者隐式开启事务后未提交或回滚,比如查询完成后未提交或者回滚,表上有失败的查询事务等。
上述案例中,查询,更新和DDL操作的线程状态都为Waiting for table metadata lock,对表t的操作全部被阻塞,前端源源不断的请求到达数据库,这个时候数据库的连接很容易被打满,那我们来分析一下为什么有这这些锁等待:
alter 操作的锁等待:由于在表t上做了一个添加字段的操作,该操作会在结束前对表获取一个metadata lock,但是该表上已经有一个查询一直未结束,导致metadata lock一直获取不到,所以添加字段操作只能等待查询结束,这就解释了alter操作为什么状态为Waiting for table metadata lock。
查询和更新的锁等待:由于前面进行的alter操作已经在T表上试图获取metadata lock,所以后续对表T的的查询和更新操作在获取metadata lock的时候会被alter操作所阻塞,进而导致这些线程状态为Waiting for table metadata lock。
解决办法则是将线程6 kill 掉即可。
总结
锁问题是非常常见的问题,需要我们在数据库开发、设计、管理的各个阶段都需要注意,防范未然,做到心中有数。
设计开发阶段:
表设计要避免使用myisam存储引擎,改用innodb引擎;
为SQL创建合适的索引,避免多个单列索引执行出错;
避免大事务,长事务,复杂事务导致事务在数据库中的运行时间加长。
管理运维阶段:
在业务低峰期执行上述操作,比如创建删除索引;
在结构变更前,观察数据库中是否存在长时间运行的SQL,未提交的事务;
结构变更期间,监控数据库的线程状态是否存在lock wait。
myisam MySQL 锁问题的更多相关文章
- 锁(MySQL篇)—之MyISAM表锁
前言 锁是计算机协调多个进程或线程并发访问某一资源的机制,在数据库中,除传统的计算资源(如CPU.RAM.I/O等)的争用以外,数据也是一种供许多用户共享的资源.如何保证数据并发访问的一致性.有效性是 ...
- MySQL- 锁机制及MyISAM表锁
锁是计算机协调多个进程或线程并发访问某一资源的机制.在数据库中,除传统的计算资源(如CPU.RAM.I/O等)的争用以外,数据也是一种供许 多用户 共享的资源.如何保证数据并发访问的一致性.有效性是所 ...
- (1.14)mysql锁问题之MyIsam
1.mysql锁概述 BDB被InnoDB代替了,MyIsam在8.0也被抛弃了 2.MyIsam表锁(读写是串行的) [2.1]查看表锁争用情况. MyIsam存储引擎只支持表锁. 查看表锁争用情况 ...
- (6)MySQL进阶篇SQL优化(MyISAM表锁)
1.MySQL锁概述 锁是计算机协调多个进程或线程并发访问某一资源的机制.在数据库中,除传统的计算资源 (如 CPU.RAM.I/O 等)的抢占以外,数据也是一种供许多用户共享的资源.如何保证数 据并 ...
- MySQL优化篇系列文章(二)——MyISAM表锁与InnoDB锁问题
我可以和面试官多聊几句吗?只是想... MySQL优化篇系列文章(基于MySQL8.0测试验证),上部分:优化SQL语句.数据库对象,MyISAM表锁和InnoDB锁问题. 面试官:咦,小伙子,又来啦 ...
- MySQL 锁问题
一.MySQL中不同的存储引擎支持不同的锁机制 (A) MyISAM 和 MEMORY 支持表级锁 (B) BDB 支持页面锁,也支持表级锁 (C) InnoDB 支持行级锁,也支持表级锁,默认是行级 ...
- MySQL锁问题
MySQL的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制.比如,MyISAM和MEMORY存储引擎 采用的是表级锁:BDB存储引擎采用的是页面锁,但也支持表级锁:InnoDB存储引擎 ...
- mysql锁
锁是计算机协调多个进程或线程并发访问某一资源的机制.在数据库中,除传统的计算资源(如CPU.RAM.I/O等)的争用以外,数据也是一种供许多用户共享的资源.如何保证数据并发访问的一致性.有效性是所有数 ...
- Mysql锁初步
存储引擎 要了解mysql的锁,就要先从存储引擎说起. 常用存储引擎列表如下图所示: 最常使用的两种存储引擎: Myisam是Mysql的默认存储引擎.当create创建新表时,未指定新表的存储引擎时 ...
随机推荐
- 为什么喜欢Kindle
为什么喜欢Kindle 有朋友问为什么那么多人喜欢用Kindle,作为刚入手一台Kindle PaperWhite 2 的人, 我想说:这个东西,应该算今年我买的最值得的设备了.它的好处太多了:1:轻 ...
- VS番茄助手安装(vs2015+vs2010):卸载之前的vs助手再安装新版本
1 卸载之前的vs助手 vs2010: vs2015: 2 安装新版本
- a*b(高进度乘以int类型的数)
以下是我今日的a-b(高精度)的程序,\(^o^)/偶也偶也偶也偶也! 程序: #include<stdio.h> #include<string.h> char s[1000 ...
- jQuery慢慢啃之ajax(九)
1.jQuery.ajax(url,[settings])//通过 HTTP 请求加载远程数据 如果要处理$.ajax()得到的数据,则需要使用回调函数.beforeSend.error.dataFi ...
- Nodejs简单验证码ccap安装
首先要求: node npm 安装时如果提示npm-gyp失败,可进行如下操作: 确认python版本2.7+ 安装npm install ccap 如果失败,尝试npm install ccap@0 ...
- Python 统计代码行
正在学习 Python, 做了个统计代码行的功能, 参考了网上很多前辈的帖子,添加了感觉还是比较实用的功能, 只是windows下测试了,而且代码文件编码形式是 utf-8的. 如果使用其它编码形式的 ...
- WPF布局容器综合展示
Border控件,以及几个重要要的属性:Background:背景的 Brush 对象BorderBrush:用来绘制边框BorderThickness: Border 边框的宽度,设置边框每一边的线 ...
- 字符串搜索算法Boyer-Moore
整理日: 2015年2月16日 1. 主要特征 假设文本串text长度为n,模式串pattern长度为m,BM算法的主要特征为: 从右往左进行比较匹配(一般的字符串搜索算法如KMP都是从从左往右进行匹 ...
- theano中的logisticregression代码学习
1 class LogisticRegression (object): 2 def __int__(self,...): 3 4 #定义一些与逻辑回归相关的各种函数 5 6 def method1( ...
- [转]hive中order by,distribute by,sort by,cluster by
转至http://my.oschina.net/repine/blog/296562 order by,distribute by,sort by,cluster by 查询使用说明 1 2 3 4 ...