数据库引起的网站访问缓慢卡顿排查经历

问题描述

有个项目网站访问异常缓慢卡顿，有时候甚至报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：含有该表