1125MySQL Sending data致使查询很慢的问题详细分析

-- 问题1 tablename使用主键索引反而比idx_ref_id慢的缘由
EXPLAIN SELECT SQL_NO_CACHE COUNT(id) FROM dbname.tbname FORCE INDEX (idx_ref_id)
EXPLAIN SELECT SQL_NO_CACHE COUNT(id) FROM dbname.tbname FORCE INDEX (PRIMARY)

缘由：能够看到走主键索引的时候效率比较差。那么是为何呢。
平时咱们检索一列的时候，基本上等值或范围查询，那么索引基数大的索引必然效率很高。
可是在作count(*)的时候并无检索具体的一行或者一个范围。那么选择基数小的索引对,count操做效率会更高。
在作count操做的时候，mysql会遍历每一个叶子节点，因此基数越小，效率越高。
mysql非聚簇索引叶子节点保存的主键ID，因此须要检索两遍索引。可是这里相对于遍历主键索引。及时检索两遍索引效率也比单纯的检索主键索引快。
[主键索引太分散了]

能够参见http://www.2cto.com/database/201508/433975.html

-- 问题2 针对一个大表
SELECT SQL_NO_CACHE COUNT(id) FROM dbname.tbname 特别慢的处理办法，
通常使用OPTIMIZE TABLE tablename
使用OPTIMIZE TABLE 对表空间信息进行优化,而后执行COUNT效果很快提高

实战：MySQL Sending data致使查询很慢的问题详细分析
转自http://blog.csdn.net/yunhua_lee/article/details/8573621

这两天帮忙定位一个MySQL查询很慢的问题，定位过程综合各类方法、理论、工具，颇有表明性，分享给你们做为新年礼物：）

 

【问题现象】

使用sphinx支持倒排索引，但sphinx从mysql查询源数据的时候，查询的记录数才几万条，但查询的速度很是慢，大概要4~5分钟左右

 

【处理过程】

1）explain

首先怀疑索引没有建好，因而使用explain查看查询计划，结果以下：

从explain的结果来看，整个语句的索引设计是没有问题的，除了第一个表由于业务须要进行整表扫描外，其它的表都是经过索引访问

 

2）show processlist;

explain看不出问题，那到底慢在哪里呢？

因而想到了使用 show processlist查看sql语句执行状态，查询结果以下：

发现很长一段时间，查询都处在 “Sending data”状态

查询一下“Sending data”状态的含义，原来这个状态的名称很具备误导性，所谓的“Sending data”并非单纯的发送数据，而是包括“收集 + 发送 数据”。

这里的关键是为何要收集数据，缘由在于：mysql使用“索引”完成查询结束后，mysql获得了一堆的行id，若是有的列并不在索引中，mysql须要从新到“数据行”上将须要返回的数据读取出来返回个客户端。

 

3）show profile

为了进一步验证查询的时间分布，因而使用了show profile命令来查看详细的时间分布

首先打开配置：set profiling=on;
执行完查询后，使用show profiles查看query id;
使用show profile for query query_id查看详细信息;

结果以下：

从结果能够看出，Sending data的状态执行了216s

 

4）排查对比

通过以上步骤，已经肯定查询慢是由于大量的时间耗费在了Sending data状态上，结合Sending data的定义，将目标聚焦在查询语句的返回列上面

通过一 一排查，最后定为到一个description的列上，这个列的设计为：`description`varchar(8000) DEFAULT NULL COMMENT '游戏描述',

因而采起了对比的方法，看看“不返回description的结果”如何。show profile的结果以下：

能够看出，不返回description的时候，查询时间只须要15s，返回的时候，须要216s，二者相差15倍

 

【原理研究】

至此问题已经明确，但原理上咱们还须要继续探究。

这篇淘宝的文章很好的解释了相关原理：innodb使用大字段text，blob的一些优化建议

这里的关键信息是：当Innodb的存储格式是 ROW_FORMAT=COMPACT (or ROW_FORMAT=REDUNDANT)的时候，Innodb只会存储前768字节的长度，剩余的数据存放到“溢出页”中。

咱们使用show table status来查看表的相关信息：

能够看到，平均一行大约1.5K，也就说大约1/10行会使用“溢出存储”，一旦采用了这种方式存储，返回数据的时候原本是顺序读取的数据，就变成了随机读取了，因此致使性能急剧降低。

 

另外，在测试过程当中还发现，不管这条语句执行多少次，甚至将整个表select *几回，语句的执行速度都没有明显变化。这个表的数据和索引加起来才150M左右，而整个Innodb buffer pool有5G，缓存整张表绰绰有余，若是缓存了溢出页，性能应该大幅提升才对。

但实测结果却并无提升，所以从这个测试能够推论Innodb并无将溢出页（overflow page）缓存到内存里面。

这样的设计也是符合逻辑的，由于overflow page原本就是存放大数据的，若是也放在缓存里面，就会出现一次大数据列（blob、text、varchar）查询，可能就将全部的缓存都更新了，这样会致使其它普通的查询性能急剧降低。

 

【解决方法】

找到了问题的根本缘由，解决方法也就不难了。有几种方法：

1）查询时去掉description的查询，但这受限于业务的实现，可能须要业务作较大调整

2）表结构优化，将descripion拆分到另外的表，这个改动较大，须要已有业务配合修改，且若是业务仍是要继续查询这个description的信息，则优化后的性能也不会有很大提高。