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

3.内存块的概念

先看下这个：

Qcache_total_blocks 表示所有的块

Qcache_free_blocks 表示未使用的块
这个值比较大，那意味着，内存碎片比较多，用flush query cache清理后，为被使用的块其值应该为1或0 ，因为这时候所有的内存都做为一个连续的快在一起了.

Qcache_free_memory 表示查询缓存区现在还有多少的可用内存
Qcache_hits 表示查询缓存区的命中个数，也就是直接从查询缓存区作出响应处理的查询个数
Qcache_inserts 表示查询缓存区此前总过缓存过多少条查询命令的结果
Qcache_lowmem_prunes 表示查询缓存区已满而从其中溢出和删除的查询结果的个数
Qcache_not_cached 表示没有进入查询缓存区的查询命令个数
Qcache_queries_in_cache 查询缓存区当前缓存着多少条查询命令的结果

优化提示：

如果Qcache_lowmem_prunes 值比较大，表示查询缓存区大小设置太小，需要增大。
如果Qcache_free_blocks 较多，表示内存碎片较多，需要清理，flush query cache

关于query_cache_min_res_unit大小的调优，书中给出了一个计算公式，可以供调优设置参考：

代码如下:

query_cache_min_res_unit = (query_cache_size - Qcache_free_memory) /Qcache_queries_in_cache

还要注意一点的是，FLUSH QUERY CACHE 命令可以用来整理查询缓存区的碎片，改善内存使用状况，但不会清理查询缓存区的内容，这个要和RESET QUERY CACHE相区别，不要混淆，后者才是清除查询缓存区中的所有的内容。
可以在 SELECT 语句中指定查询缓存的选项，对于那些肯定要实时的从表中获取数据的查询，或者对于那些一天只执行一次的查询，我们都可以指定不进行查询缓存，使用 SQL_NO_CACHE 选项。
对于那些变化不频繁的表，查询操作很固定，我们可以将该查询操作缓存起来，这样每次执行的时候不实际访问表和执行查询，只是从缓存获得结果，可以有效地改善查询的性能，使用 SQL_CACHE 选项。
下面是使用 SQL_NO_CACHE 和 SQL_CACHE 的例子：

代码如下:

mysql> select sql_no_cache id,name from test3 where id < 2;
mysql> select sql_cache id,name from test3 where id < 2;

注意：查询缓存的使用还需要配合相应得服务器参数的设置。

二、覆盖索引（偷懒整理一下，来自百度百科）

理解方式一：就是select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖。
理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了（或覆盖了）满足查询结果的数据就叫做覆盖索引。
理解方式三：是非聚集复合索引的一种形式，它包括在查询里的Select、Join和Where子句用到的所有列（即建索引的字段正好是覆盖查询条件中所涉及的字段，也即，索引包含了查询正在查找的数据）。

作用：

如果你想要通过索引覆盖select多列，那么需要给需要的列建立一个多列索引，当然如果带查询条件，where条件要求满足最左前缀原则。

Innodb的辅助索引叶子节点包含的是主键列，所以主键一定是被索引覆盖的。

（1）例如，在sakila的inventory表中，有一个组合索引(store_id,film_id)，对于只需要访问这两列的查询，MySQL就可以使用索引，如下：

代码如下:

mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventory\G

（2）再比如说在文章系统里分页显示的时候，一般的查询是这样的：

代码如下:

SELECT id, title, content FROM article ORDER BY created DESC LIMIT 10000, 10;

通常这样的查询会把索引建在created字段（其中id是主键），不过当LIMIT偏移很大时，查询效率仍然很低，改变一下查询：

代码如下:

SELECT id, title, content FROM article
INNER JOIN (
SELECT id FROM article ORDER BY created DESC LIMIT 10000, 10
) AS page USING(id)

此时，建立复合索引”created, id”（只要建立created索引就可以吧，Innodb是会在辅助索引里面存储主键值的），就可以在子查询里利用上Covering Index，快速定位id，查询效率嗷嗷的

注：本文是参考《Mysql性能优化案例 - 覆盖索引》的一篇文章借题发挥，参考了原文的知识点，自己做了一点的发挥和研究，原文被多次转载，不知作者何许人也，也不知出处在哪个，如需原文请自行搜索。

更多SQL内容来自木庄网络博客

标签：SQL

返回前面的内容

数据库系统概念第6版

￥41.1元 机械工业出版社

本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。

转载请注明出处：木庄网络博客 » Mysql性能优化案例研究-覆盖索引和SQL_NO_CACHE

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

数据库系统概念第6版

相关推荐

评论