[[233746]]

一、引言

MySQL數(shù)據(jù)庫(kù)自問(wèn)世以來(lái)，就因它的體積小、速度快、低成本等優(yōu)勢(shì)受到眾多企業(yè)的追捧。同時(shí)由于它的完全開(kāi)源特性，更增進(jìn)了廣大數(shù)據(jù)庫(kù)愛(ài)好者對(duì)其深入研究的興趣，通過(guò)源碼的研究與探索，MySQL越來(lái)越多的優(yōu)秀特性被廣泛挖掘出來(lái)。

本文將圍繞MySQL table-cache相關(guān)參數(shù)進(jìn)行相應(yīng)的源碼解讀及性能分析，旨在為使用MySQL的眾多數(shù)據(jù)庫(kù)工程師提供一些實(shí)際開(kāi)發(fā)或運(yùn)維工作的助益。

二、參數(shù)源碼解讀

table-cache相關(guān)參數(shù)具體包括：

• open_files_limit；
• max_connections；
• table_open_cache；
• table_definition_cache。

MySQL實(shí)例進(jìn)程在啟動(dòng)時(shí)會(huì)根據(jù)配置文件my.cnf中對(duì)這四個(gè)參數(shù)的設(shè)置進(jìn)行自適應(yīng)的調(diào)整生效，由于MySQL在設(shè)置這四個(gè)參數(shù)時(shí)存在嚴(yán)格的順序和依賴關(guān)系，故將它們放在一起分析討論。

首先看一下源碼中關(guān)于這四個(gè)參數(shù)的自適應(yīng)關(guān)系函數(shù)（源碼位于MySQLd.cc），該函數(shù)在main函數(shù)中被調(diào)用，內(nèi)部分別調(diào)用了各自的設(shè)置函數(shù)。 

void adjust_related_options(ulong *requested_open_files)  
{  
 …  
adjust_open_files_limit(requested_open_files);  
adjust_max_connections(*requested_open_files);  
adjust_table_cache_size(*requested_open_files);  
adjust_table_def_size();  
}    

由于這四個(gè)設(shè)置函數(shù)存在嚴(yán)格的順序調(diào)用關(guān)系，下文將依次對(duì)各個(gè)函數(shù)進(jìn)行拆分說(shuō)明。

1、open_files_limit

該參數(shù)作用為限定了MySQL實(shí)例進(jìn)程能打開(kāi)的文件描述符最大值。關(guān)于該參數(shù)設(shè)置函數(shù)的聲明： 

void adjust_open_files_limit(ulong *requested_open_files) 

函數(shù)中的參數(shù)requested_open_files為指針變量，這是一個(gè)貫穿前后的指針，它指向的內(nèi)存中所存儲(chǔ)的內(nèi)容將會(huì)被后續(xù)函數(shù)多次用到。 

limit_1= 10 + max_connections + table_cache_size * 2;  
limit_2= max_connections * 5;  
limit_3= open_files_limit ? open_files_limit : 5000;  
request_open_files= max<ulong>(max<ulong>(limit_1, limit_2), limit_3);  

由于該參數(shù)首先被設(shè)置，所以這部分計(jì)算邏輯所取用的變量均來(lái)自配置文件中的設(shè)置值（源碼中的table_cache_size對(duì)應(yīng)配置文件中的table_open_cache），根據(jù)計(jì)算后得出的limit_1,2,3將取最大值存放在變量request_open_files中。

PS：此處需注意的是，request_open_files和requested_open_files是不同的。 

effective_open_files= my_set_max_open_files(request_open_files);  
open_files_limit= effective_open_files;  

隨后，函數(shù)my_set_max_open_files會(huì)以request_open_files作為參數(shù)，來(lái)計(jì)算effective_open_files的值。此函數(shù)中的計(jì)算邏輯會(huì)根據(jù)不同的系統(tǒng)環(huán)境選擇不同分支，但因本文的分析和測(cè)試均針對(duì)服務(wù)器，故以Linux分支為主。

不同的分支計(jì)算邏輯略有不同，在Linux環(huán)境下，函數(shù)中會(huì)調(diào)用系統(tǒng)函數(shù)getrlimit和setrlimit來(lái)獲取系統(tǒng)資源的最大使用量，在系統(tǒng)允許范圍內(nèi)，計(jì)算所得到的effective_open_files的值與request_open_files的值相等。筆者所用測(cè)試物理機(jī)測(cè)得的系統(tǒng)允許上限值為1024*1024。

此外，另一個(gè)可能影響effective_open_files數(shù)值的是MySQL實(shí)例的啟動(dòng)方式:

• 若MySQL實(shí)例在非root下啟動(dòng)，則effective_open_files的值會(huì)受到系統(tǒng)對(duì)于單進(jìn)程句柄的限制，即命令ulimit –n得到的值；
• 若在root下啟動(dòng)實(shí)例，則不會(huì)受到系統(tǒng)對(duì)單進(jìn)程的限制。

計(jì)算后所得的effective_open_files的值會(huì)賦給open_files_limit，作為實(shí)例中最終生效的實(shí)際參數(shù)。

概括來(lái)講，在未達(dá)到最大值時(shí)，計(jì)算所得的effective_open_files 與request_open_files 值相等，并將effective_open_files的最終值賦給open_files_limit；若超過(guò)最大值則effective_open_files會(huì)以配置文件中的open_files_limit設(shè)置值生效，若配置文件中設(shè)置也超限，則取系統(tǒng)對(duì)單進(jìn)程文件描述符的限制做生效值。為了更清晰的說(shuō)明此處邏輯，筆者進(jìn)行了以下對(duì)比測(cè)試。

為了便于更直觀的看清測(cè)試結(jié)果，我們更改系統(tǒng)單進(jìn)程文件描述符限制為56789，更改系統(tǒng)對(duì)全局文件描述符限制為655350。然后分別使用下列三種配置文件啟動(dòng)實(shí)例：

配置一：配置文件中設(shè)置open_files_limit值為1040000。

使用非root用戶啟動(dòng)MySQL實(shí)例，進(jìn)入數(shù)據(jù)庫(kù)查看變量生效值：

此時(shí)是以系統(tǒng)對(duì)單進(jìn)程文件描述符限制生效的。

關(guān)閉實(shí)例進(jìn)程，使用root用戶啟動(dòng)MySQL實(shí)例，再次進(jìn)入數(shù)據(jù)庫(kù)查看變量生效值：

此時(shí)則以配置文件中的設(shè)置值生效。

配置二：配置文件中設(shè)置table_open_cache=520000，open_files_limit=655350。

在root用戶下啟動(dòng)實(shí)例，可以看到此條件下可以按照配置文件生效：

隨后，更改配置文件中設(shè)置table_open_cache=530000，open_files_limit不變，在root用戶下重啟實(shí)例，觀察變量生效情況：

  

產(chǎn)生變化的原因是根據(jù)修改的table_open_cache值計(jì)算所得的effective_open_files會(huì)超出系統(tǒng)允許的上限，故MySQL會(huì)使用配置文件中的設(shè)置生效，并重新計(jì)算table_open_cache的值。 

配置三：配置文件設(shè)置table_open_cache=530000，open_files_limit=1049000。 

在root用戶下重啟實(shí)例，觀察變量生效情況：

 

此時(shí)由于計(jì)算所得的effective_open_files和配置文件中的open_files_limit設(shè)置值均超限，故使用系統(tǒng)對(duì)單進(jìn)程文件描述符限制作為生效值，并進(jìn)一步計(jì)算得到實(shí)際的table_open_cache。 

讓我們回到源碼中繼續(xù)解讀。在設(shè)置了open_files_limit生效值后，MySQL源碼中通過(guò)封裝C語(yǔ)言的標(biāo)準(zhǔn)輸出函數(shù)實(shí)現(xiàn)了自己的輸出函數(shù)，并在一定條件下向error.log中輸入相應(yīng)信息。  

if (effective_open_files < request_open_files)  
{  
  if (open_files_limit == 0)  
  {  
    sql_print_warning("Changed limits: max_open_files: %lu (requested %lu)", effective_open_files, request_open_files);  
  }  
  else  
  {  
    sql_print_warning("Could not increase number of max_open_files to "  
"more than %lu (request: %lu)", effective_open_files, request_open_files);  
  }  
} 

 

根據(jù)源碼邏輯，當(dāng)effective_open_files小于request_open_files的值時(shí)，error.log中就會(huì)記錄相應(yīng)信息。同時(shí)又根據(jù)配置文件中是否設(shè)置了open_files_limit的值來(lái)輸出不同內(nèi)容的錯(cuò)誤信息。以前文配置一為例，非root用戶啟動(dòng)MySQL計(jì)算所得的effective_open_files小于request_open_files，查看error.log中的信息有如下內(nèi)容：

 

對(duì)于root用戶啟動(dòng)，由于比較條件不滿足，則無(wú)相應(yīng)信息輸出。    

if (requested_open_files) 
 
equested_open_files= min<ulong>(effective_open_files, request_open_files); 

 

函數(shù)體的最后在effective_open_files和request_open_files中取小值放在了指針requested_open_files所指的內(nèi)存中，以便于后續(xù)函數(shù)對(duì)該變量的調(diào)用。 

2、max_connections 

該參數(shù)限制了MySQL實(shí)例允許的最大連接數(shù)，在數(shù)據(jù)庫(kù)的維護(hù)工作中相較于其他參數(shù)也更容易直觀的接觸到，下面讓我們看一下在源碼中是如何對(duì)這個(gè)參數(shù)進(jìn)行設(shè)置及生效的。    

 

void adjust_max_connections(ulong requested_open_files) 

此函數(shù)中的參數(shù)requested_open_files變量值即為前文函數(shù)中requested_open_files指針變量所指內(nèi)容。關(guān)于max_connections的計(jì)算邏輯則相對(duì)簡(jiǎn)單。 

 

limit= requested_open_files - 10 - TABLE_OPEN_CACHE_MIN * 2;  
if (limit < max_connections)  
  {  
    sql_print_warning("Changed limits: max_connections: %lu (requested %lu)",limit, max_connections);  
    max_connections= limit; 
  } 

 

首先根據(jù)算式計(jì)算limit變量的值，此處用到的TABLE_OPEN_CACHE_MIN是在頭文件sql_const.h中定義的宏定義變量，值為400。 

隨后將limit的值與配置文件中設(shè)定的max_connections進(jìn)行比較，若limit較小，則向error.log中輸出一串提示信息，并以limit作為最終生效值；若limit較大，則直接以配置文件的設(shè)置值生效，同時(shí)不打印提示信息。以下為操作實(shí)例： 

設(shè)置配置文件中max_connections值為5000，其他配置沿用前文。以非root用戶啟動(dòng)MySQL實(shí)例，在數(shù)據(jù)庫(kù)中查看max_connections的值：

 

此時(shí)max_connections按照配置文件中的設(shè)置進(jìn)行生效，原因在于非root用戶啟動(dòng)實(shí)例，requested_open_files取系統(tǒng)限定的effective_open_files值為56789，計(jì)算limit=56789-10-400*2=55979，該值遠(yuǎn)大于5000，故取較小值即配置文件中的設(shè)置值生效。 

保持同樣的條件不變，僅更改配置文件中的max_connections設(shè)置值為60000大于55979，使用非root用戶重啟MySQL實(shí)例，再次查看max_connections生效值，已經(jīng)更新為預(yù)期的55979了。

 

3、table_open_cache 

此參數(shù)規(guī)定了內(nèi)存中允許打開(kāi)表的數(shù)量，從它的作用可以看出，當(dāng)MySQL在處理查詢請(qǐng)求時(shí)，table_open_cache將會(huì)起到較大作用，有效設(shè)置并使用此參數(shù)可以降低熱點(diǎn)表的頻繁開(kāi)關(guān)動(dòng)作，從而改善性能。關(guān)于該參數(shù)設(shè)置的源碼如下：  

void adjust_table_cache_size(ulong requested_open_files)  
     limit= max<ulong>((requested_open_files - 10 - max_connections) / 2,  
                    TABLE_OPEN_CACHE_MIN);  
     if (limit < table_cache_size)  
    {  
    sql_print_warning("Changed limits: table_open_cache: %lu (requested %lu)",limit, table_cache_size);  
    table_cache_size= limit;  
    } 

 

對(duì)比max_connections的實(shí)現(xiàn)函數(shù)可以看出，兩個(gè)函數(shù)的內(nèi)部結(jié)構(gòu)相似，都是以requested_open_files為參數(shù)，根據(jù)各自的邏輯計(jì)算出limit變量的值，并將其與配置文件中的設(shè)置值比較，取更小的值作為最終生效值。需要注意的是，table_open_cache在源碼文件sys_vars.cc中被限定了取值范圍(0,512*1024)，這個(gè)范圍會(huì)對(duì)table_open_cache的實(shí)際生效值產(chǎn)生影響。下面看一些配置實(shí)例： 

設(shè)置配置文件中table_open_cache=30000，max_connections=5000，在非root用戶下啟動(dòng)實(shí)例。 

此模式下，requested_open_files=56789,max_connections生效值5000，算式(requested_open_files - 10 - max_connections) / 2值為25889>400，故limit=25889，同時(shí)小于配置文件中的設(shè)置值，故最終生效值應(yīng)為25889。在數(shù)據(jù)庫(kù)中查看變量的實(shí)際生效值：

 

結(jié)果符合預(yù)期。 

保持其他條件不變，更改配置文件中table_open_cache值為20000，再用非root用戶重啟實(shí)例，此時(shí)limit值仍為25889，但已大于配置文件中的設(shè)置值，故生效值應(yīng)為20000。到數(shù)據(jù)庫(kù)中查看實(shí)際生效值驗(yàn)證。

 

4、table_definition_cache 

此參數(shù)乍一看很容易與table_open_cache相混淆，畢竟這對(duì)“孿生兄弟”從生效到功能都有相近之處。table_definition_cache定義了內(nèi)存中可打開(kāi)的表結(jié)構(gòu)數(shù)量。此參數(shù)的設(shè)置函數(shù)與前列很大的一個(gè)不同點(diǎn)是沒(méi)有使用requested_open_files作為參數(shù)，僅僅聲明了一個(gè)無(wú)參函數(shù)： 

 

void adjust_table_def_size() 

此參數(shù)的設(shè)置算式僅使用了已生效的table_open_cache作為計(jì)算變量。 

 

default_value= min<ulong> (400 + table_cache_size / 2, 2000); 

table_open_cache函數(shù)中有一個(gè)很值得關(guān)注的點(diǎn)，在函數(shù)體內(nèi)涉及了MySQL動(dòng)態(tài)哈希鏈表的訪問(wèn)。這個(gè)鏈表是MySQL在啟動(dòng)主函數(shù)中定義并且用來(lái)存放部分系統(tǒng)變量的動(dòng)態(tài)鏈表，下面我們來(lái)詳細(xì)了解一下函數(shù)內(nèi)部的訪問(wèn)流程。 

首先函數(shù)體內(nèi)定義了一個(gè)系統(tǒng)變量類型的指針var，隨后調(diào)用函數(shù)訪問(wèn)哈希表，并將定位到的內(nèi)存塊賦值給類對(duì)象var。 

 

var= intern_find_sys_var(STRING_WITH_LEN("table_definition_cache")); 

此處STRING_WITH_LEN()是一個(gè)宏定義，返回內(nèi)容為對(duì)應(yīng)字符串本身及長(zhǎng)度。我們到intern函數(shù)內(nèi)部看一下： 

 

var=(sys_var*)my_hash_search(&system_variable_hash,(uchar*) str, length ? length : strlen(str));  
return var; 

 

intern函數(shù)內(nèi)部調(diào)用my_hash_search函數(shù)查找table_definition_cache字符串在哈希鏈表中對(duì)應(yīng)的結(jié)點(diǎn)，并將找到的位置返回類對(duì)象指針var。在找到var指針的目標(biāo)結(jié)點(diǎn)后，table_definition_cache設(shè)置主函數(shù)就把前面計(jì)算所得到的值寫(xiě)入var所指向的內(nèi)存。 

 

var->update_default(default_value); 

值得注意的是，即便函數(shù)已將計(jì)算結(jié)果賦給目標(biāo)結(jié)點(diǎn)，但函數(shù)依然會(huì)首先判斷配置文件中是否設(shè)置了table_definition_cache的值。若配置文件中未設(shè)置，則以計(jì)算所得的結(jié)果作為生效值；若配置文件中有對(duì)應(yīng)設(shè)置，則優(yōu)先以配置文件中的設(shè)置生效。 

 

if (! table_definition_cache_specified)  
_def_size= default_value; 

 

另一個(gè)需要注意的是雖然MySQL默認(rèn)配置文件中設(shè)置的table_definition_cache優(yōu)先生效，但在頭文件sql_const.h中宏定義了table_definition_cache的下限值為400，故即便在配置文件中設(shè)置了一個(gè)很小的值，MySQL也會(huì)自動(dòng)將生效值上調(diào)為下限值。下面看一些對(duì)應(yīng)的配置實(shí)例： 

我們選擇前例中requested_open_files=56789，max_connections=5000，table_open_cache=25889的條件進(jìn)行測(cè)試。 

首先，我們?cè)谂渲梦募性O(shè)置table_definition_cache=35486并將其注釋，保存文件。 

重啟MySQL實(shí)例，令修改的配置文件生效。根據(jù)前面對(duì)源碼的分析，計(jì)算公式default_value= min<ulong> (400 + table_cache_size / 2, 2000)=2000，此時(shí)配置文件中的設(shè)置無(wú)效，應(yīng)以計(jì)算結(jié)果生效。進(jìn)入數(shù)據(jù)庫(kù)中查看生效值：

 

然后修改配置文件，取消table_definition_cache的相關(guān)注釋，保存配置文件并重啟實(shí)例，到數(shù)據(jù)庫(kù)中查看生效值：

 

此時(shí)已按照配置文件設(shè)置生效。 

最后為驗(yàn)證MySQL對(duì)table_definition_cache下限的自適應(yīng)調(diào)整，我們修改配置文件中的對(duì)應(yīng)值為table_definition_cache=15并保存，重啟，再次進(jìn)入數(shù)據(jù)庫(kù)查看生效值：

 

可以看到，生效值已被MySQL自適應(yīng)調(diào)整為源碼中宏定義的下限值。 

至此，上文已完成對(duì)table_cache相關(guān)的源碼分析內(nèi)容，當(dāng)我們?cè)趯?shí)際工作中需要調(diào)整相關(guān)參數(shù)，可以參考前文并配置?，F(xiàn)在讓我們進(jìn)一步思考，在知曉了這些參數(shù)間的關(guān)聯(lián)和配置方法后，如何設(shè)置相應(yīng)的值才算合理？這些參數(shù)對(duì)MySQL的實(shí)際使用性能又會(huì)有多大的影響？下文將會(huì)對(duì)這部分內(nèi)容進(jìn)行測(cè)試分析。 

三、 參數(shù)性能影響及測(cè)試分析 

上文介紹了table-cache相關(guān)參數(shù)在MySQL數(shù)據(jù)庫(kù)正常運(yùn)轉(zhuǎn)過(guò)程中存在至關(guān)重要的作用，但并不是每個(gè)參數(shù)的微調(diào)都會(huì)對(duì)性能產(chǎn)生顯著的影響，以下將對(duì)它們逐一進(jìn)行說(shuō)明。 

嚴(yán)格來(lái)講，open_files_limit和max_connections對(duì)MySQL的重要性并非體現(xiàn)在性能方面。 

對(duì)于open_files_limit來(lái)說(shuō)，不合理的設(shè)置將會(huì)直接導(dǎo)致MySQL實(shí)例down掉或在啟動(dòng)時(shí)根本無(wú)法正常拉起進(jìn)程。對(duì)于這些場(chǎng)景，MySQL會(huì)有簡(jiǎn)單直接的錯(cuò)誤信息來(lái)提示DBA需要進(jìn)行相應(yīng)的調(diào)整。 

對(duì)于max_connections來(lái)說(shuō)，設(shè)置過(guò)大可能會(huì)對(duì)其它參數(shù)的生效產(chǎn)生影響，設(shè)置過(guò)小又無(wú)法滿足業(yè)務(wù)高峰時(shí)的連接需求，從而造成大量的連接等待和超時(shí)。通常根據(jù)實(shí)際情況設(shè)置在能夠滿足業(yè)務(wù)峰值的大小即可。 

基于上述原因，這兩個(gè)參數(shù)的性能影響在此不做深入探討，而把重點(diǎn)放在對(duì)另外兩個(gè)參數(shù)的測(cè)試及分析。 

1、table_definition_cache(TDC) 

本節(jié)對(duì)TDC可能產(chǎn)生的性能影響進(jìn)行測(cè)試分析。使用的MySQL測(cè)試版本為5.7.18，測(cè)試服務(wù)器為單實(shí)例單庫(kù)，庫(kù)中共建立40000張表，每張表內(nèi)5000行數(shù)據(jù)。測(cè)試條件為保證其他參數(shù)一致的前提下分別設(shè)置TDC=10000和TDC=50000進(jìn)行對(duì)比。 

首先比較兩種場(chǎng)景下全局變量的區(qū)別，分別修改配置文件中TDC設(shè)置值為10000和50000，再分別重啟實(shí)例，查看相關(guān)全局變量如下： 

• TDC=10000

 

• TDC=50000

 

 

通過(guò)對(duì)比可以看出，重啟后兩種場(chǎng)景的TDC生效值分別已達(dá)到預(yù)期的10000和50000。同時(shí)，我們?cè)诖颂帉?duì)比另外一個(gè)變量open_table_definitions，這個(gè)變量表示在當(dāng)前狀態(tài)下打開(kāi)的表結(jié)構(gòu)數(shù)量，兩種場(chǎng)景下在MySQL實(shí)例剛剛重啟后由于TDC的不同，打開(kāi)的表結(jié)構(gòu)數(shù)量是不同的： 

• TDC=10000的場(chǎng)景下打開(kāi)的表結(jié)構(gòu)數(shù)量被限制在10000；
• TDC=50000的場(chǎng)景下實(shí)例中的表結(jié)構(gòu)全部被打開(kāi)（其中有40000張測(cè)試表+219張系統(tǒng)表）。 

對(duì)比結(jié)果說(shuō)明當(dāng)TDC生效值大于庫(kù)中全表數(shù)量時(shí)，實(shí)例啟動(dòng)時(shí)會(huì)將所有表結(jié)構(gòu)加載到內(nèi)存；當(dāng)TDC生效值小于庫(kù)中全表數(shù)量時(shí)，MySQL會(huì)按照TDC的生效值加載相應(yīng)數(shù)量的表結(jié)構(gòu)到內(nèi)存。 

隨后我們來(lái)比較TDC的差別是否會(huì)對(duì)性能產(chǎn)生影響。測(cè)試使用sysbench工具模擬客戶端向服務(wù)器發(fā)送請(qǐng)求，申請(qǐng)?jiān)L問(wèn)的表數(shù)量為35000，連接并發(fā)數(shù)為50，連接發(fā)送請(qǐng)求持續(xù)時(shí)間為5min，使用以上測(cè)試模式分別測(cè)試TDC=10000和TDC=50000兩條件下四種基本SQL語(yǔ)句的qps，對(duì)比結(jié)果如下：

 

從測(cè)試結(jié)果對(duì)比可以看出，不同的TDC對(duì)MySQL基準(zhǔn)性能的影響并不大。那么導(dǎo)致這樣的因素是什么？ 

我們查看兩個(gè)測(cè)試后全局狀態(tài)變量open_table_definitions的值進(jìn)行對(duì)比： 

• TDC=10000

 

• TDC=50000

  

通過(guò)比較可以發(fā)現(xiàn)，雖然TDC設(shè)置值為10000的模式無(wú)法在啟動(dòng)實(shí)例時(shí)將所有表結(jié)構(gòu)都加載入內(nèi)存，但在實(shí)際請(qǐng)求到達(dá)服務(wù)器時(shí)，MySQL允許在內(nèi)存中“超載”TDC定義的表結(jié)構(gòu)數(shù)量，這就使得實(shí)例當(dāng)前已打開(kāi)的表結(jié)構(gòu)數(shù)量可超過(guò)TDC的限定值。同時(shí)，對(duì)于單一表來(lái)說(shuō)，重復(fù)訪問(wèn)并不會(huì)增加表結(jié)構(gòu)的打開(kāi)次數(shù)。因此，TDC對(duì)于性能的影響便不是很大了。 

2、table_open_cache（TOC） 

本節(jié)測(cè)試TOC可能產(chǎn)生的性能影響。使用的MySQL版本及測(cè)試庫(kù)環(huán)境與TDC測(cè)試相同。首先比較兩種不同TOC對(duì)性能帶來(lái)的影響。根據(jù)前文，使用root和非root用戶啟動(dòng)實(shí)例會(huì)導(dǎo)致open_files_limit的生效值有區(qū)別，進(jìn)而影響TOC的生效值。本例在配置文件中設(shè)置TOC值為350000，再分別使用root及非root用戶啟動(dòng)實(shí)例，觀察實(shí)際生效值如下： 

• root用戶啟動(dòng)：

 

 

  

• 非root用戶啟動(dòng)：

 

 

  

由于TOC決定了內(nèi)存中打開(kāi)表的數(shù)量，功能上對(duì)查詢SQL的影響更為明顯，故使用sysbench僅發(fā)送select語(yǔ)句并統(tǒng)計(jì)qps，申請(qǐng)?jiān)L問(wèn)的表數(shù)量是35000，訪問(wèn)持續(xù)時(shí)間為5min。更改不同的連接并發(fā)數(shù)分別測(cè)試qps并繪制成折線圖，結(jié)果如下：

 

從曲線圖可以看出，TOC較大（=350000）的條件下，查詢語(yǔ)句的qps隨并發(fā)數(shù)增加變化比較明顯，整體呈現(xiàn)先迅速上升后平穩(wěn)回落的趨勢(shì)，在64-128并發(fā)范圍內(nèi)達(dá)到高峰。反觀TOC較?。?30262）的模式下qps隨并發(fā)數(shù)的增加無(wú)明顯變化，而且持續(xù)處于較低水平。 

為了更加清晰的分析TOC對(duì)性能的影響，我們統(tǒng)計(jì)了每個(gè)并發(fā)下獨(dú)立測(cè)試的緩存命中率并繪制成曲線進(jìn)行比較：

 

比較二者命中率曲線可以看出，TOC較大的模式下，緩存命中率隨并發(fā)數(shù)的變化趨勢(shì)與qps曲線基本一致，雖然存在一定的波動(dòng)，但整體命中率均在99%以上，這時(shí)我們可以判定緩存的效率是較高的；但TOC較小的模式下，緩存命中率在不同并發(fā)數(shù)下普遍較差（低于50%），同時(shí)隨并發(fā)數(shù)的增加還有急速下降的趨勢(shì)。    

我們?cè)俳y(tǒng)計(jì)一下各個(gè)并發(fā)測(cè)試下的table_open_cache_overflows的值繪制成曲線并觀察：

 

從曲線圖可以看出，TOC較大的模式下overflow值非常?。ɑ緸?），這與該模式下緩存命中率較高的結(jié)果相吻合；但TOC較小的模式下則存在較大的overflow，這說(shuō)明該模式下較小的緩存無(wú)法滿足大量的并發(fā)訪問(wèn)請(qǐng)求，緩存不得不持續(xù)將新表刷入內(nèi)存。 

四、總結(jié) 

通過(guò)本文對(duì)table-cache相關(guān)源碼的分析及對(duì)比測(cè)試，我們可以得出一些相關(guān)結(jié)論： 

• open_files_limit，max_connections， table_open_cache， table_definition_cache四個(gè)參數(shù)在MySQL實(shí)例啟動(dòng)時(shí)依次生效，且相互存在制約關(guān)系，若需要單獨(dú)更改某一變量，要注意可能產(chǎn)生的影響；
• open_files_limit參數(shù)的生效會(huì)受到不同啟動(dòng)方式的影響進(jìn)而影響其它參數(shù)的生效值，設(shè)置時(shí)要按需選擇；
• open_files_limit和max_connections參數(shù)對(duì)性能影響較小，設(shè)置時(shí)可滿足業(yè)務(wù)量需求即可，二者更多影響的是MySQL實(shí)例的正常運(yùn)作；
• table_definition_cache參數(shù)對(duì)性能影響較小；
• table_open_cache參數(shù)對(duì)實(shí)際性能影響較大，但生效值需要在上下限間合理設(shè)置，為盡可能發(fā)揮cache性能，生效值應(yīng)設(shè)置為大并發(fā)下可維持較高命中率的同時(shí)不發(fā)生緩存overflow。 

以上是本文全部?jī)?nèi)容，希望讀到此文的廣大前輩和同行能夠積極提出文中的不足并不吝指正。