直接切入正題吧:

通常來說，我們看到的慢查詢一般還不致于導致掛站，頂多就是應用響應變慢
不過這個恰好今天被我撞見了，一個慢查詢把整個網站搞掛了
先看看這個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 的這個值有多少數據，來進一步驗證我們的猜想。