专栏名称: 程序猿

本微信公众号：imkuqin，为程序员提供最新最全的编程学习资料的查询。目前已经开通PHP、C/C++函数库、.NET Framework类库、J2SE API查询功能。

一条慢SQL引发的血案

程序猿 · 公众号 · 程序员 · 2016-11-08 22:29

正文

来自：Svan.xiean - 博客园
链接：http://www.cnblogs.com/svan/p/5584411.html（点击尾部阅读原文前往）
已获转载授权

直接切入正题吧:

通常来说，我们看到的慢查询一般还不致于导致挂站，顶多就是应用响应变慢
不过这个恰好今天被我撞见了，一个慢查询把整个网站搞挂了

先看看这个SQL张撒样子：

# Query_time: 70.472013 Lock_time: 0.000078 Rows_sent: 7915203 Rows_examined: 15984089 Rows_affected: 0
# Bytes_sent: 1258414478
use js_sku;
SET timestamp=1465850117;
SELECT
ss_id, ss_sa_id, ss_si_id, ss_av_zid, ss_av_fid, ss_artno,
ss_av_zvalue, ss_av_fvalue, ss_av_zpic, ss_av_fpic, ss_number,
ss_sales, ss_cprice, ss_price, ss_stock, ss_orderid, ss_status,
ss_add_time, ss_lastmodify
FROM js_sgoods_sku
WHERE ss_si_id = 0 AND ss_status > 0
ORDER BY
ss_orderid DESC, ss_av_fid ASC;

这里贴出来的就是 mysql slow log 的信息，查询时间用了高达 70s！！

看到慢查询我们一般第一反应是这个语句没有用到索引？或者是索引不合理么？那我们会去看看执行计划：

mysql> explain SELECT
-> ss_id, ss_sa_id, ss_si_id, ss_av_zid, ss_av_fid, ss_artno,
-> ss_av_zvalue, ss_av_fvalue, ss_av_zpic, ss_av_fpic, ss_number,
-> ss_sales, ss_cprice, ss_price, ss_stock, ss_orderid, ss_status,
-> ss_add_time, ss_lastmodify
-> FROM js_sgoods_sku
-> WHERE ss_si_id = 0 AND ss_status > 0
-> ORDER BY
-> ss_orderid DESC, ss_av_fid ASC;
+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+
| 1 | SIMPLE | js_sgoods_sku | ref | ss_si_id | ss_si_id | 4 | const | 9516091 | Using where; Using filesort |
+----+-------------+---------------+------+---------------+----------+---------+-------+---------+-----------------------------+

1、row in set (0.00 sec)

这个看起来似乎用到了索引，可是为什么扫描到行还是这么多呢？那我们就去看看表结构了，期望能从中找到点有价值的东西：

我们看到如下可用信息：

KEY `ss_si_id` (`ss_si_id`,`ss_av_zid`,`ss_av_fid`) USING BTREE,
`ss_si_id` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '对应js_sgoods_info.si_id',

我们看到索引似乎还能比较能够接受，但是我们看到这个 ss_si_id 这个字段实际上是 goods_info 表的主键，也就是说它的离散程度应该是很大的，也就是区分度很大。
其实到这一步我们基本上可以认为是由于我们这个表里边有很多 ss_si_id=0 导致，不过我们可以进一步的来证实我们的猜想：

1、首先我们可以先确定我们的统计信息没有问题
2、其次我们再count ss_si_id=0 的这个值有多少数据，来进一步验证我们的猜想。

那么我们先查看以下这个索引的统计信息：

xiean@localhost:js_sku 03:27:42>show index from js_sgoods_sku;
+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| js_sgoods_sku | 0 | PRIMARY | 1 | ss_id | A | 18115773 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | ss_si_id | 1 | ss_si_id | A | 1811577 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | ss_si_id | 2 | ss_av_zid | A | 6038591 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | ss_si_id | 3 | ss_av_fid | A | 18115773 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | IDX_001 | 1 | ss_sa_id | A | 3623154 | NULL | NULL | | BTREE | | |
+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

那么可以看到以下问题：

我们的ss_si_id 这个字段并没有我们表面上看到的因为关联了某个表的主键，它的Cardinality 值就应该接近于 PRIMARY 的值。而是差别比较大的,难道是索引的统计信息不准确？那我们尝试重新收集下索引的统计信息：

xiean@localhost:js_sku 03:27:47>analyze table js_sgoods_sku;
+----------------------+---------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+----------------------+---------+----------+----------+
| js_sku.js_sgoods_sku | analyze | status | OK |
+----------------------+---------+----------+----------+
but ，我们再次查看这些索引的统计信息：
xiean@localhost:js_sku 03:28:14>show index from js_sgoods_sku;
+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| js_sgoods_sku | 0 | PRIMARY | 1 | ss_id | A | 18621349 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | ss_si_id | 1 | ss_si_id | A | 1551779 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | ss_si_id | 2 | ss_av_zid | A | 6207116 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | ss_si_id | 3 | ss_av_fid | A | 18621349 | NULL | NULL | | BTREE | | |
| js_sgoods_sku | 1 | IDX_001 | 1 | ss_sa_id | A | 3724269 | NULL | NULL | | BTREE | | |
+---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
我们可以看到 ss_si_id 的离散程度（Cardinality）没有增加反而有向下波动的趋势，因为这个信息是采集部分页的来的，而每个页上边数据分布是不一样的，导致我们这个索引收集的统计信息就回有所变化。
好吧，到这里我们可以认为我们的统计信息没有失效，那么我们就看数据的分别情况咯：
+--------------++----------++------------------+
| ss_si_id=0; || count(*) || 7994788/19048617 |
+--------------++----------++------------------+
| 7994788 || 19048617 || 0.4197 |
+--------------++----------++------------------+

额，不看不知道，一看吓一跳：我们这个表里边存在有大量的 ss_si_id＝0 的情况，占了整个表数据量的 41% ！！！

好吧问题找到了，那么接下来我们需要知道，为什么这个SQL语句会导致挂站呢？

我们通过观看应用程序服务器的监控看到一些信息：我们的 goods_service 这个服务异常：异常情况如下：

1、cpu 长期占用100% ＋
2、jstatck pid 无法dump 内存堆栈信息，必须强制dump －F
3、dump 出来的内存信息发现，这个进程里边所有线程均处于 BLOCKED 状态
4、通过jstat －gcutil 看到 FGC 相当频繁，10s左右就FGC一次
5、内存占用超过了分配的内存

那么最终的原因就是因为上边的慢查询查询了大量数据（最多有700w行数据），导致goods_service 内存暴涨，出现服务无法响应，进一步的恶化就是挂占

OK，知道了为什么会挂占，那么我们是如何解决这个问题的呢？

既然我们知道是由于查询了 ss_si_id＝0 导致的，那么我们屏蔽掉这个SQL不就好了么。屏蔽的办法可以有多种：

1、我们程序逻辑判断一下这类型的查询如果有查询 ss_si_id＝0 的一律封杀掉
2、我们改改SQL配置文件，修改SQL语句

我们发现DB服务器上存在大量的这个慢查询，而且DB服务器负载已经从 0.xx 飙升到了 50+ 了，随之而来的连接数也飙升的厉害，如果再不及时处理，估计DB服务器也挂掉了

那么我们最终采取以下处理办法：

1、运维配合研发修改SQL语句我们在这个WHERE 条件中添加了一个条件： AND ss_si_id 0 ,在MySQL之行计划层屏蔽掉此SQL;
2、DBA 开启kill 掉这个查询语句，避免DB服务器出现down机的情况，当然这个就用到了我们的 pt-kill 工具，不得不说这个工具相当好用

总结（经验与教训）：

1、类似这种查询 default 值的 SQL ，我们应该从源头上杜绝这类查询
2、限制查询结果集大小，避免因查询结果集太大导致服务死掉

●本文编号2047，以后想阅读这篇文章直接输入2047即可。

●本文分类“数据库”，搜索分类名可以获得相关文章。

●输入m可以获取到文章目录

本文内容的相关公众号推荐

数据库开发↓↓↓

Web编程↓↓↓

更多推荐《15个技术类公众微信》

涵盖：程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。