问题描述
有个项目网站访问异常缓慢卡顿,有时候甚至报404,网站代码确定没有问题,那只好检查数据库,看数据库那边是否合理或有待优化。
数据库排查
排查之前基本确定是一张存储引擎为 MyISAM
的表的问题(在这里取表名为 A
),所有的访问都卡在了 A
表的查询上面,那么为什么会卡在这里呢???接下来就开始分析排查
查看慢查询日志
一般正式环境中,都会开启慢查询日志,方便后期的维护。
因为表 A
有 100 万条左右的记录,所以虽然对应的列有做索引,但第一反应还是以为是数据太多查询慢导致的网站访问缓慢,所以去查看慢查询日志,结果发现基本上没有 A
表的慢查询记录。
基于慢查询日志查看结果的思考
这就有点离谱了,为什么明明卡在了 A
表,但关于 A
表的慢查询却没有呢??难道是慢查询记录有问题?还是说 A
表查询其实是不慢的?
排除疑惑,确定排查方向
有了上面的疑惑,我就在网上查看相关的慢查询资料,后来看到了下面这一段话:
只有当一个 SQL 的执行时间(不包括锁等待的时间
lock_time
)大于long_query_time
的时候,才会判定为慢查询 SQL;但是判定为慢查询 SQL 之后,输出的Query_time
包括了(执行时间+锁等待时间),并且也会输出Lock_time
时间。当一个 SQL 的执行时间(排除lock_time
)小于long_query_time
的时候(即使他锁等待超过了很久),也不会记录到慢查询日志当中的。
看了上面这段话,我恍然大悟。既然卡在了 A
表,又没有关于 A
表的慢查询,那唯一的可能就是锁定时间 lock_time
太长了。那就往这个方向分析吧。
关于 MyISAM 表的锁机制与分析
MyISAM 表的锁机制
MySQL 数据表存储引擎不同,锁机制也不同。如:MyISAM 和 MEMORY 存储引擎采用的是表级锁table-level locking
;BDB 存储引擎采用的是页面锁 page-level locking
,但也支持表级锁;InnoDB 存储引擎既支持行级锁 row-level locking
,也支持表级锁,但默认情况下是采用行级锁。
所以 MyISAM 的锁是表级锁,一旦锁定就是整张表锁定。MyISAM 有读锁和写锁,具体的锁定机制如下图:
MyISAM 有 表共享读锁 table read lock
和表独占写锁 table write lock
两种,有以下几点特性:
- MyISAM 表的读操作,不会阻塞其他用户对同一个表的读请求,但会阻塞对同一个表的写请求;
- MyISAM 表的写操作,会阻塞其他用户对同一个表的读和写操作;
- MyISAM 表的读、写操作之间、以及写操作之间是串行的
一些有助于排查的语句
SHOW STATUS LIKE ‘table%’
通过语句 SHOW STATUS LIKE 'table%';
可以查看到如下图的查询结果:
Table_locks_immediate
:能够立即获得表级锁的锁请求次数Table_locks_waited
:不能立即获取表级锁而需要等待的锁请求次数
如果 Table_locks_waited
值较高,且存在性能问题,则说明存在着较严重的表级锁争用情况
当初执行以上语句时,确实看到
Table_locks_waited
非常大,好像有几千~~~
SHOW OPEN TABLES
这个语句的作用是 列举在表缓存中当前被打开的非TEMPORARY表,会返回一下字段:
Database
:含有该表