MySQL效能的五大配置引數(記憶體引數)
記憶體引數:
儲存引擎/共享
日誌緩衝區,緩衝區池
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_buffer_size
伺服器/共享
查詢調整快取
執行緒高速絡快取
query_cache
table_cahce
table_definition_cache
連線/會話
排序緩衝區,讀取緩衝區,臨時表
binlog_cache_size
read_buffer_size
read_rnd_buffer_size
join_buffer_size
sort_buffer_size
tmp_table_size
thread_cache_size
bulk_insert_buffer_size
net_buffer_length
thread_stack
下面轉載自:http://www.bitscn.com/pdb/mysql/201405/227583.html
*.執行緒獨享記憶體
*.全域性共享記憶體
全域性共享記憶體類似ORACLE的系統全域性區SGA,執行緒獨享記憶體類似ORACLE的程序全域性區PGA
一、執行緒獨享記憶體
在MySQL中,執行緒獨享記憶體主要用於各客戶端連線執行緒儲存各種操作的獨享資料,如執行緒棧資訊,分組排序操作,資料讀寫緩衝,結果集暫存等等,而且大多數可以通過相關引數來控制記憶體的使用量。
* 執行緒棧資訊使用記憶體(thread_stack):
主要用來存放每一個執行緒自身的標識資訊,如執行緒id,執行緒執行時基本資訊等等,我們可以通過 thread_stack 引數來設定為每一個執行緒棧分配多大的記憶體。
Global,No Dynamic,Default 192K(32bit), 256K(32bit),
推薦配置:預設
* 排序使用記憶體(sort_buffer_size):
MySQL 用此記憶體區域進行排序操作(filesort),完成客戶端的排序請求。當我們設定的排序區快取大小無法滿足排序實際所需記憶體的時候,MySQL會將資料寫入磁碟檔案來完成排序。由於磁碟和記憶體的讀寫效能完全不在一個數量級,
所以sort_buffer_size引數對排序操作的效能影響絕對不可小視。排序操作的實現原理請參考:MySQL Order By的實現分析。
什麼時候會用到?
對結果集排序時
使用確認:
可以通過查詢計劃中的Extra列的值為Using file-sort來證實使用了和這個緩衝區。
>explain select * from user1;
Global Session,Dynamic,Default 2M(32bit), 2M(32bit),
推薦配置:8M(記憶體足夠的情況下),預設(記憶體緊張的情況)
優化建議:一種說法是增大可以提高order by,group by效能,防止資料寫入磁碟佔用IO資源,還有一種說法是不推薦增加這個緩衝區的大小,理由是當值太大時可能會降低查詢的執行速度。目前我沒有實驗證實。
* Join操作使用記憶體(join_buffer_size):
應用程式經常會出現一些兩表(或多表)Join的操作需求,MySQL在完成某些Join需求的時候(all/index join),為了減少參與Join的“被驅動表”的讀取次數以提高效能,需要使用到Join Buffer來協助完成Join操作
(具體Join實現演算法請參考:MySQL中的 Join 基本實現原理)。當Join Buffer太小,MySQL 不會將該Buffer存入磁碟檔案,而是先將Join Buffer中的結果集與需要Join的表進行Join操作,然後清空Join Buffer中的資料,
繼續將剩餘的結果集寫入此Buffer中,如此往復。這勢必會造成被驅動表需要被多次讀取,成倍增加IO訪問,降低效率。
什麼時候會用到?
當查詢必須連線兩個表(或多個)的資料集並且不能使用索引時,這個緩衝區會被用到。這個緩衝區專門為每個執行緒的無索引連結操作準備的。
使用確認:
可以通過查詢計劃中的Extra列的值為Using join bufer來證實使用了和這個緩衝區。
>explain select * from user1;
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | user1 | index | NULL | name | 78 | NULL | 3 | Using index |
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
Global Session,Dynamic,Default 128K 各版本平臺最大值不一樣
推薦配置:8M(記憶體足夠的情況下),預設(記憶體緊張的情況)
優化建議:有一種說法是增加這個緩衝區的大小不會加快全連線操作的速度。目前我沒有實驗證實。
* 順序讀取資料緩衝區使用記憶體(read_buffer_size):
這部分記憶體主要用於當需要順序讀取資料的時候,如無法使用索引的情況下的全表掃描,全索引掃描等。在這種時候,MySQL按照資料的儲存順序依次讀取資料塊,每次讀取的資料快首先會暫存在read_buffer_size中,
當buffer空間被寫滿或者全部資料讀取結束後,再將buffer中的資料返回給上層呼叫者,以提高效率。
Global Session,Dynamic,Default 128K
推薦配置:4M/8M
* 隨機讀取資料緩衝區使用記憶體(read_rnd_buffer_size):
和順序讀取相反,當MySQL進行非順序讀取(隨機讀取)資料塊的時候,會利用這個緩衝區暫存讀取的資料。如根據索引資訊讀取表資料,根據排序後的結果集與表進行Join等等。
總的來說,就是當資料塊的讀取需要滿足一定的順序的情況下,MySQL就需要產生隨機讀取,進而使用到read_rnd_buffer_size 引數所設定的記憶體緩衝區。
Global Session,Dynamic,Default 256K
推薦配置:8M
* 連線資訊及返回客戶端前結果集暫存使用記憶體(net_buffer_lenth):
這部分用來存放客戶端連線執行緒的連線資訊和返回客戶端的結果集。當MySQL開始產生可以返回的結果集,會在通過網路返回給客戶端請求執行緒之前,會先暫存在通過net_buffer_lenth所設定的緩衝區中,
等滿足一定大小的時候才開始向客戶端傳送,以提高網路傳輸效率。不過net_buffer_lenth引數所設定的僅僅只是該快取區的初始化大小,MySQL會根據實際需要自行申請更多的記憶體以滿足需求,
但最大不會超過 max_allowed_packet 引數大小。
Global Session,Dynamic,Default 16K
推薦配置:預設 16K
* 批量插入暫存使用記憶體(bulk_insert_buffer_size):
當我們使用如 insert … values(…),(…),(…)… 的方式進行批量插入的時候,MySQL會先將提交的資料放如一個快取空間中,當該快取空間被寫滿或者提交完所有資料之後,MySQL才會一次性將該快取空間中的資料寫入資料庫並清空快取。
此外,當我們進行 LOAD DATA INFILE操作來將文字檔案中的資料Load進資料庫的時候,同樣會使用到此緩衝區。
Global Session,Dynamic,Default 8M
推薦配置:預設 8M
* 臨時表使用記憶體(tmp_table_size):
當我們進行一些特殊操作如需要使用臨時表才能完成的Order By,Group By 等等,MySQL可能需要使用到臨時表。當我們的臨時表較小(小於tmp_table_size 引數所設定的大小)的時候,MySQL會將臨時表建立成記憶體臨時表,
只有當tmp_table_size所設定的大小無法裝下整個臨時表的時候,MySQL才會將該表建立成MyISAM儲存引擎的表存放在磁碟上。不過,當另一個系統引數 max_heap_table_size 的大小還小於 tmp_table_size 的時候,
MySQL將使用 max_heap_table_size 引數所設定大小作為最大的記憶體臨時表大小,而忽略tmp_table_size 所設定的值。而且 tmp_table_size 引數從 MySQL 5.1.2 才開始有,之前一直使用 max_heap_table_size。
誰小誰生效.另外還有一個引數max_tmp_tables,沒有使用
tmp_table_size
Global Session,Dynamic,Default 16M
推薦配置:64M
max_heap_table_size
Global Session,Dynamic,Default 8M
This variable sets the maximum size to which user-created MEMORY tables are permitted to grow
這個變數定義了MEMORY儲存引擎表的最大容量。
This variable is also used in conjunction with tmp_table_size to limit the size of internal in-memory tables. See
這個變數也與tmp_table_size一起使用限制內部記憶體表的大小。請見
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
推薦配置:64M
主要根據業務以及伺服器記憶體來調整,如果有需要到則可以調整到。GB居然使用2G的配置,汗
目前沒有一個簡便的方式來確定內部臨時表的總容量。可以通過MySQL狀態變數created_tmp_tables和created_tmp_disk_tables來確定建立了臨時表和基於磁碟的臨時表
mysql> show global status like 'create%tables';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 0 |
+-------------------------+-------+
5.5中,可以使用PERFORMANCE—SCHEMA來幫助統計基於磁碟的臨時表的總大小
補充說明:上面所列舉的MySQL執行緒獨享記憶體僅僅只是所有執行緒獨享記憶體中的部分,並不是全部,只是這些可能對MySQL的效能產生較大的影響,且可以通過系統引數進行調節。
由於以上記憶體都是執行緒獨享,極端情況下的記憶體總體使用量將是所有連線執行緒的總倍數。所以在設定過程中一定要謹慎,切不可為了提升效能就盲目的增大各引數值,
避免因為記憶體不夠而產生Out Of Memory異常或者是嚴重的Swap交換反而降低整體效能。
二、全域性共享記憶體
儲存查詢快取的 Query Cache,
快取連線執行緒的 Thread Cache,
快取表文件控制代碼資訊的 Table Cache,
快取二進位制日誌的 BinLog Buffer,
快取MyISAM儲存引擎索引鍵的 Key Buffer
儲存InnoDB資料和索引的 InnoDB Buffer Pool
等等。下面針對 MySQL 主要的共享記憶體進行一個簡單的分析。
* MyISAM索引快取 Key Buffer(key_buffer_size):
MyISAM 索引快取將MyISAM表的索引資訊(.MYI檔案)快取在記憶體中,以提高其訪問效能。這個快取可以說是影響MyISAM儲存引擎效能的最重要因素之一了,通過 key_buffere_size 設定可以使用的最大記憶體空間。
注意:即使執行一個全部採用innodb的模式,仍需要定義一個索引碼緩衝區,因為MYSQL元資訊與MyISAM定義相同。
Global ,Dynamic,Default 8M
推薦配置:預設 8M
如何確認key_buffer_size不夠用?
使用show full proceslist的State列中,值Repairing the keycache是一個明顯的指標,它指出當前索引碼緩衝區大小不足以執行當前執行的SQL語句。這將導致額外的磁碟I/O開銷。
* 查詢快取 Query Cache (query_cache_size):
http://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
http://dev.mysql.com/doc/refman/5.5/en/query-cache-status-and-maintenance.html
查詢快取是MySQL比較獨特的一個快取區域,用來快取特定Query的結果集(Result Set)資訊,且共享給所有客戶端。通過對Query語句進行特定的Hash計算之後與結果集對應存放在Query Cache中,以提高完全相同的Query語句的相應速度。
當我們開啟MySQL的Query Cache之後,MySQL接收到每一個SELECT型別的Query之後都會首先通過固定的Hash演算法得到該Query的Hash值,然後到Query Cache中查詢是否有對應的Query Cache。如果有,則直接將Cache的結果集返回給客戶端。
如果沒有,再進行後續操作,得到對應的結果集之後將該結果集快取到Query Cache中,再返回給客戶端。當任何一個表的資料發生任何變化之後,與該表相關的所有Query Cache全部會失效,所以Query Cache對變更比較頻繁的表並不是非常適用,
但對那些變更較少的表是非常合適的,可以極大程度的提高查詢效率,如那些靜態資源表,配置表等等。為了儘可能高效的利用Query Cache,MySQL針對Query Cache設計了多個query_cache_type值
和兩個Query Hint:SQL_CACHE和SQL_NO_CACHE。當query_cache_type設定為0(或者 OFF)的時候不使用Query Cache,當設定為1(或者 ON)的時候,當且僅當Query中使用了SQL_NO_CACHE 的時候MySQL會忽略Query Cache,
當query_cache_type設定為2(或者DEMAND)的時候,當且僅當Query中使用了SQL_CACHE提示之後,MySQL才會針對該Query使用Query Cache。可以通過query_cache_size來設定可以使用的最大記憶體空間。
Global Dynamic,Default 0
推薦配置:16M
如何確定系統query cache的情況?
show global status like 'Qcache%';或者
select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'Qcache%';
公式:
(Qcache_hits/Qcache_hits+Com_select+1)*100來確定查詢快取的有效性
mysql> show variables like 'query_cache_size';
+------------------+----------+
| Variable_name | Value |
+------------------+----------+
| query_cache_size | 16777216 |
+------------------+----------+
1 row in set (0.00 sec)
mysql> show global status like 'Qcache%';
+-------------------------+------------+
| Variable_name | Value |
+-------------------------+------------+
| Qcache_free_blocks | 535 |
| Qcache_free_memory | 4885448 |
| Qcache_hits | 1858574835 |
| Qcache_inserts | 1619931831 |
| Qcache_lowmem_prunes | 802889469 |
| Qcache_not_cached | 825000679 |
| Qcache_queries_in_cache | 4411 |
| Qcache_total_blocks | 9554 |
+-------------------------+------------+
8 rows in set (0.00 sec)
mysql> show global status like 'Com_select';
+---------------+------------+
| Variable_name | Value |
+---------------+------------+
| Com_select | 2445037535 |
+---------------+------------+
1 row in set (0.00 sec)
* 連線執行緒快取 Thread Cache(thread_cache_size):
連線執行緒是MySQL為了提高建立連線執行緒的效率,將部分空閒的連線執行緒保持在一個快取區以備新進連線請求的時候使用,這尤其對那些使用短連線的應用程式來說可以極大的提高建立連線的效率。
當我們通過thread_cache_size設定了連線執行緒快取池可以快取的連線執行緒的大小之後,可以通過(Connections - Threads_created) / Connections * 100% 計算出連線執行緒快取的命中率。
注意,這裡設定的是可以快取的連線執行緒的數目,而不是記憶體空間的大小。
Global,Dynamic,Default 0
推薦配置:8個
如何確定系統Thread Cache的情況?
mysql> show global status like 'Threads_created';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Threads_created | 506 |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> show global status like 'connections';
+---------------+----------+
| Variable_name | Value |
+---------------+----------+
| Connections | 16513711 |
+---------------+----------+
1 row in set (0.00 sec)
16513711-506/16513711 * 100% =99.9938% 很高的命中率啊 這臺之只讀的slave
* 表快取 Table Cache(table_open_cache):
表快取區主要用來快取表文件的檔案控制代碼資訊,在 MySQL5.1.3之前的版本通過table_cache引數設定,但從MySQL5.1.3開始改為table_open_cache來設定其大小。當我們的客戶端程式提交Query給MySQL的時候,
MySQL需要對Query所涉及到的每一個表都取得一個表文件控制代碼資訊,如果沒有Table Cache,那麼MySQL就不得不頻繁的進行開啟關閉檔案操作,無疑會對系統性能產生一定的影響,Table Cache 正是為了解決這一問題而產生的。
在有了Table Cache之後,MySQL每次需要獲取某個表文件的控制代碼資訊的時候,首先會到Table Cache中查詢是否存在空閒狀態的表文件控制代碼。如果有,則取出直接使用,沒有的話就只能進行開啟檔案操作獲得檔案控制代碼資訊。
在使用完之後,MySQL會將該檔案控制代碼資訊再放回Table Cache 池中,以供其他執行緒使用。注意,這裡設定的是可以快取的表文件控制代碼資訊的數目,而不是記憶體空間的大小。
Global,Dynamic,Default 400
推薦配置:根據記憶體配置4G 2048 大於最大Opened_tables
如何確定系統table_open_cache的情況?
mysql> show variables like 'table_open_cache';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| table_open_cache | 512 |
+------------------+-------+
1 row in set (0.00 sec)
mysql> show global status like 'open%_tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 512 |
| Opened_tables | 6841 |
+---------------+-------+
2 rows in set (0.00 sec)
調優參考:
http://blog.zfcms.com/article/282
http://www.kuqin.com/database/20120815/328904.html
兩個引數的值。其中Open_tables是當前正在開啟表的數量,Opened_tables是所有已經開啟表的數量。
如果Open_tables的值已經接近table_cache的值,且Opened_tables還在不斷變大,則說明mysql正在將快取的表釋放以容納新的表,此時可能需要加大table_cache的值。對於大多數情況,比較適合的值:
Open_tables / Opened_tables >= 0.85
Open_tables / table_cache <= 0.95
如果對此引數的把握不是很準,VPS管理百科給出一個很保守的設定建議:把MySQL資料庫放在生產環境中試執行一段時間,然後把引數的值調整得比Opened_tables的數值大一些,並且保證在比較高負載的極端條件下依然比Opened_tables略大。
在mysql預設安裝情況下,table_cache的值在2G記憶體以下的機器中的值預設時256到 512,如果機器有4G記憶體,則預設這個值是2048,
* 表定義資訊快取 Table definition Cache (table_definition_cache):
表定義資訊快取是從 MySQL5.1.3 版本才開始引入的一個新的快取區,用來存放表定義資訊。當我們的 MySQL 中使用了較多的表的時候,此快取無疑會提高對錶定義資訊的訪問效率。
MySQL 提供了 table_definition_cache 引數給我們設定可以快取的表的數量。注意,這裡設定的是可以快取的表定義資訊的數目,而不是記憶體空間的大小。
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables.
Global, Dynamic, Default 400
推薦配置:根據記憶體配置4G 2048 和Table Cache一樣即可
* 二進位制日誌緩衝區Binlog Cache( binlog_cache_size):
二進位制日誌緩衝區主要用來快取由於各種資料變更操做所產生的 Binary Log 資訊。為了提高系統的效能,MySQL 並不是每次都是將二進位制日誌直接寫入 Log File,而是先將資訊寫入 Binlog Buffer 中,
當滿足某些特定的條件(如 sync_binlog引數設定)之後再一次寫入 Log File 中。我們可以通過 binlog_cache_size 來設定其可以使用的記憶體大小,同時通過 max_binlog_cache_size 限制其最大大小
(當單個事務過大的時候 MySQL 會申請更多的記憶體)。當所需記憶體大於 max_binlog_cache_size 引數設定的時候,MySQL 會報錯:“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage”。
Global,Dynamic,Default 32K
推薦配置:2M
* InnoDB 日誌緩衝區 InnoDB Log Buffer (innodb_log_buffer_size):
這是 InnoDB 儲存引擎的事務日誌所使用的緩衝區。類似於 Binlog Buffer,InnoDB 在寫事務日誌的時候,為了提高效能,也是先將資訊寫入 Innofb Log Buffer 中,當滿足 innodb_flush_log_trx_commit 引數所設定的相應條件(或者日誌緩衝區寫滿)之後,才會將日誌寫到檔案(或者同步到磁碟)中。可以通過 innodb_log_buffer_size 引數設定其可以使用的最大記憶體空間。
注:innodb_flush_log_trx_commit 引數對 InnoDB Log 的寫入效能有非常關鍵的影響。該引數可以設定為0,1,2,解釋如下:
0:log buffer中的資料將以每秒一次的頻率寫入到log file中,且同時會進行檔案系統到磁碟的同步操作,但是每個事務的commit並不會觸發任何log buffer 到log file的重新整理或者檔案系統到磁碟的重新整理操作;
1:在每次事務提交的時候將log buffer 中的資料都會寫入到log file,同時也會觸發檔案系統到磁碟的同步;
2:事務提交會觸發log buffer 到log file的重新整理,但並不會觸發磁碟檔案系統到磁碟的同步。此外,每秒會有一次檔案系統到磁碟同步操作。
此外,MySQL文件中還提到,這幾種設定中的每秒同步一次的機制,可能並不會完全確保非常準確的每秒就一定會發生同步,還取決於程序排程的問題。實際上,InnoDB 能否真正滿足此引數所設定值代表的意義正常 Recovery 還是受到了不同 OS 下檔案系統以及磁碟本身的限制,可能有些時候在並沒有真正完成磁碟同步的情況下也會告訴 mysqld 已經完成了磁碟同步。
Global,Dynamic,Default 8M
推薦配置:8M 預設
* InnoDB 資料和索引快取 InnoDB Buffer Pool(innodb_buffer_pool_size):
InnoDB Buffer Pool 對 InnoDB 儲存引擎的作用類似於 Key Buffer Cache 對 MyISAM 儲存引擎的影響,主要的不同在於 InnoDB Buffer Pool 不僅僅快取索引資料,還會快取表的資料,
而且完全按照資料檔案中的資料快結構資訊來快取,這一點和 Oracle SGA 中的 database buffer cache 非常類似。所以,InnoDB Buffer Pool 對 InnoDB 儲存引擎的效能影響之大就可想而知了。
可以通過 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算得到 InnoDB Buffer Pool 的命中率。
global級別,不可動態變更 Default 128M
設定InnoDB資料和索引記憶體快取空間大小
配置方式:配置檔案中配置
選擇引數:50 - 80 % RAM
mysql> show variables like '%innodb_buffer%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 268435456 |
+------------------------------+-----------+
2 rows in set (0.00 sec)
通過show global status和show engine innodb status/G的BUFFER POOL AND MEMORY
mysql> show global status like '%innodb_buffer%';
+---------------------------------------+--------------+
| Variable_name | Value |
+---------------------------------------+--------------+
| Innodb_buffer_pool_pages_data | 15684 |
| Innodb_buffer_pool_bytes_data | 256966656 |
| Innodb_buffer_pool_pages_dirty | 210 |
| Innodb_buffer_pool_bytes_dirty | 3440640 |
| Innodb_buffer_pool_pages_flushed | 372378403 |
| Innodb_buffer_pool_pages_free | 1 |
| Innodb_buffer_pool_pages_misc | 698 |
| Innodb_buffer_pool_pages_total | 16383 |
| Innodb_buffer_pool_read_ahead_rnd | 0 |
| Innodb_buffer_pool_read_ahead | 691803 |
| Innodb_buffer_pool_read_ahead_evicted | 41350 |
| Innodb_buffer_pool_read_requests | 170965099291 |
| Innodb_buffer_pool_reads | 5392513 |
| Innodb_buffer_pool_wait_free | 0 |
| Innodb_buffer_pool_write_requests | 5825388207 |
+---------------------------------------+--------------+
15 rows in set (0.01 sec)
mysql> show engine innodb status/G
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 274726912; in additional pool allocated 0
Dictionary memory allocated 4055091
Buffer pool size 16383
Free buffers 1
Database pages 15673
Old database pages 5765
Modified db pages 521
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 27497746, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 6346456, created 1902566, written 372381712
0.00 reads/s, 0.37 creates/s, 27.75 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 15673, unzip_LRU len: 0
I/O sum[1107]:cur[0], unzip sum[0]:cur[0]
命中率 Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%
170965099291-5392513/170965099291 × 100% = 99.99%
* InnoDB 字典資訊快取 InnoDB Additional Memory Pool(innodb_additional_mem_pool_size):
InnoDB 字典資訊快取主要用來存放 InnoDB 儲存引擎的字典資訊以及一些 internal 的共享資料結構資訊。所以其大小也與系統中所使用的 InnoDB 儲存引擎表的數量有較大關係。不過,如果我們通過 innodb_additional_mem_pool_size 引數所設定的記憶體大小不夠,InnoDB 會自動申請更多的記憶體,並在 MySQL 的 Error Log 中記錄警告資訊。
global級別,不可動態變更 Default 8M
設定InnoDB存放資料庫字典資訊的Buffer大小
推薦配置:50M
三、檢視統計
#全域性共享記憶體 9個變數
show variables like 'innodb_buffer_pool_size'; /* InnoDB 資料和索引快取(InnoDB Buffer Pool) */
show variables like 'innodb_additional_mem_pool_size'; /* InnoDB 字典資訊快取(InnoDB Additional Memory Pool)*/
show variables like 'innodb_log_buffer_size'; /* InnoDB 日誌緩衝區(InnoDB Log Buffer) */
show variables like 'binlog_cache_size'; /* 二進位制日誌緩衝區(Binlog Buffer)*/
show variables like 'thread_cache_size'; /* 連線執行緒快取(Thread Cache)*/
show variables like 'query_cache_size'; /* 查詢快取(Query Cache)*/
show variables like 'table_open_cache'; /* 表快取(Table Cache) */
show variables like 'table_definition_cache'; /* 表定義資訊快取(Table definition Cache) */
show variables like 'key_buffer_size'; /* MyISAM索引快取(Key Buffer) */
#最大執行緒數
show variables like 'max_connections';
#執行緒獨享記憶體 6個變數
show variables like 'thread_stack'; /* 線執行緒棧資訊使用記憶體(thread_stack) */
show variables like 'sort_buffer_size'; /* 排序使用記憶體(sort_buffer_size) */
show variables like 'join_buffer_size'; /* Join操作使用記憶體(join_buffer_size) */
show variables like 'read_buffer_size'; /* 順序讀取資料緩衝區使用記憶體(read_buffer_size) */
show variables like 'read_rnd_buffer_size'; /* 隨機讀取資料緩衝區使用記憶體(read_rnd_buffer_size) */
show variables like 'tmp_table_size'; /* 臨時表使用記憶體(tmp_table_size) ,我實際計算把tmp_table_size放入全域性共享內*/
也可以通過系統變數的方式直接獲取
select @@key_buffer_size;
select @@max_connections
2.mysql記憶體計算公式
mysql使用的記憶體 = 全域性共享記憶體+最大執行緒數×執行緒獨享記憶體
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size
+max_connections*(
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size+tmp_table_size)
SET @kilo_bytes=1024;
SET @[email protected]_bytes*1024;
SET @[email protected]_bytes*1024;
SELECT (@@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@max_connections*(@@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@tmp_table_size))/@giga_bytes AS MAX_MEMORY_GB;
這個理論最大的記憶體使用量,在5.5版本中tmp_table_size預設是16M,按預設u自大連線數151計算,光執行緒獨享的臨時表佔據的空間都是2416M,我實際計算把tmp_table_size放入全域性共享內
我的計算公式
mysql使用的記憶體 = 全域性共享記憶體+最大執行緒數×執行緒獨享記憶體
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size+tmp_table_size
+max_connections*(
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size)
相關推薦
MySQL效能的五大配置引數(記憶體引數)
記憶體引數: 儲存引擎/共享 日誌緩衝區,緩衝區池 innodb_buffer_pool_size innodb_additional_mem_pool_size innodb_log_buffer_size 伺服器/共享 查詢調整快取 執行緒高速絡快取 query_c
影響MySQL效能的五大配置引數
我們今天主要和大家分享的是對MySQL效能影響關係緊密的五大配置引數,以下就是文章的具體內容描述,希望會給你帶來一些幫助。 以下的文章主要是對MySQL效能影響關係緊密的五大配置引數的介紹,我前幾天在相關網站看見對MySQL效能影響關係緊密的五大配置引數的資料,覺得挺好,就
MySQL配置檔案mysql.ini引數詳解、MySQL效能優化
my.ini(Linux系統下是my.cnf),當mysql伺服器啟動時它會讀取這個檔案,設定相關的執行環境引數。 my.ini分為兩塊:Client Section和Server Section。 Client Section用來配置MySQL客戶端引數。 要檢視配置引
MYSQL效能優化之引數配置
1、目的: 通過根據伺服器目前狀況,修改MySQL的系統引數,達到合理利用伺服器現有資源,最大合理的提高MySQL效能。 2、伺服器引數: 32G記憶體、4個CPU,每個CPU 8核。 3、MySQL目前安裝狀況。 MySQL目前安裝,用的是MySQL
關於tomcat的記憶體引數優化——如何配置catalina.sh的JAVA_OPTS?
以下是實體記憶體為16G的建議配置: export JAVA_OPTS="-server -Xms4096m -Xmx4096m -Xss256k -XX:PermSize=256m -XX:MaxPermSize=4096m -XX:NewSize=512m -XX:Ma
PostgreSQL 配置記憶體引數
對於任何資料庫軟體,記憶體配置項都是很重要的配置項。在 PostgreSQL 主要有以下幾個記憶體配置引數。 shared_buffers: integer 型別,設定資料庫伺服器將使用的共享記憶體緩衝區數量,此緩衝區為緩衝資料塊所用。此緩衝區是放在共享記憶體中的。每個緩衝區大小的典型值是 8K 位元組,預
yarn資源排程引數配置(記憶體,cpu)
Hadoop YARN同時支援記憶體和CPU兩種資源的排程(預設只支援記憶體,如果想進一步排程CPU,需要自己進行一些配置),本文將介紹YARN是如何對這些資源進行排程和隔離的。 在YARN中,資源管理由ResourceManager和NodeManager共同完成,其中,Resou
JVM JMM 引數配置,記憶體模型
java虛擬機器在執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域都有各自的用途,以及建立和銷燬的時間。有的區域隨著虛擬機器程序的啟動而存在,有些區域則是依賴使用者執行緒的啟動和結束而建立和銷燬。 JVM記憶體模型可以分為兩個部分,如下圖所示
JVM堆記憶體引數優化,讓效能飛起來
JVM堆記憶體引數優化,讓效能飛起來 堆記憶體是Java程序的重要組成部分,幾乎所有與應用相關的記憶體空間都和堆有關。現在主要介紹與堆記憶體相關的引數設定,這些引數對Java虛擬機器中非常重要的,也是對程式效能有著重要的影響。讓你徹底脫離OOM記憶體溢位等等帶來
.NET Core採用的全新配置系統[5]: 聊聊預設支援的各種配置源[記憶體變數,環境變數和命令列引數]
較之傳統通過App.config和Web.config這兩個XML檔案承載的配置系統,.NET Core採用的這個全新的配置模型的最大一個優勢就是針對多種不同配置源的支援。我們可以將記憶體變數、命令列引數、環境變數和物理檔案作為原始配置資料的來源,如果採用物理檔案作為配置源,我們可以選擇不同的格式(比如XML
Yarn下Mapreduce的記憶體引數理解&xml引數配置
Container是什麼? Container就是一個yarn的java程序,在Mapreduce中的AM,MapTask,ReduceTask都作為Container在Yarn的框架上執行,你可以在RM的網頁上【8088埠】看到Container的狀
Mysql效能優化之快取引數優化
資料庫屬於 IO 密集型的應用程式,其主要職責就是資料的管理及儲存工作。而我們知道,從記憶體中讀取一個數據庫的時間是微秒級別,而從一塊普通硬碟上讀取一個IO是在毫秒級別,二者相差3個數量級。所以,要優化資料庫,首先第一步需要優化的就是 IO,儘可能將磁碟IO轉化為記憶體IO。本文先從 MySQL 資料庫IO相
Java架構學習(十二)java記憶體結構&新生代&老年代&JVM引數調優&堆記憶體引數配置&解決堆疊溢位
JVM引數調優與垃圾回收機制 一、java記憶體結構 Java記憶體模型:是多執行緒裡面的,jmm與執行緒可見性有關 Java記憶體結構:是JVM虛擬機器儲存空間。 Java記憶體結構圖 Java記憶體機構分為:方法區、java堆、棧、本地
HDP 2.2 ( Hadoop 2.6 ) 叢集的記憶體引數配置和引數調優 (Yarn/MapReduce2)
近期在根據叢集上的各節點的物理機配置對叢集的記憶體引數進行調整。 因此較系統的學習了一下hadoop裡對資源調配的各元件的相關引數的含義。 作為示例的配置叢集版本是2.6, hortonworks 2.2. 首先要理解, hadoop 中 yarn 作為資源管理器,
JVM記憶體引數詳解以及配置調優
基本概念: PermGen space:全稱是Permanent Generation space。就是說是永久儲存的區域,用於存放Class和Meta資訊,Class在被Load的時候被放入該區域 Heap space:存放Instance。GC(Garbage Collection)應該不會對PermGe
mysql組複製配置檔案引數
組複製的配置檔案引數: [[email protected] ~]# cat /etc/my.cnf [mysqld] user =mysql # mysql plugin-dir=/opt/mysql/plugin_data basedi
MySQL 8.0.12 mysqlbinlog命令引數詳解
1.版本號不同: # /usr/local/mysql57/bin/mysqlbinlog --version /usr/local/mysql57/bin/mysqlbinlog Ver 3.4 for linux-glibc2.12 at x86_64 # /usr/local/mysql8
Intellij IDEA 中&專案部署中的Tomcat Server 配置VM options引數說明
第一點 Intellij IDEA 中的配置 點選Intellij IDEA 介面視窗Run,開啟Edit Configuration,出現Run/Debug Configurations介面。Application server 選擇安裝Tomcat所在的資料
MyBatis中的XML配置的一些引數、型別對應關係表
MyBatis中的各項設定引數 這是 MyBatis 中極為重要的調整設定,它們會改變 MyBatis 的執行時行為。下表描述了設定中各項的意圖、預設值等。 一個配置完整的 settings 元素的示例如下: <settings> <setting name="cache
JIRA應用的記憶體引數設定不當+容器沒有對資源進行限制導致服務掛掉的例子
背景: 應用的部署結構是這樣的:使用rancher管理的Docker叢集,有三臺物理主機,二十多個Docker容器, 提供的功能是問題跟蹤(JIRA),文件管理(Confluence),程式碼託管(svn,gitlab),持續整合(jenkins,gitlab-ci + Docker),程式碼質量管理(Son