Mysql性能优化案例研究-覆盖索引和SQL_NO

本文整理自网络，侵删。

场景

产品中有一张图片表pics，数据量将近100万条，有一条相关的查询语句，由于执行频次较高，想针对此语句进行优化

表结构很简单，主要字段：

代码如下:

user_id 用户ID
picname 图片名称
smallimg 小图名称

一个用户会有多条图片记录，现在有一个根据user_id建立的索引：uid，查询语句也很简单：取得某用户的图片集合：

代码如下:

select picname, smallimg from pics where user_id = xxx;

优化前

执行查询语句（为了查看真实执行时间，强制不使用缓存，为了防止在测试时因为读取了缓存造成对时间上的差别）

代码如下:

select SQL_NO_CACHE picname, smallimg from pics where user_id=17853;

执行了10次，平均耗时在40ms左右

使用explain进行分析：

代码如下:

explain select SQL_NO_CACHE picname, smallimg from pics where user_id=17853

使用了user_id的索引，并且是const常数查找，表示性能已经很好了

优化后

因为这个语句太简单，sql本身没有什么优化空间，就考虑了索引

修改索引结构，建立一个(user_id,picname,smallimg)的联合索引：uid_pic

重新执行10次，平均耗时降到了30ms左右

使用explain进行分析

看到使用的索引变成了刚刚建立的联合索引，并且Extra部分显示使用了'Using Index'

总结

‘Using Index'的意思是“覆盖索引”，它是使上面sql性能提升的关键

一个包含查询所需字段的索引称为“覆盖索引”

MySQL只需要通过索引就可以返回查询所需要的数据，而不必在查到索引之后进行回表操作，减少IO，提高了效率

例如上面的sql，查询条件是user_id，可以使用联合索引，要查询的字段是picname smallimg，这两个字段也在联合索引中，这就实现了“覆盖索引”，可以根据这个联合索引一次性完成查询工作，所以提升了性能。

扩展研究

一、Mysql缓存，SQL_NO_CACHE和SQL_CACHE 的区别

上边在进行测试的时候，为了防止读取缓存造成对实验结果的影响使用到了SQL_NO_CACHE这个功能，对于SQL_NO_CACHE的介绍官网如下：

代码如下:

SQL_NO_CACHE means that the query result is not cached. It does not mean that the cache is not used to answer the query.
You may use RESET QUERY CACHE to remove all queries from the cache and then your next query should be slow again. Same effect if you change the table, because this makes all cached queries invalid.

当我们想用SQL_NO_CACHE来禁止结果缓存时发现结果和我们的预期不一样，查询执行的结果仍然是缓存后的结果。其实，SQL_NO_CACHE的真正作用是禁止缓存查询结果，但并不意味着cache不作为结果返回给query。

在说白点就是，不是本次查询不使用缓存，而是本次查询结果不做为下次查询的缓存。

还有就是，mysql本身是有对sql语句缓存的机制的，合理设置我们的mysql缓存可以降低数据库的io资源，因此，这里我们有必要再看一下如何控制这个比较安逸的功能。

看图如下：

其中各项的含义为：

1、have_query_cache
是否支持查询缓存区 “YES”表是支持查询缓存区

2、query_cache_limit
可缓存的Select查询结果的最大值 1048576 byte /1024 = 1024kB 即最大可缓存的select查询结果必须小于 1024KB

3、query_cache_min_res_unit
每次给query cache结果分配内存的大小默认是 4096 byte 也即 4kB

4、query_cache_size
如果你希望禁用查询缓存，设置 query_cache_size=0。禁用了查询缓存，将没有明显的开销

5、query_cache_type
查询缓存的方式(默认是 ON)

1、完整查询的过程如下

当查询进行的时候，Mysql把查询结果保存在qurey cache中，但是有时候要保存的结果比较大，超过了query_cache_min_res_unit的值，这时候mysql将一边检索结果，一边进行慢慢保存结果，所以，有时候并不是把所有结果全部得到后再进行一次性保存，而是每次分配一块query_cache_min_res_unit 大小的内存空间保存结果集，使用完后，接着再分配一个这样的块，如果还不不够，接着再分配一个块，依此类推，也就是说，有可能在一次查询中，mysql要进行多次内存分配的操作，而我们应该知道，频繁操作内存都是要耗费时间的。

2、内存碎片的产生

当一块分配的内存没有完全使用时，MySQL会把这块内存Trim掉，把没有使用的那部分归还以重复利用。比如，第一次分配4KB,只用了3KB，剩1KB，第二次连续操作，分配4KB，用了2KB，剩2KB，这两次连续操作共剩下的1KB+2KB=3KB，不足以做个一个内存单元分配，这时候，内存碎片便产生了。

阅读剩余部分