MySQL数据库出现大量Locked的一个案例

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
云数据库 RDS MySQL,高可用系列 2核4GB
简介:
做为一款轻量级 数据库软件, MySQL在使用过程中遇到访问速度慢,或者无法响应这类的问题,解决方式基本都有定式,一般第一反应都会是登录到MySQL, show processlist看看当前连接状态。
  虽说简单,但show processlist显示的信息确实是相当有用,有一回,三思收到反馈说MySQL查询很慢,于是,赶紧登录到mysql中,执行show processlist查看当前连接信息:
mysql> show processlist;
+--------+-------------+--------------------+-------+---------+-------+----------------------------------+----------------------------------------------------------------------------------+
| Id     | User        | Host               | db    | Command | Time  | State                            | Info                                                                             |
+--------+-------------+--------------------+-------+---------+-------+----------------------------------+----------------------------------------------------------------------------------+
|      1 | system user |                    | NULL  | Connect | 342266| Waiting for master to send event | NULL                                                                             |
|      2 | system user |                    | hdpic | Connect |   872 | Locked                           | UPDATE a SET STATE=0 WHERE ID=83752                                              |
| 123890 | hdpic_read  | 192.168.1.79:54910 | hdpic | Query   |  1512 | Sending data                     | select z.ID,z.TITLE,z.CREATOR_USER_NICK,z.CREATOR_USER_IDEN,z.LASTEDITOR_TI      |
| 124906 | hdpic_read  | 192.168.1.39:18844 | hdpic | Query   |   845 | Locked                           | select * from a where ((ID = 78789) AND (STATE != 0))                            |
| 124912 | hdpic_read  | 192.168.1.39:18862 | hdpic | Query   |   845 | Locked                           | select * from a where ((ID = 16031) AND (STATE != 0))                            |
| 124914 | hdpic_read  | 192.168.1.39:18865 | hdpic | Query   |   837 | Locked                           | select * from a where ((ID = 39109) AND (STATE != 0))                            |
| 124917 | hdpic_read  | 192.168.1.39:18875 | hdpic | Query   |   833 | Locked                           | select * from a where ((ID = 16031) AND (STATE != 0))                            |
................
................
................
  一堆的Locked,怪不得慢啊,阻塞的时间不短了,十几分钟。
  通常来说存在Locked就说明当前读写操作存在被阻塞的情况,一般我们看到锁都会下意识认为是由于写阻塞了读,上面的结果看仿佛也符合这一特征:只有一条UPDATE,而无数条的SELECT。猜是必须的,但不能瞎猜,这毕竟是线上系统,就算想杀连接的线程,也是要杀掉造成阻塞的那个,不能把所有Locked的全杀了,不然DBA本人很快也要被人杀了,因此具体情况如何还是需要继续分析。
  从show processlist查看到的信息来看,UPDATE的语句是很简单的,分析a的表结构,该表为MyISAM表,ID为该表主键,该条更新应该能够瞬间执行完,即使系统繁忙也不应该,而且通过查看当前的系统状态,整体负载很低,iostat中看I/Owait几可忽略,该写操作不太可能这么长时间都没有执行完。
  这个时候再分析show processlist中显示的信息,发现id 123890的语句执行时间最长,肯定是在该UPDATE语句之前执行的,通过show full processlist查看语句详表,看到该查询也访问到了a表,经此分析,应该是该语句长时间的读阻塞了写,而被阻塞的写操作由于处于最优先处理队列,又阻塞了其它的读。
  不过这些都还只是我们的推论,考虑到线上系统服务的可靠性,最好还是能找到更确切的证据,而后再做操作。

mysqladmin命令有一个debug参数,可以分析当前MySQL服务的状态信息,同时也可以用来帮助我们定位当前锁的详细情况,这里我们通过该命令分析一下当前MySQL服务的详细状态,执行mysqladmin命令如下:
  [root@phpmysql02 data]# mysqladmin -ujss -p -S /data/3306/mysql.sock debug
   Enter password:
  debug会将状态信息生成到mysql的错误文件,一般锁的信息都会保存在最后几行,这里我们在操作系统层error log最后几行:
[root@phpmysql02 data]# tail -10 phpmysql02.err
Thread database.table_name          Locked/Waiting        Lock_type
2       hdpic.t_wiki_zutu           Waiting - write       Highest priority write lock
123890  hdpic.t_wiki_zutu_category  Locked - read         Low priority read lock
123890  hdpic.t_wiki_zutu_photo     Locked - read         Low priority read lock
123890  hdpic.t_wiki_zutu           Locked - read         Low priority read lock
124906  hdpic.t_wiki_zutu           Waiting - read        Low priority read lock
  从上述信息可以看出,123890持有的读锁阻塞了2的写入和124906的读操作,这个状态符合我们的推论,接下来处理就比较单纯了,如果现状不可接受,不能继续等待,将123890杀掉,释放资源即可:
  mysql> kill 123890;
  Query OK, 0 rows affected (0.00 sec)
  再次执行show processlist查看:
mysql> show processlist;
+--------+-------------+--------------------+-------+---------+--------+----------------------------------+------------------+
| Id     | User        | Host               | db    | Command | Time   | State                            | Info             |
+--------+-------------+--------------------+-------+---------+--------+----------------------------------+------------------+
|      1 | system user |                    | NULL  | Connect | 342390 | Waiting for master to send event | NULL             |
| 124906 | hdpic_read  | 192.168.1.39:18844 | hdpic | Sleep   |      1 |                                  | NULL             |
| 124912 | hdpic_read  | 192.168.1.39:18862 | hdpic | Sleep   |      2 |                                  | NULL             |
| 124914 | hdpic_read  | 192.168.1.39:18865 | hdpic | Sleep   |      1 |                                  | NULL             |
| 124917 | hdpic_read  | 192.168.1.39:18875 | hdpic | Sleep   |      1 |                                  | NULL             |
| 124919 | hdpic_read  | 192.168.1.39:18877 | hdpic | Sleep   |      2 |                                  | NULL             |
................
................
................
  已经没有Locked的连接,此时向前端人员询问,告知响应慢的现象也已经消除,服务恢复正常。


最新内容请见作者的GitHub页:http://qaseven.github.io/

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
SQL 数据库 数据安全/隐私保护
数据库数据恢复——sql server数据库被加密的数据恢复案例
SQL server数据库数据故障: SQL server数据库被加密,无法使用。 数据库MDF、LDF、log日志文件名字被篡改。 数据库备份被加密,文件名字被篡改。
|
3月前
|
关系型数据库 MySQL Linux
MySQL原理简介—6.简单的生产优化案例
本文介绍了数据库和存储系统的几个主题: 1. **MySQL日志的顺序写和数据文件的随机读指标**:解释了磁盘随机读和顺序写的原理及对数据库性能的影响。 2. **Linux存储系统软件层原理及IO调度优化原理**:解析了Linux存储系统的分层架构,包括VFS、Page Cache、IO调度等,并推荐使用deadline算法优化IO调度。 3. **数据库服务器使用的RAID存储架构**:介绍了RAID技术的基本概念及其如何通过多磁盘阵列提高存储容量和数据冗余性。 4. **数据库Too many connections故障定位**:分析了MySQL连接数限制问题的原因及解决方法。
132 23
|
29天前
|
SQL 存储 分布式数据库
分布式存储数据恢复—hbase和hive数据库数据恢复案例
分布式存储数据恢复环境: 16台某品牌R730xd服务器节点,每台服务器节点上有数台虚拟机。 虚拟机上部署Hbase和Hive数据库。 分布式存储故障: 数据库底层文件被误删除,数据库不能使用。要求恢复hbase和hive数据库。
75 12
|
27天前
|
关系型数据库 MySQL 大数据
大数据新视界--大数据大厂之MySQL 数据库课程设计:MySQL 数据库 SQL 语句调优的进阶策略与实际案例(2-2)
本文延续前篇,深入探讨 MySQL 数据库 SQL 语句调优进阶策略。包括优化索引使用,介绍多种索引类型及避免索引失效等;调整数据库参数,如缓冲池、连接数和日志参数;还有分区表、垂直拆分等其他优化方法。通过实际案例分析展示调优效果。回顾与数据库课程设计相关文章,强调全面认识 MySQL 数据库重要性。为读者提供综合调优指导,确保数据库高效运行。
|
1月前
|
NoSQL MongoDB 数据库
数据库数据恢复——MongoDB数据库服务无法启动的数据恢复案例
MongoDB数据库数据恢复环境: 一台Windows Server操作系统虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 管理员在未关闭MongoDB服务的情况下拷贝数据库文件。将MongoDB数据库文件拷贝到其他分区后,对MongoDB数据库所在原分区进行了格式化操作。格式化完成后将数据库文件拷回原分区,并重新启动MongoDB服务。发现服务无法启动并报错。
|
3月前
|
存储 SQL 关系型数据库
服务器数据恢复—云服务器上mysql数据库数据恢复案例
某ECS网站服务器,linux操作系统+mysql数据库。mysql数据库采用innodb作为默认存储引擎。 在执行数据库版本更新测试时,操作人员误误将在本来应该在测试库执行的sql脚本在生产库上执行,导致生产库上部分表被truncate,还有部分表中少量数据被delete。
114 25
|
3月前
|
SQL 数据库
数据库数据恢复—SQL Server报错“错误 823”的数据恢复案例
SQL Server数据库附加数据库过程中比较常见的报错是“错误 823”,附加数据库失败。 如果数据库有备份则只需还原备份即可。但是如果没有备份,备份时间太久,或者其他原因导致备份不可用,那么就需要通过专业手段对数据库进行数据恢复。
|
3月前
|
存储 运维 数据挖掘
虚拟化数据恢复—误还原快照导致虚拟机上数据库丢失的数据恢复案例
虚拟化数据恢复环境&故障: vmfs文件系统,存储的数据是SqlServer数据库及其他办公文件。 工作人员误将快照还原,导致了SqlServer数据库数据的丢失,需要恢复原来的SqlServer数据库文件。
108 22
|
3月前
|
SQL 关系型数据库 MySQL
数据库数据恢复——MySQL简介和数据恢复案例
MySQL数据库数据恢复环境&故障: 本地服务器,安装的windows server操作系统。 操作系统上部署MySQL单实例,引擎类型为innodb,表空间类型为独立表空间。该MySQL数据库没有备份,未开启binlog。 人为误操作,在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作。
|
3月前
|
SQL 关系型数据库 MySQL
MySQL原理简介—11.优化案例介绍
本文介绍了四个SQL性能优化案例,涵盖不同场景下的问题分析与解决方案: 1. 禁止或改写SQL避免自动半连接优化。 2. 指定索引避免按聚簇索引全表扫描大表。 3. 按聚簇索引扫描小表减少回表次数。 4. 避免产生长事务长时间执行。