mysql優化之連接優化(open-files-limit與table_open_cache）

 

 

MySQL打開的文件描述符限制

Can't open file: '.\test\mytable.frm' (errno: 24)

[root@localhost ~]# perror 24
OS error code  24:  Too many open files

 

這就是MySQL的文件描述不夠用了。先說解決辦法，再說背后的原因吧。

1. 如何解決

第一步：設置OS參數（如果你有權限的話）：

文件/etc/security/limits.conf新增如下行：

mysql soft nofile 65535
mysql hard nofile 65535

 

上面的配置，是OS限制各個用戶能夠打開的文件描述符限制（hard soft區別參看man ulimit），新增上面兩行，表示mysql用戶能夠打開65535個文件描述符

（可以使用lsof -u mysql|wc -l查看當前打開了多少個文件描述符）

[root@localhost ~]# lsof -u mysql|wc -l
63

 

第二步：修改MySQL參數：
在MySQL配置文件my.cnf中新增下面的行

open_files_limit = 65535
innodb_open_files=65535

innodb_open_files:

This variable is relevant only if you use multiple InnoDB tablespaces. It specifies the maximum number of .ibd files that MySQL can keep open at one time. The minimum value is 10. The default value is 300 if innodb_file_per_table is not enabled, and the higher of 300 and table_open_cache otherwise.

The file descriptors used for .ibd files are for InnoDB tables only. They are independent of those specified by the --open-files-limit server option, and do not affect the operation of the table cache.

open_files_limit ：

更改為 mysqld 的可用的文件描述符數量。你應該嘗試增加此選項的值，如果 mysqld 給你出的錯誤太多打開的文件。mysqld 使用選項值保留與 setrlimit() 的描述符。在內部，此選項的最大值是最大的無符號的整數值，但實際最大值是依賴於平台。如果無法分配請求的文件描述符數量，mysqld 向錯誤日志中寫入一個警告。

mysqld 可能嘗試分配更多請求的描述符 （如果可用），使用 max_connections 和 table_open_cache 的值來估計是否將需要更多的描述符數量。

在 Unix 上，設置的值不能小於 ulimit-n。

 

然后重啟你的MySQL一般問題就解決了。

2. 背后的問題

上面的辦法一般就能解決問題了。不過在實踐中發現，在my.cnf中設置的參數open_files_limit值是無效的，即MySQL啟動后open_files_limit始終以OS的文件描述符為准。（版本MySQL5.1.45 RHEL5.4）

mysql> show global variables like "%open_files_limit%"; 
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+
1 row in set (0.02 sec)

 

 

那my.cnf參數open_files_limit是否真的是沒用呢？接下來會是一篇很長、很蛋疼的關於該問題的研究，如果不是很有時間，不建議看下去。

3. 源代碼中如何設置open_files_limit

 

3.1 實驗驗證

配置文件中配置：open_files_limit = 10000；$ulimit -n 20000；啟動數據庫，觀察：

mysql> show global variables like "%open_files_limit%";
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+
1 row in set (0.03 sec)

/etc/security/limits.conf

*   soft nproc    65535
*   hard nproc    65535
*   soft nofile   65535
*   hard nofile   65535

 

看到參數open_files_limit確實沒有作用（已經實驗了很多次了）。limit -n 20000也沒有用，直接用 limits.conf值

 

連接優化

連接優化主要指客戶端連接數據庫以及數據庫為響應客戶端的請求而打開數據表和索引的過程中涉及到的參數調整。原文可以參考這里或者這里。(原文鏈接 http://ddbiz.com/?p=950)
盡管不同的mysql發行版本的編譯和鏈接方式也會影響到客戶端的鏈接請求，但是由於我的系統多是直接安裝mysql的發行包，且很少會做改動，因此關於手動編譯mysql的以達到優化的目的的方面，此處無法聊及，或許日后會有機會涉足其中。

根據MySQL如何使用內存中的說法，下面的參數會影響到客戶端的每個請求：

1. open-files-limit

   命令行參數: –open-files-limit=#
   ini/cnf參數: open-files-limit
   mysql 變量: open_files_limit
   全局變量，不可動態調整，取值范圍 0到65535。
   open_files_limit指mysql能夠打開的文件句柄數。該值不足時，會引發 Too many open files錯誤。具體需要多少個文件句柄，還需要根據 max_connections 和 table_open_cache來計算。

2. 
   一個有趣的現象是，在我的64bit linux中， –open-files-limit或者–open_files_limit可以設置超過 64k，如：

   open-files-limit可能受到操作系統的限制，比如linux中，/proc/sys/fs/file-max，就限制了系統最大能夠開啟的文件句柄數目。像oracle在linux的安裝運行要求，對最低要求就是要超過 64k. 可以通過修改/etc/sysctl.conf，增加或者修改 fs.file-max=#來增加系統最大打開值，別忘了修改完了，用 sysctl -p 來啟用新值(以上操作為centos/rhel)。
   在linux中，還有一個參數可能會限制系統最大打開文件數值，就是/etc/security/limits.conf
   
   具體如何修改其值，請參考系統文檔

   受如下參數影響: 受系統限制
   將影響如下參數: max_connections table_open_cache
   調整觸發條件: 當系統出現 Too many open files 時需要調整此參數。

3. thread_stack

   命令行參數: –thread_stack=#
   ini/cnf參數: thread_stack
   mysql 變量: thread_stack
   全局變量，不可動態調整。
   32bit系統中默認為192k, 64bit系統中默認為256k. 先談及thread_stack是因為他對下面要講的max_connections有關鍵影響因素。

   thread_stack 對應於操作系統層面中的stack size，windows中的默認線程的stack size為1M, linux根據版本不同會有變化，一般在8m或者10m。在我的幾個Centos 5.x/6.x中，默認的stack size 都是10M(這要比windows高出10倍)

   ulimit -s
   10240

    stack size在32bit的OS中是一個很重要的參數，減少一個線程的stack size可以增加線程數，比如從10m減少到64k。                                                                            但是在64bit的Linux（內核版本>= 2.6.x）中，如果允許 /proc/sys/vm/overcommit_memory，stack size或許沒那么重要了。

   受如下參數影響: 無
   將影響如下參數: max_connections
   調整觸發條件: max_connections 已經達到當前系統允許的最大值。

4. max_connections

   命令行參數: –max_connections 或者 –max-connections
   ini/cnf定義: max_connections
   mysql 變量: max_connections
   全局變量，可動態調整

   MySQL數據庫允許的並發連接數。
   對於一個訪問者眾多(pv值很高)的網站來說，有時可能會發生 : Too many connections 的錯誤。可以考慮增加此值。對於MySQL來說，能夠支持的最大的並發連接數，取決於很多因素，包括：

   1. 操作系統線程模型、操作系統版本(參見 thread_size)
   2. 可用的內存數量
   3. 每個連接的內存使用量/工作負載(參見 thread_size)
   4. 預期的服務器響應時間

   在內存允許的情況下,32bit windows可以支持最大2000左右的並發請求（因為單進程最大支持的內存為2G，而默認的一個線程需要資源為1MB），64bit windows 也可以根據內存計算得出可支持的線程數。（關於windows中可用線程估算，可以參考Mark Russinovich的文章Pushing the Limits of Windows: Processes and Threads，或者參考微軟的一篇簡述(進程地址空間)）。
   而Linux中的因素可能更復雜，不過 stack_size 依然如同windows中一樣，是制約線程數的一個重要因素，最大線程數在Liunx下也有默認值，cat /proc/sys/kernel/threads-max, 當不調整這個值時，MySQL的max_connections應該遠小於它。

   在實際應用中，可支持的並發數將會遠小於理論值，因為每個線程不可能只是空連接一下就斷開。線程工作時的CPU/內存損耗，會降低整個系統的可用資源調配。對於MySQL來說，其提供了一個可以調整stack size的參數: thread_stack.
   mysql 的 max_connections * thread_stack 應小於可用內存；根據mysql的官方文檔(doc5.5)，linux(或者solaris)下，可以支持500到1000個並發連接，如果每個連接的工作很小，且服務器內存很大的話，那么可以支持到10k的鏈接。在windows下，則有一個 (open tables*2+open connection) < 2048的限制。因此：

   受如下參數影響: thread_stack    table_open_cache     open_file_limit
   將影響如下參數: 無
   調整觸發條件: 當threads_connected（show status like ‘threads_connected’） 接近 max_connections 時，應該采取行動提高並發數.

5. thread_cache_size

   命令行參數: –thread_cache_size
   ini/cnf定義: thread_cache_size
   mysql 變量: thread_cache_size
   全局變量，可動態調整, 默認值0，最大值16k

   mysql使用此參數限定數據庫服務中，緩存多少個線程共客戶端使用。 如果服務器每秒都有幾百個新的連接出現，那么這個值應該挑高一些。通過評測connections和threads_created判定是否需要增加thread_cache_size.
   mysql> show status like ‘%connections%’; 輸出
   Connections 嘗試連接請求（包括不能成功建立連接的請求）
   Max_used_connections 最大並發連接數量

   mysql> show variables like "%connections%";
   +----------------------+-------+
   | Variable_name        | Value |
   +----------------------+-------+
   | max_connections      | 151   |
   | max_user_connections | 0     |
   +----------------------+-------+
   2 rows in set (0.02 sec)

   mysql> show status like ‘threads_c%’; 輸出

   threads_cached 當前緩存線程數
   threads_connected 當前連接數
   thread_created 線程創建數

   mysql> show status like "%threads_c%";
   +-------------------+-------+
   | Variable_name     | Value |
   +-------------------+-------+
   | Threads_cached    | 0     |
   | Threads_connected | 1     |
   | Threads_created   | 1     |
   +-------------------+-------+
   3 rows in set (0.03 sec)

    

   當連接緩存的利用率( thread cache hit =(connections – threads_created)/connections*100%） 的值較低時，表明mysql需要創建更多的線程（線程緩存不夠了）來接受客戶端請求。

   受如下參數影響: 無
   將影響如下參數: 無
   調整觸發條件: 當thread cache hit較低時，應該采取行動提高thread_cache_size此值.

6. table_open_cache/table_cache

   命令行參數: –table-open-cache
   ini/cnf定義: table_open_cache
   mysql 變量: table_open_cache
   全局變量，可動態調整, 默認值400，最大值512k

   mysql打開表的描述符，被緩存在table_open_cache中，table_open_cache >= max_connections * 2，這是因為有些表打開時，需要兩個文件符，如myisam表，另外還有index、臨時表等的文件符。自鏈接的查詢語句，會額外再多開啟一個該表的文件符。

   一個針對性的設置是，找到和數據庫有關的所有最復雜的查詢語句（包括自鏈接,left/right/outer join，以及group 等統計語句）查看這些鏈接將打開多少數據表，設定此值為 N，則

   table_open_cache > max_connections * N

   eg:
   mysql> show variables like "%table_open%";        表文件描述符===》線程描術符===》總打開文件描述符
   +----------------------------+-------+
   | Variable_name              | Value |
   +----------------------------+-------+
   | table_open_cache           | 2000  |
   | table_open_cache_instances | 1     |
   +----------------------------+-------+
   2 rows in set (0.02 sec)

    

   受如下參數影響: max_connections    open_file_limit
   將影響如下參數: max_connections
   調整觸發條件: 當opened_tables（show status like ‘opened_tables’）值很大時，應該采取行動提高table_open_cache此值.

7. net_buffer_length    

   命令行參數: –net_buffer_length
   ini/cnf定義: net_buffer_length
   mysql 變量: thread_cache_size
   全局變量，可動態調整, 默認值16k，范圍1k到1m.

   客戶端連接時的緩沖和結果緩沖, 可以動態調整（自動調整，意味着 set net_buffer_length=xxx是無效的）到最大max_allowed_packet的大小。每個SQL語句結束后，這個值會恢復到初始值。內存不足時–這個情況也很少了，畢竟現在內存這么便宜–或者並發連接很大時，可以適當的縮小這個初始值，比如1k.

   受如下參數影響: max_allowed_packet
   將影響如下參數: 無
   調整觸發條件: 如果要裝載/導入/導出大量數據時；查詢結果中包含大的數據字段時，如TEXT,BLOB等

8. max_allowed_packet

   命令行參數: –max_allowed_packet
   ini/cnf定義: max_allowed_packet
   mysql 變量: max_allowed_packet
   全局變量，可動態調整, 默認值1m，范圍1k到1g.

   客戶端和服務端的max_allowed_packet需要一致，或者客戶端的max_allowed_packet要大於服務端的max_allowed_packet。

   受如下參數影響: 無
   將影響如下參數: 無
   調整觸發條件: 如果要裝載/導入/導出大量數據時；查詢結果中包含大的數據字段時，如TEXT,BLOB等

   Q:max_allowed_packet和net_buffer_length會影響load data infile嗎？
   A:No 

9. wait_timeout

   命令行參數: –wait_timeout
   ini/cnf定義: wait_timeout
   mysql 變量: wait_timeout
   全局變量，可動態調整, 默認值8小時，范圍1秒到31536000.
   wait_timeout定義了一個已連接的客戶端在不進行任何查詢動作時最常的空閑時間。
   注意：對已經建立的連接將不產生影響。
   可以通過 show processlist 來查看當前數據庫連接的狀況，如：
   

   受如下參數影響:
   將影響如下參數: max_connections
   調整觸發條件: 短鏈接、高並發的系統應用中.

 

 

《open/close table on mysql》 

我們知道mysql是一個支持多線程的數據庫，尤其在innodb存儲引擎出現后，對mysql的事務，並發，鎖支持得到了極大提高。在高並發的訪問的應用場景中，應用端大量並發的進程發問數據庫，而數據庫中的數據表在磁盤上以數據文件存放，在unix，linux的系統調用中，是依賴於文件描述符的。不同的os對文件描述符的限制不同（非Unix/linux 操作系統無文件描述符概念，在windows中稱作文件句柄），如在linux中/etc/security/limits.conf配置文件中設置他們的文件描述符極限。

在了解mysql打開表的過程前，需要了解一些知識：

table cache：對於不同的存儲引擎，table cache的作用是不同的，對於MyISAM表，每一個客戶端線程打開任何一個MyISAM表的數據文件都需要打開一個文件描述符，但如果是索引文件，則可以多個線程共享同一個索引文件的描述符，table cache的主要作用應該用於緩存文件描述符，當有新的請求時不需要重新的打開，使用結束時也不用立即關閉。

對於InnoDB的存儲引擎來說，打開表的方式與myisam是不同：

 

Unlike MyISAM Innodb does not have to keep open file descriptor when table is open – open table is purely logical state and appropriate .ibd file may be open or closed，InnoDB uses a single, global file descriptor for each .ibd file.

InnoDB has its own per-table cache, variously called a table definition cache or data dictionary, which you cannot configure.When InnoDB opens a table, it adds a corresponding object to the data dictionary. Each table can take up 4 KB or more of memory(although much less space is required in MySQL 5.1). Tables are not removed from the data dictionary when they are closed.

在引擎上，innodb把table cache 叫做了數據字典，表的定義都緩存在數據字典中（data dictionary），文件描述符上使用一個global file descriptor來處理每個ibd文件，如果使用的是共享表空間來存儲數據，則打開的文件描述符就比較少，但如果使用的是獨享表空間方式（innodb_file_per_table=1）則打開的文件描述符則較多。

知道了上面的知識后，來看下面的參數：

Table_cache：在MySQL 5.1.3版本中為table_open_cache，其默認值為64，官方文檔中對該參數的解釋為：

The number of open tables for all threads. Increasing this value increases the number of file descriptors thatmysqld requires.

所有threads打開表的數量，增加這個參數需要在mysqld啟動的時候增加文件描述符；

第一個問題：mysql是如何打開和關閉表的？

在官方文檔中描述的很清晰了：

MySQL is multi-threaded, so there may be many clients issuing queries for a given table simultaneously. To minimize the problem with multiple client sessions having different states on the same table, the table is opened independently by each concurrent session

Mysql在訪問一張表的時候，將其放入到cache中，如果數據庫中有許多的表，通常將其放入到cache中，對性能的提升帶來幫助。

那么在不斷的新表打開中，cache被慢慢填滿（table_open_cache—-full），如果新打開的表沒有在cache中，mysql會將一些沒有使用的table清除掉：

(1)

Session 1

mysql> show variables like "%table_open%";
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| table_open_cache           | 2000  |
| table_open_cache_instances | 1     |
+----------------------------+-------+

root@test 10:56:22>set global table_open_cache=2;

Query OK, 0 rows affected (0.00 sec)

 

root@test 11:07:50>flush tables;

Query OK, 0 rows affected (0.00 sec)

 

root@test 11:08:58>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 0     |

| Open_tables                    | 0     |

| Opened_table_definitions | 28   |

| Opened_tables                | 28   |

 

 

(2)

Sessioin 2：

root@test 10:56:03>select * from t1;

 

session 3：

root@test 10:56:03>select * from t2;

 

session 1：

root@test 11:09:17>show global status like ‘open%table%’;

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

| Variable_name                 | Value|

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

| Open_table_definitions     |  2    |

| Open_tables                    |  2    |

| Opened_table_definitions | 30   |

| Opened_tables                | 30   |

 

 

(3)

Session 4：

root@test 10:52:22>select * from t1;

 

Session1：

root@test 11:11:08>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 2     |

| Open_tables                    | 2     |

| Opened_table_definitions | 30    |

| Opened_tables                | 30    |

 

 

(4)

Session5：

root@test 10:52:39>select * from test_1;

Session1:

root@test 11:13:03>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 3     |

| Open_tables                    | 2     |

| Opened_table_definitions | 31   |

| Opened_tables                | 31   |

 

我們可以看到，第一步：session1： 開始cache中執行 flush tables后，open_tables為0，Open_table_definitions 為0；

第二步：Session2,3：執行兩個表的查詢，session1中查詢open_tables， Open_table_definitions 為2；

第三步：session 4:執行session2的查詢，session1中查詢open_tables， Open_table_definitions 沒有變，保持2；

第四步：session5：執行新的查詢，session中查詢open_tables為2，Open_table_definitions為3；

從實驗上看是滿足上述的情況的。

 

 

如果沒有table能夠被釋放，cache將會根據需要臨時擴展，當有table關閉或者unused，cache將會被釋放：

第一步：Session1： root@test 11:26:58>flush tables;

root@test 11:33:35>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 0     |

| Open_tables                    | 0     |

| Opened_table_definitions | 38    |

| Opened_tables                | 39    |

 

第二步：

Session2：

root@test 11:10:43>HANDLER t1 open;

session3

root@test 11:10:46>HANDLER t2 open;

 

第三步：session1

root@test 11:33:41>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 2     |

| Open_tables                    | 2     |

| Opened_table_definitions | 40    |

| Opened_tables                | 41    |

 

第四步：

session4：

root@test 11:10:49>select * from t3;

 

 

第五步：

Session1：

root@test 11:34:06>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 3     |

| Open_tables                    | 2     |

| Opened_table_definitions | 41    |

| Opened_tables                | 42    |

 

 

第六步：

Session5： root@test 11:29:59>HANDLER test_1 open;

 

第七步：

root@test 11:34:19>show global status like ‘open%table%’;

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

| Variable_name                | Value |

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

| Open_table_definitions     | 4     |

| Open_tables                    | 3     |

| Opened_table_definitions | 42    |

| Opened_tables                | 43    |

 

 

上面中有兩個參數：

Open_table_definitions

The number of cached .frm files. This variable was added in MySQL 5.1.3.

Open_tables

The number of tables that are open.

 

 

我們看到在使用HANDLER open打開表的時候，該table不會被mysql清出cache，當cache被填滿后，在使用HANDLER open，cache將會被擴展；直到使用handler close關閉后釋放。

那table_open_cache設為多少值合理，是不是越大table_open_cache參數設置會帶來性能的上的線性提升？當我們的數據庫中上千數量的表的時候，查詢中有涉及復雜的多表連接，並且同時有多個connection連到mysql中執行這些query，那么就可能很快用完文件描述符cache（table_open_cache），mysql使用LRU算法，把最近最少使用的描述符關閉掉，用於存放新的描述符。但是在查找要關閉的描述符中，查找時間會隨着cache中的緩存數量增加而增加（O(n),n為cache的items數量），文件打開的時間等於文件關閉的時間，從而導致了性能上的下降。

在官方文檔中對table_open_cache參數的設置限於對os的文件描述符的上，當然還一些相應內存開銷，通常在設置table_open_cache參數的時候，我們會在業務的高峰時期，檢查open_Tables的值，如果open_Tables的值與table_open_cache的值相等，並且opened_tales的值在不斷的增加，這個時候就需要對table_open_cache的值增加了；

set global table_open_cache=M；

root@test 01:25:00>show global status like ‘open%tables’;

+—————+———+

| Variable_name | Value   |

+—————+———+

| Open_tables     | 56       |

| Opened_tables | 2139150 |

 

 

第二個問題：os文件描述符對該參數的限制，

當我們在調整table_open_cache的時候，還需要考慮一個參數就是os的文件描述符，如果table_open_cache參數設置的很大，mysql有可能用完文件描述符，導致mysql拒絕其他連接請求，這時候就需要根據os的文件描述符限制來設置參數的值。

調整文件描述符：open_files_limit和open-files-limit這兩個參數：

官方文檔中告訴我們可以通過再mysqld_safe啟動中加入open-files-limit參數，mysqld_safe –open-files-limit=N,來改變open_files_limit值；

在配置文件中，我們也可以看到open_files_limit參數，但是如果你設置該參數，重啟主機后，該參數的值還是以系統的文件描述符為准，所以在安裝mysql的時候，在/etc/security/limits.conf配置好mysql用戶對最大打開文件數的限制，建議設置到最大：

Mysql soft nofiles 65535

Mysql hard nofiles 65535。

 

table_open_cache與max_connections與open_files_limit

 

一般來講:

table_open_cache = max_connections * N  ,N代表一個查詢中最多打開的表數量。

table_definition_cache = 設置足夠大。

對於open_files_limit，它代表同一時間點能打開的文件數上限，這里有兩篇文章：http://www.orczhou.com/index.php/2010/10/mysql-open-file-limit/，http://blog.csdn.net/fbjwying2/article/details/6323897，里面具體的說了open_files_limit與哪些因素有關。我這里只簡單說下我的理解。

open_files_limit的值取決於三個數值:open_files_limit,max_connections*5,10+max_connections+table_cache_size*2。真實值是這三個值的最大值。

有一種情況是上面得出的最大值超過了ulimit -n設置的值時，有可能通過show variables看到值卻不是真實的。因為運行於os里的進程最終會受到os的影響。所以最好就是設置ulimit -n 與 show variables like 'open_files_limit'里一樣。

show global 里的open_files表示當前此時此刻打開文件的數量，如果與open_files_limit非常接近，則就要提高open_files_limit的值。

show global 里的opened_tables表示已經打開表的數量，如果與table_open_cache非常接近，則就要提高table_open_cache的值。但不要一味的增加，還要看當前open_tables的值。

注意:show global 里 open_files 代表當前此時此刻打開的文件數，opened_files代表從服務最近一次啟動到現在打開的文件數。

open_tables 代表當前此時此刻打開的表，opened_tables代表從服務最近一次啟動到現在打開的表。

opened_tables -----> table_open_cache.

open_files       -----> open_files_limit.

出處： http://www.cnblogs.com/xuegang/

 

 

MYSQL性能優化

mysql> show variables like "table%";
+-------------------------+--------+
| Variable_name             | Value |
+-------------------------+--------+
| table_definition_cache  | 256    | 
| table_lock_wait_timeout    | 50     | 
| table_open_cache        | 1024   | 
| table_type                      | InnoDB | 
+-------------------------+--------+
4 rows in set (0.00 sec)

 

table_open_cache   ：mysql每打開一個表，都會讀入一些數據到table_open_cache 緩存 中

當mysql在這個緩存中找不到相應的信息時，才會去磁盤上直接讀取。

mysql> show status like "open%";
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| Open_files                   | 66       | 
| Open_streams               | 0        | 
| Open_table_definitions     | 135      | 
| Open_tables               | 302      | 
| Opened_files                 | 86399846 | 
| Opened_table_definitions | 0        | 
| Opened_tables               | 0        | 
+--------------------------+----------+
7 rows in set (0.00 sec)

 

 

Open_tables      當前打開的表數目 302 。table_open_cache   1024   。所有現在沒必要對緩存進行調整。

mysql> show variables like "thread%";
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    81208905
Current database: ZXX

+-------------------+---------------------------+
| Variable_name     | Value                             |
+-------------------+---------------------------+
| thread_cache_size | 64                               | 
| thread_handling        | one-thread-per-connection | 
| thread_stack            | 196608                         | 
+-------------------+---------------------------+
3 rows in set (0.04 sec)

每當客戶端連接到mysql數據庫，mysql數據庫就會創建以個線程為它服務

但是首先mysql回去thread_cache中尋找可用的線程，找不到才會創建新的線程

 

當前線程狀況：

mysql> show status like "thread%";
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 61    | 
| Threads_connected  | 3       | 
| Threads_created      | 2371 | 
| Threads_running      | 3     | 
+-------------------+-------+

 

 

參數說明：

table_open_cache(5.1以前版本為table_cache)
table_open_cache指定表高速緩存的大小。每當MySQL訪問一個表時，如果在表緩沖區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容

通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_open_cache的值。如果你發現open_tables等於table_open_cache，並且opened_tables在不斷增長，那么你就需要增加table_open_cache的值了

 

5.max_connections
最大連接數
6.back_bog
back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接，你需要增加它，換句話說，這值對到來的TCP/IP連接的偵聽隊列的大小.
7.thread_cache
mySQL里面為了提高客戶端請求創建連接過程的性能,提供了一個連接池也就是Thread_Cache池,將空閑的連接線程放在連接池中,而不是立即銷毀.這樣的好處就是,當又有一個新的請求的時候,mysql不會立即去創建連接線程,而是先去Thread_Cache中去查找空閑的連接線程,如果存在則直接使用,不存在才創建新的連接線程.
thread_cache_size
Thread_Cache中存放的最大連接線程數.在短連接的應用中Thread_Cache的功效非常明顯
thread_stack
每個連接被創建的時候,mysql分配給它的內存.這個值一般認為默認就可以應用於大部分場景了
thread_cache命中率計算
show variables like 'thread%';show status like '%connections%';show status like '%thread%'

公式為：thread_cache_hit=(connections-thread_create)/connections*100%