接下來(lái)這篇是查詢優(yōu)化，用戶80%的操作基本都在查詢汤求，我們有什么理由不去優(yōu)化他呢俏险？？所以這篇博客將會(huì)講解大量的查詢優(yōu)化（索引以及庫(kù)表結(jié)構(gòu)優(yōu)化等高級(jí)用法后面文章再講）扬绪，先講單表查優(yōu)化竖独，再講多表查優(yōu)化。

本系列：demo下載

（一）MySQL優(yōu)化筆記（一）--庫(kù)與表基本操作以及數(shù)據(jù)增刪改

（二）MySQL優(yōu)化筆記（二）--查找優(yōu)化（1）（非索引設(shè)計(jì)）

（三）MySQL優(yōu)化筆記（二）--查找優(yōu)化（2）（外連接挤牛、多表聯(lián)合查詢以及查詢注意點(diǎn)）

（四） MySQL優(yōu)化筆記（三）--索引的使用莹痢、原理和設(shè)計(jì)優(yōu)化

（五） MySQL優(yōu)化筆記（四）--表的設(shè)計(jì)與優(yōu)化（單表、多表）

（六）MySQL優(yōu)化筆記（五）--數(shù)據(jù)庫(kù)存儲(chǔ)引擎

（七）MySQL優(yōu)化筆記（六）--存儲(chǔ)過(guò)程和存儲(chǔ)函數(shù)

（八）MySQL優(yōu)化筆記（七）--視圖應(yīng)用詳解

（九） MySQL優(yōu)化筆記（八）--鎖機(jī)制超詳細(xì)解析（鎖分類、事務(wù)并發(fā)竞膳、引擎并發(fā)控制）

文章結(jié)構(gòu)：（1）明確搜索優(yōu)化的整體思路以及查詢優(yōu)化的因素航瞭；（2）優(yōu)化查詢前的幾個(gè)工具說(shuō)明；（3）單表查詢步步優(yōu)化坦辟；

文章目錄：

（1）明確搜索優(yōu)化的整體思路以及查詢優(yōu)化的因素

• 搜索優(yōu)化的整體思路
• 查詢優(yōu)化的因素思路
  - 是否向數(shù)據(jù)庫(kù)請(qǐng)求了不需要的數(shù)據(jù)
  - mysql是否掃描額外的紀(jì)錄
  - 查詢方式
  - 一個(gè)復(fù)雜查詢 or 多個(gè)簡(jiǎn)單查詢
  - 切分查詢
  - 分解關(guān)聯(lián)查詢
• 查詢的流程（站在后端開發(fā)者角度）沧奴。

（2）優(yōu)化查詢前的幾個(gè)工具說(shuō)明

• 查看MySQL整體狀態(tài)
• 開啟慢查詢?nèi)罩?br> - 在配置文件my.cnf或my.ini中在[mysqld]一行下面加入兩個(gè)配置參數(shù)
  - 查看日志啟動(dòng)狀態(tài)
  - 設(shè)置慢日志開啟
  - 查詢long_query_time 的值
  - 為了方便測(cè)試，可以將修改慢查詢時(shí)間為3秒
  - 以后就往我們?cè)O(shè)置的日志路徑去訪問(wèn)日志即可
• explain查詢分析
• profiling查詢分析

（3）單表查詢步步優(yōu)化：（暫不討論索引长窄，在下篇文章再詳解索引）

• 明確需要的字段滔吠，要多少就寫多少字段
• 使用分頁(yè)語(yǔ)句：limit start , count 或者條件 where子句
• 如果是有序的查詢，可使用ORDER BY
• 開啟查詢緩存
• 建立索引（下篇博客再詳講）

數(shù)據(jù)庫(kù)文件依然是： 數(shù)據(jù)庫(kù)文件挠日，這篇主要看商品表

一疮绷、明確搜索優(yōu)化的整體思路以及查詢優(yōu)化的因素：

（1）搜索優(yōu)化的整體思路：

索引優(yōu)化，查詢優(yōu)化嚣潜，查詢緩存冬骚，服務(wù)器設(shè)置優(yōu)化，操作系統(tǒng)和硬件優(yōu)化懂算，應(yīng)用層面優(yōu)化（web服務(wù)器只冻，緩存）等等。對(duì)于一個(gè)整體項(xiàng)目而言只有這些齊頭并進(jìn)计技，才能實(shí)現(xiàn)mysql高性能喜德。

（2）查詢優(yōu)化的因素思路：

[一]是否向數(shù)據(jù)庫(kù)請(qǐng)求了不需要的數(shù)據(jù)。

也就是說(shuō)不要輕易使用select * from 垮媒，能明確多少數(shù)據(jù)就查多少個(gè)

[二]mysql是否掃描額外的紀(jì)錄

查詢是否掃描了過(guò)多的數(shù)據(jù)舍悯。最簡(jiǎn)單的衡量查詢開銷三個(gè)指標(biāo)如下：響應(yīng)時(shí)間；掃描的行數(shù)睡雇；返回的行數(shù)萌衬。

沒(méi)有哪個(gè)指標(biāo)能夠完美地衡量查詢的開銷，但它們大致反映了mysql在內(nèi)部執(zhí)行查詢時(shí)需要多少數(shù)據(jù)它抱，并可以推算出查詢運(yùn)行的時(shí)間秕豫。

這三個(gè)指標(biāo)都會(huì)記錄到mysql的慢日志中，所以檢查慢日志記錄是找出掃描行數(shù)過(guò)多的查詢的好辦法观蓄。

響應(yīng)時(shí)間：是兩個(gè)部分之和：服務(wù)時(shí)間和排隊(duì)時(shí)間混移。服務(wù)時(shí)間是指數(shù)據(jù)庫(kù)處理這個(gè)查詢真正花了多長(zhǎng)時(shí)間。 排隊(duì)時(shí)間是指服務(wù)器因?yàn)榈却承┵Y源而沒(méi)有真正執(zhí)行查詢的時(shí)間蜘腌。---可能是等io操作完成沫屡，也可能是等待行鎖，等等撮珠。

掃描的行數(shù)和返回的行數(shù)：分析查詢時(shí)沮脖，查看該查詢掃描的行數(shù)是非常有幫助的金矛。這在一定程度上能夠說(shuō)明該查詢找到需要的數(shù)據(jù)的效率高不高。

掃描的行數(shù)和訪問(wèn)類型：　在expain語(yǔ)句中的type列反應(yīng)了訪問(wèn)類型勺届。訪問(wèn)類型有很多種驶俊，從全表掃描（ALL）到索引掃描（index）到范圍掃描（）到唯一索引查詢到常數(shù)引用等。這里列的這些免姿，速度由慢到快饼酿，掃描的行數(shù)也是從大到小。

如果發(fā)現(xiàn)查詢需要掃描大量的數(shù)據(jù)但只返回少數(shù)的行胚膊，那么通彻世可以嘗試下面的技巧去優(yōu)化它：

使用索引覆蓋掃描。

改變庫(kù)表結(jié)構(gòu)紊婉。例如使用單獨(dú)的匯總表药版。

重寫這個(gè)復(fù)雜的查詢。讓mysql優(yōu)化器能夠以更優(yōu)化的方式執(zhí)行這個(gè)查詢喻犁。

[三]查詢方式：

1. 一個(gè)復(fù)雜查詢 or 多個(gè)簡(jiǎn)單查詢

設(shè)計(jì)查詢的時(shí)候一個(gè)需要考慮的重要問(wèn)題是槽片，是否需要將一個(gè)復(fù)雜的查詢分成多個(gè)簡(jiǎn)單的查詢。

2.切分查詢

有時(shí)候?qū)τ谝粋€(gè)大查詢我們需要“分而治之”肢础，將大查詢切分為小查詢还栓，每個(gè)查詢功能完全一樣，只完成一小部分传轰，每次只返回一小部分查詢結(jié)果剩盒。

3.分解關(guān)聯(lián)查詢

分解關(guān)聯(lián)查詢

    select * from tag 

　　　　　　　join tag_post on tag_post.tag_id = tag.id

　　　　　　　join post on tag_post.post_id = post.id

　　　　where tag.tag = 'mysql'

　　　　可以分解成下面這些查詢來(lái)代替：

　　　　> select * from tag where tag = 'mysql'

　　　　> select * from tag_post where tag_id = 1234

　　　　> select * from post where post_id in (123, 456, 567, 9098, 8904)　　　　
　　　　

讓緩存的效率更高。

將查詢分解后路召，執(zhí)行單個(gè)查詢可以減少鎖的競(jìng)爭(zhēng)勃刨。

在應(yīng)用層做關(guān)聯(lián)，可以更容易對(duì)數(shù)據(jù)庫(kù)進(jìn)行拆分股淡，更容易做到高性能和可擴(kuò)展。

查詢本身效率也可能會(huì)有所提升廷区。

可以減少冗余記錄的查詢唯灵，

更進(jìn)一步，這樣做相當(dāng)于在應(yīng)用中實(shí)現(xiàn)了哈希關(guān)聯(lián)隙轻，而不是使用mysql的嵌套循環(huán)關(guān)聯(lián)埠帕。

（3）查詢的流程（站在后端開發(fā)者角度）：摘自此博主此文章

這里寫圖片描述

1.客戶端發(fā)送一條查詢給服務(wù)器

2.服務(wù)器先檢查查詢緩存，如果命中了緩存玖绿，則立刻返回存儲(chǔ)在緩存中的結(jié)果敛瓷，否則進(jìn)入下一階段。

3.服務(wù)器進(jìn)行SQL解析斑匪，預(yù)處理呐籽，再由優(yōu)化器生成對(duì)應(yīng)的執(zhí)行計(jì)劃，

4.mysql根據(jù)優(yōu)化器生成的執(zhí)行計(jì)劃，調(diào)用存儲(chǔ)引擎的API來(lái)執(zhí)行查詢狡蝶。

5.將結(jié)果返回給客戶端庶橱。

二、優(yōu)化查詢前的幾個(gè)工具說(shuō)明：

（1）查看MySQL整體狀態(tài)：

1. Mysql> show status; ——顯示狀態(tài)信息（擴(kuò)展show status like ‘XXX’）

2. Mysql>show variables ——顯示系統(tǒng)變量（擴(kuò)展show variables like ‘XXX’）

3. Mysql>show innodb status ——顯示InnoDB存儲(chǔ)引擎的狀態(tài)

4. Mysql>show processlist ——查看當(dāng)前SQL執(zhí)行贪惹，包括執(zhí)行狀態(tài)苏章、是否鎖表等

5. Shell> mysqladmin variables -u username -p password——顯示系統(tǒng)變量

6. Shell> mysqladmin extended-status -u username -p password——顯示狀態(tài)信息

7. Shell> mysqld –verbose –help [|more #逐行顯示] 查看狀態(tài)變量及幫助：

（2）開啟慢查詢?nèi)罩荆?/h3>

這里寫圖片描述

1. 在配置文件my.cnf或my.ini中在[mysqld]一行下面加入兩個(gè)配置參數(shù)

log-slow-queries={自己想存放的日志路徑}/slow-query.log

long_query_time=2

注：log-slow-queries參數(shù)為慢查詢?nèi)罩敬娣诺奈恢茫话氵@個(gè)目錄要有mysql的運(yùn)行帳號(hào)的可寫權(quán)限奏瞬，一般都將這個(gè)目錄設(shè)置為mysql的數(shù)據(jù)存放目錄枫绅；

long_query_time=2中的2表示查詢超過(guò)兩秒才記錄；

在my.cnf或者my.ini中添加log-queries-not-using-indexes參數(shù)硼端，表示記錄下沒(méi)有使用索引的查詢并淋。

log-slow-queries=/data/mysqldata/slow-query.log

long_query_time=10

log-queries-not-using-indexes

2. 查看日志啟動(dòng)狀態(tài)：show variables like "slow%";

這里寫圖片描述

3. 設(shè)置慢日志開啟: set global slow_query_log = ON;

這里寫圖片描述

4. 查詢long_query_time 的值 ：

show variables like "long%";

5. 為了方便測(cè)試，可以將修改慢查詢時(shí)間為3秒显蝌。（小點(diǎn)容易比較预伺，畢竟mysql處理那么快）

這里寫圖片描述

6.以后就往我們?cè)O(shè)置的日志路徑去訪問(wèn)日志即可：

more  slow.log

（3）explain查詢分析：

使用 EXPLAIN 關(guān)鍵字可以模擬優(yōu)化器執(zhí)行SQL查詢語(yǔ)句，從而知道MySQL是如何處理你的SQL語(yǔ)句的曼尊。這可以幫你分析你的查詢語(yǔ)句或是表結(jié)構(gòu)的性能瓶頸酬诀。通過(guò)explain命令可以得到:

表的讀取順序

數(shù)據(jù)讀取操作的操作類型

哪些索引可以使用

哪些索引被實(shí)際使用

表之間的引用

每張表有多少行被優(yōu)化器查詢

這里寫圖片描述

EXPLAIN查詢出來(lái)的字段解析：

？Table：顯示這一行的數(shù)據(jù)是關(guān)于哪張表的

骆撇？possible_keys：顯示可能應(yīng)用在這張表中的索引瞒御。如果為空，沒(méi)有可能的索引神郊‰热梗可以為相關(guān)的域從WHERE語(yǔ)句中選擇一個(gè)合適的語(yǔ)句

？key：實(shí)際使用的索引涌乳。如果為NULL蜻懦，則沒(méi)有使用索引。MYSQL很少會(huì)選擇優(yōu)化不足的索引夕晓，此時(shí)可以在SELECT語(yǔ)句中使用USE INDEX（index）來(lái)強(qiáng)制使用一個(gè)索引或者用IGNORE INDEX（index）來(lái)強(qiáng)制忽略索引

宛乃？key_len：使用的索引的長(zhǎng)度。在不損失精確性的情況下蒸辆，長(zhǎng)度越短越好

征炼？ref：顯示索引的哪一列被使用了，如果可能的話躬贡，是一個(gè)常數(shù)

谆奥？rows：MySQL認(rèn)為必須檢索的用來(lái)返回請(qǐng)求數(shù)據(jù)的行數(shù)

？type：這是最重要的字段之一拂玻，顯示查詢使用了何種類型酸些。從最好到最差的連接類型為system宰译、const、eq_reg擂仍、ref囤屹、range、index和ALL

nsystem逢渔、const：可以將查詢的變量轉(zhuǎn)為常量. 如id=1; id為 主鍵或唯一鍵.

neq_ref：訪問(wèn)索引,返回某單一行的數(shù)據(jù).(通常在聯(lián)接時(shí)出現(xiàn)肋坚，查詢使用的索引為主鍵或惟一鍵)

nref：訪問(wèn)索引,返回某個(gè)值的數(shù)據(jù).(可以返回多行) 通常使用=時(shí)發(fā)生

nrange：這個(gè)連接類型使用索引返回一個(gè)范圍中的行，比如使用>或<查找東西肃廓，并且該字段上建有索引時(shí)發(fā)生的情況(注:不一定好于index)

nindex：以索引的順序進(jìn)行全表掃描智厌，優(yōu)點(diǎn)是不用排序,缺點(diǎn)是還要全表掃描

nALL：全表掃描，應(yīng)該盡量避免

盲赊？Extra：關(guān)于MYSQL如何解析查詢的額外信息铣鹏，主要有以下幾種

nusing index：只用到索引,可以避免訪問(wèn)表.

nusing where：使用到where來(lái)過(guò)慮數(shù)據(jù). 不是所有的where clause都要顯示using where. 如以=方式訪問(wèn)索引.

nusing tmporary：用到臨時(shí)表

nusing filesort：用到額外的排序. (當(dāng)使用order by v1,而沒(méi)用到索引時(shí),就會(huì)使用額外的排序)

nrange checked for eache record(index map:N)：沒(méi)有好的索引.

（4）profiling查詢分析：

通過(guò)慢日志查詢可以知道哪些SQL語(yǔ)句執(zhí)行效率低下，通過(guò)explain我們可以得知SQL語(yǔ)句的具體執(zhí)行情況哀蘑，索引使用等诚卸，還可以結(jié)合show命令查看執(zhí)行狀態(tài)。

如果覺(jué)得explain的信息不夠詳細(xì)绘迁，可以同通過(guò)profiling命令得到更準(zhǔn)確的SQL執(zhí)行消耗系統(tǒng)資源的信息合溺。

profiling默認(rèn)是關(guān)閉的∽禾ǎ可以通過(guò)以下語(yǔ)句查看： select @@profiling;

這里寫圖片描述

打開profiling查詢分析：set profiling = 1;

這里寫圖片描述

然后我們隨便寫幾條select語(yǔ)句棠赛，再查看：show profiles\G;

這里寫圖片描述

mysql> show profiles\G; 可以得到被執(zhí)行的SQL語(yǔ)句的時(shí)間和ID

mysql>show profile for query 1; 得到對(duì)應(yīng)SQL語(yǔ)句執(zhí)行的詳細(xì)信息

Show Profile命令格式：

SHOW PROFILE [type [, type] … ]                                    

    [FOR QUERY n]                                                            

    [LIMIT row_count [OFFSET offset]]        



type參數(shù)：                                                                                 

  |ALL                                                                               

  | BLOCK IO                                                                      

  | CONTEXT SWITCHES                                                   

  | CPU                                                                              

  | IPC                                                                                

  | MEMORY                                                                            

  | PAGE FAULTS                                                               

  | SOURCE                                                                        

  | SWAPS                              

以上的16rows是針對(duì)非常簡(jiǎn)單的select語(yǔ)句的資源信息，對(duì)于較復(fù)雜的SQL語(yǔ)句膛腐，會(huì)有更多的行和字段睛约，比如converting HEAP to MyISAM 、Copying to tmp table等等哲身，由于以上的SQL語(yǔ)句不存在復(fù)雜的表操作辩涝，所以未顯示這些字段。通過(guò)profiling資源耗費(fèi)信息勘天，我們可以采取針對(duì)性的優(yōu)化措施膀值。

測(cè)試完畢以后 ，關(guān)閉參數(shù)：mysql> set profiling=0

三误辑、單表查詢步步優(yōu)化：（暫不討論索引，在下篇文章再詳解索引）

（我們繼續(xù)看上面所用的商品表）

//最傻的查詢方式
select * from commodity_list

（1）明確需要的字段歌逢，要多少就寫多少字段：

select  d.Good_ID ,
        d.Classify_ID,
        d.Good_Name,
        d.Monthsale_Num,
        d.Store_Name,
        d.Comment_Num,
        d.Good_Brand,
        d.Ishas_License,
        ifnull(d.Good_Hot,0),
        d.Good_Price,
        d.Store_Add,
        d.Store_Age,
        d.Seller_Credit,
        d.Classify_Description
        from
        Commodity_list d;

（2）使用分頁(yè)語(yǔ)句：limit start , count 或者條件 where子句

有什么可限制的條件盡量加上巾钉，查一條就limit一條。做到不多拿不亂拿秘案。

明確子句的執(zhí)行順序先：

SELECT select_list　　　
FROM table_name　　
[ WHERE search_condition ]　　
[ GROUP BY group_by_expression ]　　
[ HAVING search_condition ]　　
[ ORDER BY order_expression [ ASC | DESC ] ]
[limit m,n]

例子：

select
        d.Good_ID ,
        d.Classify_ID,
        d.Good_Name,
        d.Monthsale_Num,
        d.Store_Name,
        d.Comment_Num,
        d.Good_Brand,
        d.Ishas_License,
        ifnull(d.Good_Hot,0),
        d.Good_Price,
        d.Store_Add,
        d.Store_Age,
        d.Seller_Credit,
        d.Classify_Description
        from
        Commodity_list d
        where Classify_ID=23
        limit 1,10000
        ;

補(bǔ)充：

1）limit語(yǔ)句的查詢時(shí)間與起始記錄的位置成正比

2）mysql的limit語(yǔ)句是很方便砰苍，但是對(duì)記錄很多的表并不適合直接使用潦匈。

對(duì)limit分頁(yè)性能優(yōu)化分析：

偏移量越大，查詢?cè)劫M(fèi)時(shí)赚导。

原因：

• 每條數(shù)據(jù)的實(shí)際存儲(chǔ)長(zhǎng)度不一樣（所以必須要依次遍歷茬缩，不能直接跳過(guò)前面的一部分）
• 哪怕是每條數(shù)據(jù)存儲(chǔ)長(zhǎng)度一樣，如果之前有過(guò)delete操作吼旧，那索引上的排列就有g(shù)ap
• 所以數(shù)據(jù)不是定長(zhǎng)存儲(chǔ)凰锡，不能像數(shù)組那樣用index來(lái)訪問(wèn)，只能依次遍歷圈暗，就導(dǎo)致偏移量越大查詢?cè)劫M(fèi)時(shí)

**對(duì)limit的使用再優(yōu)化 **：

利用自增主鍵掂为，避免offset的使用（演示在積分表score，商品表設(shè)計(jì)得不太好）员串，約是上面方法的1/3時(shí)間勇哗。

select *
        from
        score 
        WHERE id>0 LIMIT 10000
        ;
select *
        from
        score 
        WHERE id>10000 LIMIT 10000
        ;
select *
        from
        score 
        WHERE id>20000 LIMIT 10000
        ;
        
        ......

（3）如果是有序的查詢，可使用ORDER BY

select *
        from
        score 
        WHERE id>0
        ORDER BY score ASC
        LIMIT 10000
        ;

（4）開啟查詢緩存：部分摘自此博主此博客

大多數(shù)的MySQL服務(wù)器都開啟了查詢緩存寸齐。這是提高性最有效的方法之一欲诺。當(dāng)有很多相同的查詢被執(zhí)行了多次的時(shí)候，這些查詢結(jié)果會(huì)被放到一個(gè)緩存中渺鹦，這樣扰法，后續(xù)的相同的查詢就不用操作表而直接訪問(wèn)緩存結(jié)果了。

命中緩存條件：

1）緩存存在一個(gè)hash表中,通過(guò)查詢SQL,查詢數(shù)據(jù)庫(kù),客戶端協(xié)議等作為key.在判斷是否命中前,MySQL不會(huì)解析SQL,而是直接使用SQL去查詢緩存,SQL任何字符上的不同,如空格,注釋,都會(huì)導(dǎo)致緩存不命中.

2）如果查詢中有不確定數(shù)據(jù),例如CURRENT_DATE()和NOW()函數(shù),那么查詢完畢后則不會(huì)被緩存.所以,包含不確定數(shù)據(jù)的查詢是肯定不會(huì)找到可用緩存的

工作流程：

1）服務(wù)器接收SQL,以SQL和一些其他條件為key查找緩存表(額外性能消耗)

2）如果找到了緩存,則直接返回緩存(性能提升)

3）如果沒(méi)有找到緩存,則執(zhí)行SQL查詢,包括原來(lái)的SQL解析,優(yōu)化等.

4）執(zhí)行完SQL查詢結(jié)果以后,將SQL查詢結(jié)果存入緩存表(額外性能消耗)

緩存使用的時(shí)機(jī)：（并不是每個(gè)情況使用緩存都是好的）

衡量打開緩存是否對(duì)系統(tǒng)有性能提升是一個(gè)整體的概念海铆。

1）通過(guò)緩存命中率判斷, 緩存命中率 = 緩存命中次數(shù) (Qcache_hits) / 查詢次數(shù) (Com_select)迹恐、

2）通過(guò)緩存寫入率, 寫入率 = 緩存寫入次數(shù) (Qcache_inserts) / 查詢次數(shù) (Qcache_inserts)

3）通過(guò) 命中-寫入率 判斷, 比率 = 命中次數(shù) (Qcache_hits) / 寫入次數(shù) (Qcache_inserts), 高性能MySQL中稱之為比較能反映性能提升的指數(shù),一般來(lái)說(shuō)達(dá)到3:1則算是查詢緩存有效,而最好能夠達(dá)到10:1

緩存參數(shù)配置：

1）query_cache_type: 是否打開緩存：

可選項(xiàng)：OFF: 關(guān)閉；ON: 總是打開卧斟；DEMAND: 只有明確寫了SQL_CACHE的查詢才會(huì)吸入緩存

2）query_cache_size: 緩存使用的總內(nèi)存空間大小,單位是字節(jié),這個(gè)值必須是1024的整數(shù)倍,否則MySQL實(shí)際分配可能跟這個(gè)數(shù)值不同(感覺(jué)這個(gè)應(yīng)該跟文件系統(tǒng)的blcok大小有關(guān))

3）query_cache_min_res_unit: 分配內(nèi)存塊時(shí)的最小單位大小

4）query_cache_limit: MySQL能夠緩存的最大結(jié)果,如果超出,則增加 Qcache_not_cached的值,并刪除查詢結(jié)果

5）query_cache_wlock_invalidate: 如果某個(gè)數(shù)據(jù)表被鎖住,是否仍然從緩存中返回?cái)?shù)據(jù),默認(rèn)是OFF,表示仍然可以返回

6）緩存的一些整體參數(shù)：

Qcache_free_blocks: 緩存池中空閑塊的個(gè)數(shù)

Qcache_free_memory: 緩存中空閑內(nèi)存量

Qcache_hits: 緩存命中次數(shù)

Qcache_inserts: 緩存寫入次數(shù)

Qcache_lowmen_prunes: 因內(nèi)存不足刪除緩存次數(shù)

Qcache_not_cached: 查詢未被緩存次數(shù),例如查詢結(jié)果超出緩存塊大小,查詢中包含可變函數(shù)等

Qcache_queries_in_cache: 當(dāng)前緩存中緩存的SQL數(shù)量

Qcache_total_blocks: 緩存總block數(shù)

減少碎片策略：

1）選擇合適的block大小

2）使用 FLUSH QUERY CACHE 命令整理碎片.這個(gè)命令在整理緩存期間,會(huì)導(dǎo)致其他連接無(wú)法使用查詢緩存

PS: 清空緩存的命令式 RESET QUERY CACHE

InnoDB與查詢緩存：

Innodb會(huì)對(duì)每個(gè)表設(shè)置一個(gè)事務(wù)計(jì)數(shù)器,里面存儲(chǔ)當(dāng)前最大的事務(wù)ID.當(dāng)一個(gè)事務(wù)提交時(shí),InnoDB會(huì)使用MVCC中系統(tǒng)事務(wù)ID最大的事務(wù)ID跟新當(dāng)前表的計(jì)數(shù)器.

只有比這個(gè)最大ID大的事務(wù)能使用查詢緩存,其他比這個(gè)ID小的事務(wù)則不能使用查詢緩存.

另外,在InnoDB中,所有有加鎖操作的事務(wù)都不使用任何查詢緩存

（5）建立索引（下篇博客再詳講）

源碼下載：工程以及數(shù)據(jù)庫(kù)文件下載

好了殴边，MySQL優(yōu)化筆記（二）--查找優(yōu)化（1）（非索引設(shè)計(jì)）講完了，由于篇幅太長(zhǎng)珍语，多表查詢只能放到下篇了锤岸，還有一些查詢的注意點(diǎn)也放到下一篇，我會(huì)繼續(xù)出這個(gè)系列文章板乙，分享經(jīng)驗(yàn)給大家是偷。歡迎在下面指出錯(cuò)誤，共同學(xué)習(xí)Ｄ汲选蛋铆！你的點(diǎn)贊是對(duì)我最好的支持！放接！

更多內(nèi)容刺啦，可以訪問(wèn)JackFrost的博客