MySql緩存查詢原理與緩存監(jiān)控

And 索引監(jiān)控

by:授客

QQ：1033553122

查詢緩存

1.查詢緩存操作原理

mysql執(zhí)行查詢語句之前，把查詢語句同查詢緩存中的語句進(jìn)行比較，且是按字節(jié)比較，僅完全一致才被認(rèn)為相同。如下，這兩條語句被視為不同的查詢

SELECT

* FROM tb1_name

Select

* from tb1_name

1)不同數(shù)據(jù)庫、不同協(xié)議版本，或字符集不同的查詢被視為不同的查詢并單獨緩存。

2)以下兩種類型的查詢不被緩存

a.預(yù)處理語句

b.嵌套查詢的子查詢

3)從查詢緩存抓取查詢結(jié)果前，mysql檢查用戶對查詢涉及的所有數(shù)據(jù)庫和表是否有查詢權(quán)限，如果沒有則不使用緩存查詢結(jié)果。

4)如果從緩存查詢返回一個查詢結(jié)果，服務(wù)器遞增Qcache_hits狀態(tài)變量，而不是Com_select

5)如果表改變，所有使用了該表的緩存查詢變成不合法，從緩存移除。表可能被多種類型的語句改變，比如INSERT,

UPDATE, DELETE, TRUNCATE TABLE, ALTER TABLE, DROP TABLE,

或DROP

DATABASE.

參考連接：

2.查看是否開啟了緩存查詢

SHOW VARIABLES LIKE 'have_query_cache';

3.從查詢緩存中移除所有查詢緩存

RESET QUERY CACHE;

4.查詢緩存性能監(jiān)控

SHOW STATUS LIKE 'Qcache%'

輸出說明：

Qcache_free_blocks：查詢緩存中的空閑內(nèi)存塊

Qcache_free_memory：查詢緩存的空閑內(nèi)存數(shù)量

Qcache_hits：查詢緩存命中數(shù)量

Qcache_inserts：添加到查詢緩存的查詢的數(shù)量(不是表示沒被緩存而進(jìn)行的讀，而是緩存失效而進(jìn)行的讀)

Qcache_lowmen_prunes：因內(nèi)存太低，從緩存查詢中刪除的查詢的數(shù)量

Qcache_not_chached：未緩存查詢的數(shù)量(未被緩存、因為querey_cache_type設(shè)置沒被緩存)

Qcache_queries_in_cache：緩存查詢中注冊的查詢的數(shù)量

Qcache_total_blocks：查詢緩存中的內(nèi)存塊總數(shù)

SELECT查詢總數(shù)：

Com_select+Qcache_hits+ 解析錯誤的查詢數(shù)(queries

with errors found by parser)

其中，Com_select表示未命中緩存數(shù)，Qcache_hits表示緩存命中數(shù)

Com_select計算公式：

Qcache_inserts+Qcache_not_cached+權(quán)限檢查錯誤數(shù)(queries

with errors found during the column-privileges check)

索引監(jiān)控

SHOW

STATUS LIKE 'handler_read%';

輸出說明：

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)被讀取的次數(shù)，如果該值很高，那表明服務(wù)器正在執(zhí)行很多全索引掃描，例如

SELECT col1 FROM foo, 假設(shè)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.

基于某個鍵讀取一行的請求次數(shù)。如果該值很高，那很好的說明了，對于執(zhí)行的請求，表采用了適當(dāng)?shù)乃饕?/p>

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.

根據(jù)鍵順序，讀取下一行的請求次數(shù)。如果你正在查詢一個帶一系列約束的索引列或者正在執(zhí)行索引掃描時，該值會增加

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

根據(jù)鍵的順序，請求讀取前一行的次數(shù)。該讀取方法主要用于優(yōu)化 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.

在固定位置讀取一行的請求次數(shù)。該值如果很高，那么說明正在執(zhí)行許多要求對結(jié)果集排序的查詢。可能在執(zhí)行有許多要求全表掃描的查詢，或沒使用適合鍵的聯(lián)合查詢。

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.

讀取數(shù)據(jù)文件中下一行的請求次數(shù)。該值很高，表明正在執(zhí)行很多全表掃描。通常表明表沒使用適當(dāng)?shù)乃饕蛘卟樵冋埱鬀]利用現(xiàn)成的索引。

參考連接：

參考連接：

總結(jié)

以上是生活随笔為你收集整理的mysql 缓存监控_MySql 缓存查询原理与缓存监控 和 索引监控的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。