MySQL高速缓存启动方法及参数详解query_cache_size=32M query_cache_type=1

来源:互联网 发布:windows ppt模板 编辑:程序博客网 时间:2024/06/05 19:27

在MYSQL的配置文件my.ini(window)或my.cnf(linux)中找到如下内容:

# Query cache is used tocache SELECT results and later return them

# without actualexecuting the same query once again. Having the query

# cache enabled mayresult in significant speed improvements, if your

# have a lot of identicalqueries and rarely changing tables. See the

# “Qcache_lowmem_prunes”status variable to check if the current value

# is high enough for yourload.

# Note: In case yourtables change very often or if your queries are

# textually differentevery time, the query cache may result in a

# slowdown instead of aperformance improvement.

query_cache_size=0

以上信息是默认配置,其注释意思是说,MYSQL的查询缓存用于缓存select查询结果,并在下次接收到同样的查询请求时,不再执行实际查询处理而直接返回结果,有这样的查询缓存能提高查询的速度,使查询性能得到优化,前提条件是你有大量的相同或相似的查询,而很少改变表里的数据,否则没有必要使用此功能。可以通过Qcache_lowmem_prunes变量的值来检查是否当前的值满足你目前系统的负载。注意:如果你查询的表更新比较频繁,而且很少有相同的查询,最好不要使用查询缓存。

具体配置方法:

1.将query_cache_size设置为具体的大小,具体大小是多少取决于查询的实际情况,但最好设置为1024的倍数,参考值32M。

2.增加一行:query_cache_type=1

query_cache_type参数用于控制缓存的类型,注意这个值不能随便设置,必须设置为数字,如果设置为0,那么可以说,你的缓存根本就没有用,相当于禁用了。

 如果设置为1,将会缓存所有的结果,除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。

如果设置为2,则只缓存在select语句中通过SQL_CACHE指定需要缓存的查询。

OK,配置完后的部分文件如下:

query_cache_size=128M

query_cache_type=1

保存文件,重新启动MYSQL服务,然后通过如下查询来验证是否真正开启了:

mysql>show variables like ‘%query_cache%’;

+——————————+———–+

|Variable_name               |Value    |

+——————————+———–+

|have_query_cache            |YES      |

|query_cache_limit           | 1048576   |

|query_cache_min_res_unit    |4096     |

|query_cache_size            | 134217728 |

|query_cache_type            |ON       |

|query_cache_wlock_invalidate |OFF      |

+——————————+———–+

 主要看query_cache_size和query_cache_type的值是否跟我们设的一致:

这里query_cache_size的值是134217728,我们设置的是128M,实际是一样的,只是单位不同,可以自己换算下:134217728= 128*1024*1024。

query_cache_type设置为1,显示为ON,这个前面已经说过了。

总之,看到上边的显示表示设置正确,但是在实际的查询中是否能够缓存查询,还需要手动测试下,我们可以通过show status like‘%Qcache%’;语句来测试,现在我们开启了查询缓存功能,在执行查询前,我们先看看相关参数的值:

mysql>show status like ‘%Qcache%’;

+————————-+———–+

|Variable_name          |Value    |

+————————-+———–+

|Qcache_free_blocks     |1        |

|Qcache_free_memory     | 134208800 |

|Qcache_hits            |0        |

|Qcache_inserts         |0        |

|Qcache_lowmem_prunes   |0        |

|Qcache_not_cached      |2        |

| Qcache_queries_in_cache|0        |

|Qcache_total_blocks    |1        |

+————————-+———–+

8 rows in set (0.00sec)

这里顺便解释下这个几个参数的作用:

Qcache_free_blocks:表示查询缓存中目前还有多少剩余的blocks,如果该值显示较大,则说明查询缓存中的内存碎片过多了,可能在一定的时间进行整理。

Qcache_free_memory:查询缓存的内存大小,通过这个参数可以很清晰的知道当前系统的查询内存是否够用,是多了,还是不够用,DBA可以根据实际情况做出调整。

Qcache_hits:表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大,缓存效果越理想。

Qcache_inserts:表示多少次未命中然后插入,意思是新来的SQL请求在缓存中未找到,不得不执行查询处理,执行查询处理后把结果insert到查询缓存中。这样的情况的次数,次数越多,表示查询缓存应用到的比较少,效果也就不理想。当然系统刚启动后,查询缓存是空的,这很正常。

Qcache_lowmem_prunes:该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值,用户可以适当的调整缓存大小。

Qcache_not_cached:表示因为query_cache_type的设置而没有被缓存的查询数量。

Qcache_queries_in_cache:当前缓存中缓存的查询数量。

Qcache_total_blocks:当前缓存的block数量。

下边我们测试下:

比如执行如下查询语句

mysql>select * from user where id = 2;

+—-+——-+

| id |name  |

+—-+——-+

2 |test2 |

+—-+——-+

1 row in set (0.02sec)

然后执行show status like‘%Qcache%’,看看有什么变化:

mysql>show status like ‘%Qcache%’;

+————————-+———–+

|Variable_name          |Value    |

+————————-+———–+

|Qcache_free_blocks     |1        |

|Qcache_free_memory     | 134207264 |

|Qcache_hits            |0        |

|Qcache_inserts         |1        |

|Qcache_lowmem_prunes   |0        |

|Qcache_not_cached      |3        |

| Qcache_queries_in_cache|1        |

|Qcache_total_blocks    |4        |

+————————-+———–+

8 rows in set (0.00sec)

对比前面的参数值,我们发现Qcache_inserts变化了。Qcache_hits没有变,下边我们在执行同样的查询
select * from user where id =2,按照前面的理论分析:Qcache_hits应该等于1,而Qcache_inserts应该值不变(其他参数的值变化暂时不关注,读者可以自行测试),再次执行:

show status like‘%Qcache%’,看看有什么变化:

mysql>show status like ‘%Qcache%’;

+————————-+———–+

|Variable_name          |Value    |

+————————-+———–+

|Qcache_free_blocks     |1        |

|Qcache_free_memory     | 134207264 |

|Qcache_hits            |1        |

|Qcache_inserts         |1        |

|Qcache_lowmem_prunes   |0        |

|Qcache_not_cached      |4        |

| Qcache_queries_in_cache|1        |

|Qcache_total_blocks    |4        |

+————————-+———–+

8 rows in set (0.00sec)

OK,果然跟我们分析的完全一致。


测试:

1)第一次执行 

select * from user where id=1;
受影响的行: 0
时间: 0.001s

2)第二次执行 

select * from user where id=1;
受影响的行: 0
时间: 0.000s

由以上查询结果可见,第一次需要0.001s,第二次需要不到0.001s。但是查询数据量较大时,这个时间差别很小,几乎没有变化。

如:

1)第一次执行

select * from user where name ='适度';
受影响的行: 0
时间: 0.137s

2)第二次执行 

select * from user where name ='适度';
受影响的行: 0
时间: 0.137s

这种数据量很大的查询时,时间没有太大的变化。









0 0
原创粉丝点击