mysql服務器參數
阿新 • • 發佈：2017-12-07
不同 開戶 nod 磁盤 opened 出了 默認值 open 定義
該變量記錄了由於查詢緩存出現內存不足，而需要從緩存中刪除的查詢數量，可通過監控Qcache_lowmem_prunes的增量，來衡量是否需要增大query_cache_size。
Created_tmp_tables
創建內存臨時表的數量，如果Created_tmp_disk_tables比較大，則應該考慮增加tmp_table_size的大小。應該將tmp_table_size和max_heap_table_size簡單調整到大小一樣。32MB一般足夠了。對這兩個參數的控制通常基於內存引擎的臨時表可以增長的閾值，若超過了這個閾值，就會轉化成On-disk MyISAM表。
Open_tables
當前打開的表的數量。
Opened_tables
已經打開的表的數量。
查看Open_tables及Opened_tables的增量時，如果Opened_tables的增量比較大，那麽可能table_open_cache不夠用了。如果Open_tables對比table_cache_size並不大，但Opened_tables還在持續增長，那麽也可能是顯式臨時表被不斷打開而導致的。
table_open_cache
默認的設置太小了，生產環境中應該將其設置得足夠大，數千到一萬是比較合理的值。檢查Opened_tables status變量，如果該值比較大，而我們不經常運行FLUSH TABLES命令，那麽應該增加table_open_cache的變量值。
table_definition_cache
一般可以將其設置為足夠高的值來緩存表定義，比如4096，這並不會耗費什麽資源。默認的256太小了。
innodb_buffer_pool_size
這個參數主要作用是緩存innodb表的索引，數據，插入數據時的緩沖。一個簡單的策略是如果數據庫很大，遠遠超過內存，那麽應設置盡可能大的緩沖池（buffer pool）。如果數據庫較小，一般來說，緩沖池的大小設置為稍大於數據庫的10%就可以了。我們的庫不會太小，所以，這個值應該盡可能大，如設置為50-80%的物理內存。默認值是128M，太小了。
innodb_log_file_size
事務日誌大小。日誌太小，會頻繁切換日誌，性能差；日誌太大，會導致災難恢復時過慢。建議是256M-512M。
innodb_flush_log_at_trx_commit
建議設置為2，兼顧性能和安全。0最快，1最安全，2可能會丟失一秒的事務。
0：日誌緩沖將每秒一次被寫到日誌文件中，並且對日誌文件進行磁盤操作的刷新，但是在事務提交時不進行任何操作。
1：在每個事務進行提交時，日誌緩沖將被寫到日誌文件，且把對日誌文件的變更刷新到磁盤中。
2：在每個事務進行提交時，日誌緩沖將被寫到文件，但不會對日誌文件進行到磁盤操作的刷新，對日誌文件的刷新每秒發生一次。
sync_binlog
寫多少次二進制日誌後，同步磁盤。默認是0，不同步。建議設置為8-20。設置為1最安全，但可能會造成IO瓶頸。
read_rnd_buffer_size
排序後，按照排序後的順序讀取行時，則通過該緩沖區讀取行，以避免搜索硬盤。將該變量設置為較大的值可以改進ORDER BY的性能。但是，這是為每個客戶端分配的緩沖區，因此你不應該將全局變量設置為較大的值。相反，只為需要運行大查詢的客戶端更改會話變量即可。
sort_buffer_size
每個排序線程分配的緩沖區的大小。增加該值可以加快ORDER BY或GROUP BY操作。查詢需要排序的時候（如filesort）才分配sort_buffer_size指定的內存，不要設置得過大，否則小的排序也需要大的內存。確定需要進行大的排序操作的時候，可以在會話級別定義大的值。
query_cache_size
緩存查詢結果。默認是0禁用的。要開戶，需要同時保證query_cache_type=ON。建議設置為64M-256M，不要太大。寫庫時，會清除相關數據的緩存，所以這個值太大，會導致寫性能變差。
以下列出了一些主要需要關註的參數。要看更全的，找Mysql官方文檔，註意要對應版本。
max_connect_errors
最大錯誤連接數，達到時會阻止連接，建議大於5000
max_connections
並行的最大連接數，建議2000-5000
max_used_connections
服務啟動後曾經達到的最大連接數，若達到max_connections，則表示某個時刻存在突然的高峰連接，可能會有性能問題。
threads_connected
當前連接數。
threads_running
指同時運行的線程數目。這個值一般不會大於邏輯CPU的個數，如果經常有過多的線程同時運行，那麽可能就意味著有性能問題。這個指標很重要，往往表明了一個系統的繁忙程度，它在系統爆發性能問題之前，會有一個上升的趨勢，此時收集的性能信息，將有助於我們診斷復雜的性能問題。
Qcache_lowmem_prunes
該變量記錄了由於查詢緩存出現內存不足，而需要從緩存中刪除的查詢數量，可通過監控Qcache_lowmem_prunes的增量，來衡量是否需要增大query_cache_size。
Created_tmp_tables
創建內存臨時表的數量，如果Created_tmp_disk_tables比較大，則應該考慮增加tmp_table_size的大小。應該將tmp_table_size和max_heap_table_size簡單調整到大小一樣。32MB一般足夠了。對這兩個參數的控制通常基於內存引擎的臨時表可以增長的閾值，若超過了這個閾值，就會轉化成On-disk MyISAM表。
Open_tables
當前打開的表的數量。
Opened_tables
已經打開的表的數量。
查看Open_tables及Opened_tables的增量時，如果Opened_tables的增量比較大，那麽可能table_open_cache不夠用了。如果Open_tables對比table_cache_size並不大，但Opened_tables還在持續增長，那麽也可能是顯式臨時表被不斷打開而導致的。
table_open_cache
默認的設置太小了，生產環境中應該將其設置得足夠大，數千到一萬是比較合理的值。檢查Opened_tables status變量，如果該值比較大，而我們不經常運行FLUSH TABLES命令，那麽應該增加table_open_cache的變量值。
table_definition_cache
一般可以將其設置為足夠高的值來緩存表定義，比如4096，這並不會耗費什麽資源。默認的256太小了。
innodb_buffer_pool_size
這個參數主要作用是緩存innodb表的索引，數據，插入數據時的緩沖。一個簡單的策略是如果數據庫很大，遠遠超過內存，那麽應設置盡可能大的緩沖池（buffer pool）。如果數據庫較小，一般來說，緩沖池的大小設置為稍大於數據庫的10%就可以了。我們的庫不會太小，所以，這個值應該盡可能大，如設置為50-80%的物理內存。默認值是128M，太小了。
innodb_log_file_size
事務日誌大小。日誌太小，會頻繁切換日誌，性能差；日誌太大，會導致災難恢復時過慢。建議是256M-512M。
innodb_flush_log_at_trx_commit
建議設置為2，兼顧性能和安全。0最快，1最安全，2可能會丟失一秒的事務。
0：日誌緩沖將每秒一次被寫到日誌文件中，並且對日誌文件進行磁盤操作的刷新，但是在事務提交時不進行任何操作。
1：在每個事務進行提交時，日誌緩沖將被寫到日誌文件，且把對日誌文件的變更刷新到磁盤中。
2：在每個事務進行提交時，日誌緩沖將被寫到文件，但不會對日誌文件進行到磁盤操作的刷新，對日誌文件的刷新每秒發生一次。
sync_binlog
寫多少次二進制日誌後，同步磁盤。默認是0，不同步。建議設置為8-20。設置為1最安全，但可能會造成IO瓶頸。
read_rnd_buffer_size
排序後，按照排序後的順序讀取行時，則通過該緩沖區讀取行，以避免搜索硬盤。將該變量設置為較大的值可以改進ORDER BY的性能。但是，這是為每個客戶端分配的緩沖區，因此你不應該將全局變量設置為較大的值。相反，只為需要運行大查詢的客戶端更改會話變量即可。
sort_buffer_size
每個排序線程分配的緩沖區的大小。增加該值可以加快ORDER BY或GROUP BY操作。查詢需要排序的時候（如filesort）才分配sort_buffer_size指定的內存，不要設置得過大，否則小的排序也需要大的內存。確定需要進行大的排序操作的時候，可以在會話級別定義大的值。
query_cache_size
緩存查詢結果。默認是0禁用的。要開戶，需要同時保證query_cache_type=ON。建議設置為64M-256M，不要太大。寫庫時，會清除相關數據的緩存，所以這個值太大，會導致寫性能變差。
mysql服務器參數