序號 | 參數 | 默認值 | 物理內存 | 說明 | ||||
16G | 32G | 64G | 128G | 256G | ||||
[mysqld] | ||||||||
1 | thread_concurrency | 8 | 16 | #推薦設置爲服務器 CPU核數的2倍。推薦設置爲服務器 CPU核數的2倍,例如雙核的CPU, 那麼thread_concurrency的應該爲4;2個雙核的cpu, thread_concurrency的值應爲8。默認爲8 | ||||
2 | thread_stack | 64K | 512K | # 線程使用的堆大小. 此容量的內存在每次連接時被預留. # MySQL 本身常不會需要超過 64K 的內存 # 如果你使用你自己的需要大量堆的 UDF 函數或者你的操作系統對於某些操作需要更多的堆,你也許需要將其設置的更高一點. |
||||
3 | thread_cache_size | 110 | 80 | #線程緩存。可以複用的保存在中的線程的數量。如果有,新的線程從緩存中取得,當斷開連接的時候如果有空間,客戶的線置在緩存中。如果有很多新的線程,爲了提高性能可以這個變量值。 | ||||
4 | transaction_isolation | REPEATABLE-READ | REPEATABLE-READ | # 設定默認的事務隔離級別.可用的級別如下: # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE |
||||
5 | table_cache | 128 | 1024 | 高速緩存的大小。每當MySQL訪問一個表時,如果在表緩衝區中還有空間,該表就被打開並放入其中,這樣可以更快地訪問表內容。通過檢查峯值時間的狀態值Open_tables和Opened_tables,可以決定是否需要增加table_cache的值。如 果你發現open_tables等於table_cache,並且opened_tables在不斷增長,那麼你就需要增加table_cache的值了 (上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得)。注意,不能盲目地把table_cache設置成很大的值。如果設置得太高,可能會造成文件描述符不足,從而造成性能 不穩定或者連接失敗。比較合適的值爲: Open_tables / Opened_tables * 100% >= 85% Open_tables / table_cache * 100% <= 95% 1G內存機器,推薦值是128-256。內存在4GB左右的服務器該參數可設置爲256M或384M。 |
||||
6 | table_open_cache | 1024 | 4096 | #同樣是緩存表大小。MySQL 5.6相比於前代GA版本性能提升顯著,但默認緩存設置對於小型站點並不合理。 open_tables等於table_open_cache,都是512,說明mysql正在將緩存的表釋放以容納新的表,此時可能需要加大table_open_cache的值,4G內存的機器,建議設置爲2048 比較適合的值: Open_tables / Opened_tables >= 0.85 Open_tables / table_open_cache <= 0.95 |
||||
7 | table_definition_cache | 1400 | 400 | 存放表的定義信息。是frm文件在內存中的映射。MySQL需要打開frm文件,並將其內容初始化爲Table Share 對象。這裏存放與存儲引擎無關的,獨立的表定義相關信息。 爲什麼MySQL會出現這兩個概念是因爲:MySQL支持不同的存儲引擎,每種存儲引擎,數據存儲的格式都是不一樣的,因此需要指定一個存儲引擎相關的handler。這就有了table cache的作用。另外表的定義也需要存放內存中,而表的定義frm文件每個存儲引擎是通用的,需要另外獨立開來,這就有了table definition cache。 |
||||
8 | table_cache_instances | 1 | 16 | MySQL 5.6後,引入了“table_cache_instances”參數來控制 table cache instance的個數。目前最大值是64,默認值是1。建議值是16,當系統CPU核數高於16時。引入此參數的目的是,提高併發。相當於把table cache 拆成了多個分區,每個分區的打開table句柄數爲:table_open_cache / table_open_cache_instances。 | ||||
9 | tmp_table_size | 16M | 256M | 512M | 512M | 512M | 512M | #cache #內部內存臨時表的最大值。 通過設置tmp_table_size選項來增加一張臨時表的大小,例如做高級GROUP BY操作生成的臨時表。如果調高該值,MySQL同時將增加heap表的大小,可達到提高聯接查詢速度的效果,建議儘量優化查詢,要確保查詢過程中生成的臨時表在內存中,避免臨時表過大導致生成基於硬盤的MyISAM表。 默認爲16M,可調到64-256最佳,線程獨佔,太大可能內存不夠I/O堵塞 |
10 | slow_query_log | ON | ||||||
11 | slow_launch_time | 2 | 5 | 5 | 5 | 5 | 5 | 超過5秒的查詢語句爲慢SQL |
12 | slow_query_log_file | mysql-slow.log | 慢SQL日誌所在位置 /var/lib/mysql/mysql-slow.log |
|||||
13 | max_connections | 3000 | 2000 | #連接數。MySQL的最大連接數,增加該值增加mysqld 要求的文件描述符的數量。如果服務器的併發連接請求量比較大,建議調高此值,以增加並行連接數量,當然這建立在機器能支撐的情況下,因爲如果連接數越多, 介於MySQL會爲每個連接提供連接緩衝區,就會開銷越多的內存,所以要適當調整該值,不能盲目提高設值。 | ||||
14 | max_connect_errors | 6000 | 1000 | #是一個MySQL中與安全有關的計數器值,它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼 | ||||
15 | back_log | 50 | 128 | 128 | 256 | 256 | 512 | #MySQL能暫存的連接數量(根據實際設置) MySQL能暫存的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求,這就起作用。如果MySQL的連接數據達到 max_connections時,新來的請求將會被存在堆棧中,以等待某一連接釋放資源,該堆棧的數量即back_log,如果等待連接的數量超過 back_log,將不被授予連接資源。 back_log值指出在MySQL暫時停止回答新請求之前的短時間內有多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接,你需要增加它,換句話說,這值對到來的TCP/IP連接的偵聽隊列的大小。 當觀察你主機進程列表(mysql> show full processlist),發現大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待連接進程時,就要加大back_log 的值了。 默認數值是50,可調優爲128,對系統設置範圍爲小於512的整數。 |
16 | Innodb_File_Per_Table | 0 | 1 | 每一個表都將會生成以獨立的文件方式來進行存儲,每一個表都有一個.frm表描述文件,還有一個.ibd文件。 其中這個文件包括了單獨一個表的數據內容以及索引內容,默認情況下它的存儲位置也是在表的位置之中。 | ||||
17 | innodb_buffer_pool_size | 256M | 8G | 16G | 32G | 64G | 128G | 對於InnoDB表來說,innodb_buffer_pool_size的作用就相當於key_buffer_size對於MyISAM表的作用一樣。InnoDB使用該參數指定大小的內存來緩衝數據和索引。對於單獨的MySQL數據庫服務器,最大可以把該值設置成物理內存的80%。 根據MySQL手冊,對於2G內存的機器,推薦值是1G(50%)。 |
18 | innodb_flush_log_at_trx_commit | 1 | 0 | 主要控制了innodb將log buffer中的數據寫入日誌文件並flush磁盤的時間點,取值分別爲0、1、2三個。0,表示當事務提交時,不做日誌寫入操作,而是每秒鐘將log buffer中的數據寫入日誌文件並flush磁盤一次;1,則在每秒鐘或是每次事物的提交都會引起日誌文件寫入、flush磁盤的操作,確保了事務的 ACID;設置爲2,每次事務提交引起寫入日誌文件的動作,但每秒鐘完成一次flush磁盤操作。 實際測試發現,該值對插入數據的速度影響非常大,設置爲2時插入10000條記錄只需要2秒,設置爲0時只需要1秒,而設置爲1時則需要229秒。因此,MySQL手冊也建議儘量將插入操作合併成一個事務,這樣可以大幅提高速度。 根據MySQL手冊,在允許丟失最近部分事務的危險的前提下,可以把該值設爲0或2。 |
||||
19 | innodb_log_buffer_size | 2M | 16M | 32M | 32M | 64M | 64M | log緩存大小,一般爲1-8M,默認爲1M,對於較大的事務,可以增大緩存大小。 可設置爲4M或8M。 |
20 | innodb_log_file_size | 8M | 512M | # 在日誌組中每個日誌文件的大小. # 你應該設置日誌文件總合大小到你緩衝池大小的25%~100% # 來避免在日誌文件覆寫上不必要的緩衝池刷新行爲. # 不論如何, 請注意一個大的日誌文件大小會增加恢復進程所需要的時間 |
||||
21 | innodb_additional_mem_pool_size | 1M | 64M | 128M | 128M | 256M | 512M | 該參數指定InnoDB用來存儲數據字典和其他內部數據結構的內存池大小。缺省值是1M。通常不用太大,只要夠用就行,應該與表結構的複雜度有關係。如果不夠用,MySQL會在錯誤日誌中寫入一條警告信息。 根據MySQL手冊,對於2G內存的機器,推薦值是20M,可適當增加。 |
22 | innodb_thread_concurrency | 8 | 8 | 16 | 32 | 64 | 64 | 推薦設置爲 2*(NumCPUs+NumDisks),默認一般爲8 |
23 | innodb_write_io_threads | 16 | 16 | 32 | 32 | 32 | 32 | 髒頁寫的線程數,加大該參數可以提升寫入性能.mysql5.5以上纔有 |
24 | innodb_flush_log_at_trx_commit | 0 | 2 | 設置0是事務log(ib_logfile0、ib_logfile1)每秒寫入到log buffer,1是時時寫,2是先寫文件系統的緩存,每秒再刷進磁盤,和0的區別是選2即使mysql崩潰也不會丟數據。 | ||||
25 | innodb_max_dirty_pages_pct | 75 | 75 | 當系統中 髒頁 所佔百分比超過這個值,INNODB就會進行寫操作以把頁中的已更新數據寫入到磁盤文件中。默認75,一般現在流行的SSD硬盤很難達到這個比例。可依據實際情況在75-80之間調節 | ||||
26 | innodb_io_capacity | 5000 | 5000 | 從緩衝區刷新髒頁時,一次刷新髒頁的數量。根據磁盤IOPS的能力一般建議設置如下: SAS 200 SSD 5000 PCI-E 10000-50000 |
||||
27 | innodb_flush_method | fdatasync | O_DIRECT | 控制innodb數據文件和redo log的打開、刷寫模式。有三個值:fdatasync(默認),O_DSYNC,O_DIRECT。 • fdatasync模式:寫數據時,write這一步並不需要真正寫到磁盤纔算完成(可能寫入到操作系統buffer中就會返回完成),真正完成是flush操作,buffer交給操作系統去flush,並且文件的元數據信息也都需要更新到磁盤。 • O_DSYNC模式:寫日誌操作是在write這步完成,而數據文件的寫入是在flush這步通過fsync完成。 • O_DIRECT模式:數據文件的寫入操作是直接從mysql innodb buffer到磁盤的,並不用通過操作系統的緩衝,而真正的完成也是在flush這步,日誌還是要經過OS緩衝。 |
||||
28 | innodb_adaptive_flushing | off | ON | 影響每秒刷新髒頁的數目。規則由原來的“大於innodb_max_dirty_pages_pct時刷新100個髒頁到磁盤”變爲 “通過buf_flush_get_desired_flush_reate函數判斷重做日誌產生速度確定需要刷新髒頁的最合適數目”;即使髒頁比例小於 innodb_max_dirty_pages_pct時也會刷新一定量的髒頁。 | ||||
29 | innodb_max_dirty_pages_pct | 20 | 90 | # 在 InnoDB 緩衝池中最大允許的髒頁面的比例. # 如果達到限額, InnoDB 會開始刷新他們防止他們妨礙到乾淨數據頁面. # 這是一個軟限制,不被保證絕對執行 |
||||
30 | innodb_stats_on_metadata | OFF | OFF | 關掉一些訪問information_schema庫下表而產生的索引統計。 當重啓mysql實例後,mysql會隨機的io取數據遍歷所有的表來取樣來統計數據,這個實際使用中用的不多,建議關閉. |
||||
31 | innodb_change_buffering | all | all | 當更新/插入的非聚集索引的數據所對應的頁不在內存中時(對非聚集索引的更新操作通常會帶來隨機IO),會將其放到一個insert buffer中,當隨後頁面被讀到內存中時,會將這些變化的記錄merge到頁中。當服務器比較空閒時,後臺線程也會做merge操作。 由於主要用到merge的優勢來降低io,但對於一些場景並不會對固定的數據進行多次修改,此處則並不需要把更新/插入操作開啓change_buffering,如果開啓只是多餘佔用了buffer_pool的空間和處理能力。這個參數要依據實際業務環境來配置。 |
||||
32 | innodb_old_blocks_time | 0 | 1000 | 使Block在old sublist中停留時間長爲1s,不會被轉移到new sublist中,避免了Buffer Pool被污染BP可以被認爲是一條長鏈表。被分成young 和 old兩個部分,其中old默認佔37%的大小(由innodb_old_blocks_pct 配置)。靠近頂端的Page表示最近被訪問。靠近尾端的Page表示長時間未被訪問。而這兩個部分的交匯處成爲midpoint。每當有新的Page需要加載到BP時,該page都會被插入到midpoint的位置,並聲明爲old-page。當old部分的page,被訪問到時,該page會被提升到鏈表的頂端,標識爲young。 由於table scan的操作是先load page,然後立即觸發一次訪問。所以當innodb_old_blocks_time =0 時,會導致table scan所需要的page不讀的作爲young page被添加到鏈表頂端。而一些使用較爲不頻繁的page就會被擠出BP,使得之後的SQL會產生磁盤IO,從而導致響應速度變慢。 這時雖然mysqldump訪問的page會不斷加載在LRU頂端,但是高頻度的熱點數據訪問會以更快的速度把page再次搶佔到LRU頂端。從而導致mysqldump加載入的page會被迅速刷下,並立即被evict(淘汰)。因此,time=0或1000對這種壓力環境下的訪問不會造成很大影響,因爲dump的數據根本搶佔不過熱點數據。不只dump,當大數據操作的時候也是如此。 |
||||
33 | innodb_lock_wait_timeout | 3600 | 120 | # 在被回滾前,一個 InnoDB 的事務應該等待一個鎖被批准多久. # InnoDB 在其擁有的鎖表中自動檢測事務死鎖並且回滾事務. # 如果你使用 LOCK TABLES 指令, 或者在同樣事務中使用除了 InnoDB 以外的其他事務安全的存儲引擎 # 那麼一個死鎖可能發生而 InnoDB 無法注意到. # 這種情況下這個 timeout 值對於解決這種問題就非常有幫助. |
||||
34 | wait_timeout | 120 | 10 | 指定一個請求的最大連接時間,對於4GB左右內存的服務器可以設置爲5-10。 | ||||
35 | interactive_timeout | 28800 | 7200 | 一個交互連接在被服務器在關閉前等待行動的秒數。一個交互的客戶被定義爲對mysql_real_connect()使用CLIENT_INTERACTIVE 選項的客戶。 默認數值是28800,可調優爲7200。 |
||||
36 | binlog_cache_size | 32K | 8M | 爲每個session 分配的內存,在事務過程中用來存儲二進制日誌的緩存。 show global status like 'bin%';上述語句我們可以得到當前 數據庫binlog_cache_size的使用情況 Binlog_cache_disk_use表示因爲我們binlog_cache_size設計的內存不足導致緩存二進制日誌用到了臨時文件的次數 Binlog_cache_use 表示 用binlog_cache_size緩存的次數 當對應的Binlog_cache_disk_use 值比較大的時候 我們可以考慮適當的調高 binlog_cache_size 對應的值 a.max_binlog_cache_size 表示的是binlog 能夠使用的最大cache 內存大小 當我們執行多語句事務的時候 所有session的使用的內存超過max_binlog_cache_size的值時 就會報錯:“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage” b.設置太大的話,會比較消耗內存資源;設置太小又會使用到臨時文件即disk |
||||
37 | performance_schema_max_table_instances | 12500 | 600 | 通過修改my.cnf文件中的performance_schema_max_table_instances參數,能夠有效降低內存佔用。 | ||||
38 | max_heap_table_size | 1M | 128M | 256M | 512M | 512M | 512M | # 獨立的內存表所允許的最大容量. # 此選項爲了防止意外創建一個超大的內存表導致永盡所有的內存資源. #內部內存臨時表的最大值,每個線程都要分配 用戶可以創建的內存表(memory table)的大小。這個值用來計算內存表的最大行數值。這個變量支持動態改變,即set @max_heap_table_size=# 這個變量和tmp_table_size一起限制了內部內存表的大小。如果某個內部heap(堆積)表大小超過tmp_table_size,MySQL可以根據需要自動將內存中的heap表改爲基於硬盤的MyISAM表。 |
39 | key_buffer_size | 8M | 1G | 2G | 4G | 8G | 16G | #指定索引緩衝區的大小,只對MyISAM表起作用,這裏寫上也沒有關係。key_buffer_size指定索引緩衝區的大小,它決定索引處理的速度,尤其是索引讀的速度。 key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表,但是內部的臨時磁盤表是MyISAM表,也要使用該值。主機內存的1/16.4G內存配置256M |
40 | sort_buffer_size | 256K | 32M | 64M | 128M | 256M | 512M | # Sort_Buffer_Size 是一個connection級參數,在每個connection(session)第一次需要使用這個buffer的時候,一次性分配設置的內存。 #Sort_Buffer_Size 並不是越大越好,由於是connection級的參數,過大的設置+高併發可能會耗盡系統內存資源。例如:500個連接將會消耗 500*sort_buffer_size(8M)=4G內存 #Sort_Buffer_Size 超過2KB的時候,就會使用mmap() 而不是 malloc() 來進行內存分配,導致效率降低。 |
41 | record_buffer_size | 128K | 32M | 64M | 128M | 256M | 512M | 每個進行一個順序掃描的線程爲其掃描的每張表分配這個大小的一個緩衝區。如果你做很多順序掃描,你可能想要增加該值。 默認數值是131072(128K),可改爲16773120 (16M) |
42 | read_buffer_size | 8M | 64M | 64M | 128M | 256M | 512M | #當一個查詢不斷地掃描某一個表,MySQL會爲它分配一段內存緩衝區 |
43 | read_rnd_buffer_size | 16M | 32M | 64M | 128M | 256M | 512M | #隨機讀取數據緩衝區使用內存。當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區。進行排序查詢時,MySQL會首先掃描一遍該緩衝,以避 免磁盤搜索,提高查詢速度,如果需要排序大量數據,可適當調高該值。但MySQL會爲每個客戶連接發放該緩衝空間,所以應儘量適當設置該值,以避免內存開 銷過大。 一般可設置爲16M |
44 | join_buffer_size | 16M | 1024M | 1024M | 2048M | 2048M | 2048M | #表和表聯接的緩衝區的大小。聯合查詢操作所能使用的緩衝區大小 record_buffer_size,read_rnd_buffer_size,sort_buffer_size,join_buffer_size爲每個線程獨佔,也就是說,如果有100個線程連接,則佔用爲16M*100 |
45 | myisam_sort_buffer_size | 1M | 256M | # 此緩衝當 MySQL 需要在 REPAIR, OPTIMIZE, ALTER 以及 LOAD DATA INFILE 到一個空表中引起重建索引時被分配. # 這在每個線程中被分配.所以在設置大值時需要小心. |
||||
46 | myisam_max_sort_file_size | 256M | 10G | # MySQL 重建索引時所允許的最大臨時文件的大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). # 如果文件大小比此值更大,索引會通過鍵值緩衝創建(更慢) |
||||
47 | query_cache_type | 0 | 1 | #將查詢結果放入查詢緩存中 | ||||
48 | query_cache_size | 128M | 256M | 512M | 1024M | 2048M | 4096M | #查詢緩存大小。使用查詢緩衝,MySQL將查詢結果存放在緩衝區中,今後對於同樣的SELECT語句(區分大小寫),將直接從緩衝區中讀取結果。 通過檢查狀態值Qcache_*,可以知道query_cache_size設置是否合理(上述狀態值可以使用SHOW STATUS LIKE ‘Qcache%’獲得)。如果Qcache_lowmem_prunes的值非常大,則表明經常出現緩衝不夠的情況,如果Qcache_hits的值也 非常大,則表明查詢緩衝使用非常頻繁,此時需要增加緩衝大小;如果Qcache_hits的值不大,則表明你的查詢重複率很低,這種情況下使用查詢緩衝反 而會影響效率,那麼可以考慮不用查詢緩衝。此外,在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩衝。 |
49 | query_cache_limit | 1M | 4M | 8M | 16M | 32M | 32M | 指定單個查詢能夠使用的緩衝區大小,缺省爲1M |
[myisamchk] | ||||||||
50 | sort_buffer_size | 2M | 16M | 32M | 64M | 128M | 256M | |
51 | key_buffer | 2M | 16M | 32M | 64M | 128M | 256M | |
52 | read_buffer | 1M | 8M | 16M | 32M | 64M | 128M | |
53 | write_buffer | 1M | 8M | 16M | 32M | 64M | 128M | |
[mysqldump] | ||||||||
54 | max_allowed_packet | 1M | 128M | 256M | 512M | 1024M | 2048M | mysql根據配置文件會限制server接受的數據包大小。 有時候大的插入和更新會被max_allowed_packet 參數限制掉,導致失敗。 |
55 | ||||||||
[mysqld_safe] | ||||||||
56 | open-files-limit | 256 | 8192 | 8192 | 16384 | 16384 | 16384 | |
建議優化參數 | ||||||||
可以優化參數 |
MySQL 5.6參數優化詳解
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.