那么可以看到以下问题：
　　我们的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 长期占用 ＋
　　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.限制查询结果集大小，避免因查询结果集太大导致服务死掉