MySql 缓存查询原理与缓存监控和索引监控介绍

查询缓存

1.查询缓存操作原理

mysql执行查询语句之前，把查询语句同查询缓存中的语句进行比较，且是按字节比较，仅完全一致才被认为相同。如下，这两条语句被视为不同的查询

SELECT * FROM tb1_name

Select * from tb1_name

1）不同数据库、不同协议版本，或字符集不同的查询被视为不同的查询并单独缓存。

2）以下两种类型的查询不被缓存

a.预处理语句

b.嵌套查询的子查询

3)从查询缓存抓取查询结果前，mysql检查用户对查询涉及的所有数据库和表是否有查询权限，如果没有则不使用缓存查询结果。

4）如果从缓存查询返回一个查询结果，服务器递增Qcache_hits状态变量，而不是Com_select

5）如果表改变，所有使用了该表的缓存查询变成不合法，从缓存移除。表可能被多种类型的语句改变，比如INSERT, UPDATE, DELETE, TRUNCATE TABLE, ALTER TABLE, DROP TABLE, 或DROP DATABASE.

参考连接：

http://dev.mysql.com/doc/refman/4.1/en/query-cache-operation.html

2.查看是否开启了缓存查询

SHOW VARIABLES LIKE 'have_query_cache';

MySql wbr>缓存查询原理与缓存监控 wbr>和 wbr>索引监控

3.从查询缓存中移除所有查询缓存

RESET QUERY CACHE;

4.查询缓存性能监控

SHOW STATUS LIKE 'Qcache%'

MySql wbr>缓存查询原理与缓存监控 wbr>和 wbr>索引监控

输出说明：

Qcache_free_blocks：查询缓存中的空闲内存块

Qcache_free_memory：查询缓存的空闲内存数量

Qcache_hits：查询缓存命中数量

Qcache_inserts：添加到查询缓存的查询的数量(不是表示没被缓存而进行的读，而是缓存失效而进行的读)

Qcache_lowmen_prunes：因内存太低，从缓存查询中删除的查询的数量

Qcache_not_chached：未缓存查询的数量(未被缓存、因为querey_cache_type设置没被缓存)

Qcache_queries_in_cache：缓存查询中注册的查询的数量

Qcache_total_blocks：查询缓存中的内存块总数

SELECT查询总数：

Com_select+Qcache_hits+ 解析错误的查询数(queries with errors found by parser)

其中，Com_select表示未命中缓存数，Qcache_hits表示缓存命中数

Com_select计算公式：

Qcache_inserts+Qcache_not_cached+权限检查错误数(queries with errors found during the column-privileges check)

索引监控

SHOW STATUS LIKE 'handler_read%';

MySql wbr>缓存查询原理与缓存监控 wbr>和 wbr>索引监控

输出说明：

Handler_read_first

The number of times the first entry in an index was read. If this value is high, it suggests that the server is doing a lot of full index scans; for example, SELECT col1 FROM foo, assuming that col1 is indexed

索引中的第一项(the first entry in an index)被读取的次数，如果该值很高，那表明服务器正在执行很多全索引扫描，例如 SELECT col1 FROM foo, 假设col1上建立了索引

Handler_read_key

The number of requests to read a row based on a key. If this value is high, it is a good indication that your tables are properly indexed for your queries.

基于某个键读取一行的请求次数。如果该值很高，那很好的说明了，对于执行的请求，表采用了适当的索引。

Handler_read_next

The number of requests to read the next row in key order. This value is incremented if you are querying an index column with a range constraint or if you are doing an index scan.

根据键顺序，读取下一行的请求次数。如果你正在查询一个带一系列约束的索引列或者正在执行索引扫描时，该值会增加

Handler_read_prev

The number of requests to read the previous row in key order. This read method is mainly used to optimize ORDER BY ... DESC

根据键的顺序，请求读取前一行的次数。该读取方法主要用于优化 ORDER BY ... DESC

Handler_read_rnd

The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that do not use keys properly.

在固定位置读取一行的请求次数。该值如果很高，那么说明正在执行许多要求对结果集排序的查询。可能在执行有许多要求全表扫描的查询，或没使用适合键的联合查询。

Handler_read_rnd_next

The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

读取数据文件中下一行的请求次数。该值很高，表明正在执行很多全表扫描。通常表明表没使用适当的索引或者查询请求没利用现成的索引。

参考连接：

http://dev.mysql.com/doc/refman/5.7/en/dynindex-statvar.html#statvar-index-H

参考连接：

http://dev.mysql.com/doc/refman/4.1/en/server-status-variables.html

http://dev.mysql.com/doc/refman/4.1/en/query-cache-status-and-maintenance.html

到此这篇关于MySql 缓存查询原理与缓存监控和索引监控介绍的文章就介绍到这了,更多相关MySql 缓存查询内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！