http://bbs.51cto.com/thread-1166608-1.html 在網上找的一篇
下面是自習找資料翻譯的 歡迎討論
1、 back_log = 50
#指定MySQL可能的連接數量。當MySQL主線程在很短的時間內得到非常多的連接請求，該參數就起作用，之後主線程花些時間（儘管很短）檢查連接並且啓動一個新線程。
back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。如果系統在一個短時間內有很多連接，則需 要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自己的限制。試圖設定back_log高於 你的操作系統的限制將是無效的。
當觀察MySQL進程列表，發現大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待連接進程時，就要加大 back_log 的值。back_log默認值爲50。
max_connections = 100
參數用來設置最大連接（用戶）數。每個連接MySQL的用戶均算作一個連接，max_connections的默認值爲100
2、 max_connect_errors = 10
#當此值設置爲10時，意味着如果某一客戶端嘗試連接此MySQL服務器，但是失敗（如密碼錯誤等等）10次，則MySQL會無條件強制阻止此客戶端連接。
如果希望重置此計數器的值，則必須重啓MySQL服務器或者執行
命令。
當這一客戶端成功連接一次MySQL服務器後，針對此客戶端的max_connect_errors會清零。
影響與錯誤形式
如果max_connect_errors的設置過小，則網頁可能提示無法連接數據庫服務器；而通過SSH的mysql命令連接數據庫，則會返回
ERROR 1129 (00000): Host ‘gateway’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’
table_open_cache = 2048
參數設置表高速緩存的數目。每個連接進來，都會至少打開一個表緩存。因此， table_cache 的大小應與 max_connections 的設置有關。例如，對於 200 個並行運行的連接，應該讓表的緩存至少有 200 × N ，這裏 N 是應用可以執行的查詢的一個聯接中表的最大數量。此外，還需要爲臨時表和文件保留一些額外的文件描述符。
當 Mysql 訪問一個表時，如果該表在緩存中已經被打開，則可以直接訪問緩存；如果還沒有被緩存，但是在 Mysql 表緩衝區中還有空間，那麼這個表就被打開並放入表緩衝區；如果表緩存滿了，則會按照一定的規則將當前未用的表釋放，或者臨時擴大表緩存來存放，使用表緩存的好處是可以更快速地訪問表中的內容。
緩存機制
當 Mysql 訪問一個表時，如果該表在緩存中已經被打開，則可以直接訪問緩存；如果還沒有被緩存，但是在 Mysql 表緩衝區中還有空間，那麼這個表就被打開並放入表緩衝區；如果表緩存滿了，則會按照一定的規則將當前未用的表釋放，或者臨時擴大表緩存來存放，使用表緩存的好處是可以更快速地訪問表中的內容。
執行
mysql >flush tables;
#命令將會清空當前所有緩存的表。
3、 max_allowed_packet = 16M
#指代mysql服務器端和客戶端在一次傳送數據包的過程當中數據包的大小
這個是定義mysql服務器端和客戶端在一次傳送數據包的過程當中數據包的大小
定義過大，比如max_allowed_packet=8092，有可能服務器端太忙，來不及接收，或者網絡太差，會容易造成丟包
定義過小，會因爲客戶端可能無法快速接收服務器端發過來的包，一般推薦是4096
http://bbs.chinaunix.net/thread-4178672-1-1.html
4、 binlog_cache_size = 1M
#爲每個session 分配的內存，在事務過程中用來存儲二進制日誌的緩存。提高記錄bin-log的效率
max_heap_table_size = 64M
它規定了內部內存臨時表的最大值，每個線程都要分配。（實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。）如果內存臨時表超出了限制，MySQL就會自動地把它轉化爲基於磁盤的MyISAM表，存儲在指定的tmpdir目錄下，默認:
mysql> show variables like "tmpdir";
5、read_buffer_size = 2M
#是MySQL讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySQL會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。如果對錶的順序掃描請求非常頻繁，並且你認爲頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩衝區大小提高其性能。
read_rnd_buffer_size = 16M
是MySQL的隨機讀緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySQL會首先掃描一遍該緩衝，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySQL會爲每個客戶連接發放該緩衝空間，所以應儘量適當設置該值，以避免內存開銷過大。
6、 sort_buffer_size = 8M
#是MySQL執行排序使用的緩衝大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小。
join_buffer_size = 8M
應用程序經常會出現一些兩表（或多表）Join的操作需求，MySQL在完成某些 Join 需求的時候（all/index join），爲了減少參與Join的“被驅動表”的讀取次數以提高性能，需要使用到 Join Buffer 來協助完成 Join操作。當 Join Buffer 太小，MySQL 不會將該 Buffer 存入磁盤文件，而是先將Join Buffer中的結果集與需要 Join 的表進行 Join 操作，然後清空 Join Buffer 中的數據，繼續將剩餘的結果集寫入此 Buffer 中，如此往復。這勢必會造成被驅動表需要被多次讀取，成倍增加 IO 訪問，降低效率
thread_cache_size = 8
如果我們在MySQL服務器配置文件中設置了thread_cache_size，當客戶端斷開之後，
服務器處理此客戶的線程將會緩存起來以響應下一個客戶而不是銷燬（前提是緩存數未達上限）。thread_cache_size功能在mysql數據庫配置文件中是非常重要的一項功能了，如果對thread_cache_size優化做得好我們可以讓服務器跑得非常快，設置不好就會發現很小訪問量就非常的卡哦。
7、 thread_concurrency = 8
#是一個編程術語,表示“線程併發”,簡單地說就是一個程序創建多個線程,並行執行一些任務。
query_cache_size = 64M
查詢緩存保存查詢返回的完整結果。當查詢命中該緩存，會立刻返回結果，跳過了解析，優化和執行階段。
查詢緩存會跟蹤查詢中涉及的每個表，如果這寫表發生變化，那麼和這個表相關的所有緩存都將失效。
但是隨着服務器功能的強大，查詢緩存也可能成爲整個服務器的資源競爭單點。
緩存存放在一個引用表中，通過一個哈希值引用，這個哈希值包括查詢本身，數據庫，客戶端協議的版本等，任何字符上的不同，例如空格，註釋都會導致緩存不命中。
當查詢中有一些不確定的數據時，是不會緩存的，比方說now(),current_date(),自定義函數，存儲函數，用戶變量，字查詢等。所以這樣的查詢也就不會命中緩存，但是還會去檢測緩存的，因爲查詢緩存在解析SQL之前，所以MySQL並不知道查詢中是否包含該類函數，只是不緩存，自然不會命中。
8、 query_cache_limit = 2M
#指定單個查詢能夠使用的緩衝區大小，缺省爲1M
ft_min_word_len = 4
從 Mysql 4.0 開始就支持全文索引功能，但是 Mysql 默認的最小索引長度是 4。如果是英文默認值是比較合理的，但是中文絕大部分詞都是2個字符，這就導致小於4個字的詞都不能被索引，全文索引功能就形同虛設了
一般的數據 庫搜索 都是用的SQL 的 like 語句，like 語句是不能利用索引的，每次查詢都是從第一條遍歷至最後一條，查詢效率極其低下。一般數據超過10萬或者在線人數過多,like查詢都會導致數據庫 崩潰。這也就是爲什麼很多程序 都只提供標題搜索的原因了，因爲如果搜索內容，那就更慢了，幾萬數據就跑不動了。
Mysql 全文索引是專門爲了解決模糊查詢提供的，可以對整篇文章 預先按照詞進行索引，搜索效率高，能夠支持百萬級的數據檢索。
9、 default-storage-engine = MYISAM
#默認的MyISAM存儲引擎
10、 thread_stack = 192K
#每個連接被創建的時候,mysql分配給它的內存.這個值一般認爲默認就可以應用於大部分場景了,除非必要非則不要動它.
transaction_isolation = REPEATABLE-READ
11、 tmp_table_size = 64M
#它規定了內部內存臨時表的最大值，每個線程都要分配。（實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。）如果內存臨時表超出了限制，MySQL就會自動地把它轉化爲基於磁盤的MyISAM表，存儲在指定的tmpdir目錄下
log-bin=mysql-bin
mysql-bin.000001、mysql-bin.000002等文件是數據庫的操作日誌，例如UPDATE一個表，或者DELETE一些數據，即使該語句沒有匹配的數據，這個命令也會存儲到日誌文件中，還包括每個語句執行的時間，也會記錄進去的。
binlog_format=mixed
mysql複製主要有三種方式：基於SQL語句的複製(statement-based replication, SBR)，基於行的複製(row-based replication, RBR)，混合模式複製(mixed-based replication, MBR)。對應的，binlog的格式也有三種：STATEMENT，ROW，MIXED。
① STATEMENT模式（SBR）
每一條會修改數據的sql語句會記錄到binlog中。優點是並不需要記錄每一條sql語句和每一行的數據變化，減少了binlog日誌量，節約IO，提高性能。缺點是在某些情況下會導致master-slave中的數據不一致(如sleep()函數， last_insert_id()，以及user-defined functions(udf)等會出現問題)
② ROW模式（RBR）
不記錄每條sql語句的上下文信息，僅需記錄哪條數據被修改了，修改成什麼樣了。而且不會出現某些特定情況下的存儲過程、或function、或trigger的調用和觸發無法被正確複製的問題。缺點是會產生大量的日誌，尤其是alter table的時候會讓日誌暴漲。
③ MIXED模式（MBR）
以上兩種模式的混合使用，一般的複製使用STATEMENT模式保存binlog，對於STATEMENT模式無法複製的操作使用ROW模式保存binlog，MySQL會根據執行的SQL語句選擇日誌保存方式
MIXED說明
對於執行的SQL語句中包含now()這樣的時間函數，會在日誌中產生對應的unix_timestamp()*1000的時間字符串，slave在完成同步時，取用的是sqlEvent發生的時間來保證數據的準確性。另外對於一些功能性函數slave能完成相應的數據同步，而對於上面指定的一些類似於UDF函數，導致Slave無法知曉的情況，則會採用ROW格式存儲這些Binlog，以保證產生的Binlog可以供Slave完成數據同步。
http://www.111cn.net/database/mysql/71702.htm
12、 slow_query_log
#顧名思義，慢查詢日誌中記錄的是執行時間較長的query，也就是我們常說的slow query，通過設--log-slow-queries[=file_name]來打開該功能並設置記錄位置和文件名，默認文件名爲hostname-slow.log，默認目錄也是數據目錄。
慢查詢日誌採用的是簡單的文本格式，可以通過各種文本編輯器查看其中的內容。其中記錄了語句執行的時刻，執行所消耗的時間，執行用戶，連接主機等相關信息。MySQL還提供了專門用來分析滿查詢日誌的工具程序mysqlslowdump，用來幫助數據庫管理人員解決可能存在的性能問題。
http://www.cnblogs.com/Richardzhu/p/3230221.html
13、 long_query_time = 2
#MySQL慢查詢支持毫秒的設置MySQL慢查詢本身不支持ms級別(需要打補丁），但是對MySQL5.21+的版本，long_query_time最小值爲0（5.2.1之前版本最小爲1s)，單位是s,如果指定ms，其ms部分會被忽略；其實這已經是變相支持毫秒級別了，比如查詢時間大於100ms將被記
http://www.dedecms.com/knowledge/data-base/mysql/2012/0819/7319.html
14、 server-id = 1
#1、 mysql同步的數據中是包含server-id的，用於標識該語句最初是從哪個server寫入的，因此server-id一定要有的
#2、 每一個同步中的slave在master上都對應一個master線程，該線程就是通過slave的server-id來標識的；每個slave在master端最多有一個master線程，如果兩個slave的server-id 相同，則後一個連接成功時，前一個將被踢掉。 這裏至少有這麼一種考慮
slave主動連接master之後，如果slave上面執行了slave stop；則連接斷開，但是master上對應的線程並沒有退出；當slave start之後，master不能再創建一個線程而保留原來的線程，那樣同步就可能有問題；
#3、 在mysql做主主同步時，多個主需要構成一個環狀，但是同步的時候有要保證一條數據不會陷入死循環，這裏就是靠server-id來實現的
14、 key_buffer_size = 32M
#key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設置是否合理。比例key_reads /key_read_requests應該儘可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。
key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁盤表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。
http://blog.chinaunix.net/uid-24145780-id-125159.html
15、 bulk_insert_buffer_size = 64M
#和key_buffer_size一樣，這個參數同樣也僅作用於使用 MyISAM存儲引擎，用來緩存批量插入數據的時候臨時緩存寫入數據。當我們使用如下幾種數據寫入語句的時候，會使用這個內存區域來緩存批量結構的數據以幫助批量寫入數據文件：
http://www.jb51.net/article/48422.htm
16、 myisam_sort_buffer_size = 128M
#當對MyISAM表執行repair table或創建索引時，用以緩存排序索引；設置太小時可能會遇到” myisam_sort_buffer_size is too small”
17、 myisam_max_sort_file_size = 10G
#當對MyISAM表重建索引時(repair/alter table/load data infile)，允許使用的臨時文件最大值；如果超過此限制索引創建則改用key cache，此時show processlist會顯示該線程處於”repair with keycache”而非”repair by sorting”，前者逐條創建索引記錄；另外，當指定的tmpdir目錄空間不足時也會導致類似情形；
18、 myisam_repair_threads = 1
# 如果一個表擁有超過一個索引, MyISAM 可以通過並行排序使用超過一個線程去修復他們.
# 這對於擁有多個CPU以及大量內存情況的用戶,是一個很好的選擇.
myisam_recover
#自動檢查和修復沒有適當關閉的 MyISAM 表
19、 innodb_additional_mem_pool_size = 16M
#這個參數用來設置 InnoDB 存儲的數據目錄信息和其它內部數據結構的內存池大小，類似於Oracle的library cache。這不是一個強制參數，可以被突破。
innodb_buffer_pool_size = 2G
當我們使用InnoDB存儲引擎的時候，innodb_buffer_pool_size 參數可能是影響我們性能的最爲關鍵的一個參數了，他用來設置用於緩存 InnoDB 索引及數據塊的內存區域大小，類似於 MyISAM 存儲引擎的 key_buffer_size 參數，當然，可能更像是 Oracle 的 db_cache_size。簡單來說，當我們操作一個 InnoDB 表的時候，返回的所有數據或者去數據過程中用到的任何一個索引塊，都會在這個內存區域中走一遭。
和key_buffer_size 對於 MyISAM 引擎一樣，innodb_buffer_pool_size 設置了 InnoDB 存儲引擎需求最大的一塊內存區域的大小，直接關係到 InnoDB存儲引擎的性能，所以如果我們有足夠的內存，儘可將該參數設置到足夠打，將儘可能多的 InnoDB 的索引及數據都放入到該緩存區域中，直至全部。
我們可以通過 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算緩存命中率，並根據命中率來調整 innodb_buffer_pool_size 參數大小進行優化。
innodb_data_file_path = ibdata1:10M:autoextend
#表空間文件 重要數據
20、 innodb_write_io_threads = 8
#其它對IO有影響的參數(以5.6爲準）
innodb_adaptive_flushing 默認即可
innodb_change_buffer_max_size 如果是日值類服務，可以考慮把這個增值調到 50
innodb_change_buffering 默認即可
innodb_flush_neighors 默認是開的， 這個一定要開着，充分利用順序IO去寫數據。
innodb_lru_scan_depth: 默認即可 這個參數比較專業。
innodb_max_purge_lag 默認沒啓用，如果寫入和讀取都量大，可以保證讀取優先，可以考慮使用這個功能。
innodb_random_read_ahead 默認沒開啓，屬於一個比較活躍的參數，如果要用一定要多測試一下。 對用passport類應用可以考慮使用
innodb_read_ahead_threshold 默認開啓：56 預讀機制可以根據業務處理，如果是passprot可以考慮關閉。如果使用innodb_random_read_ahead,建議關閉這個功能
innodb_read_io_threads 默認爲：4 可以考慮8
innodb_write_io_threads 默認爲：4 可以考慮8
sync_binlog 默認即可： 0
innodb_rollback_segments 默認即可: 128
另外5.6的undo log也可以獨立配置了，建議單獨配置出來。
http://www.mysqlsupport.cn/innodb-io-optimize-conf
21、 innodb_read_io_threads = 8
#文件IO的線程數，一般爲 4，但是在 Windows 下，可以設置得較大。
22、 innodb_thread_concurrency = 16
#服務器有幾個CPU就設置爲幾，建議用默認設置，一般爲8.
23 、innodb_flush_log_at_trx_commit = 1
# 如果將此參數設置爲1，將在每次提交事務後將日誌寫入磁盤。爲提供性能，可以設置爲0或2，但要承擔在發生故障時丟失數據的風險。設置爲0表示事務日誌寫入日誌文件，而日誌文件每秒刷新到磁盤一次。設置爲2表示事務日誌將在提交時寫入日誌，但日誌文件每次刷新到磁盤一次。
24、 innodb_log_buffer_size = 8M
#這是 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 已經完成了磁盤同步。
25、 innodb_log_file_size = 256M
#此參數確定數據日誌文件的大小，以M爲單位，更大的設置可以提高性能，但也會增加恢復故障數據庫所需的時間
26、 innodb_log_files_in_group = 3
#爲提高性能，MySQL可以以循環方式將日誌文件寫到多個文件。推薦設置爲3M
27、 innodb_max_dirty_pages_pct = 90
# Buffer_Pool中Dirty_Page所佔的數量，直接影響InnoDB的關閉時間。參數innodb_max_dirty_pages_pct 可以直接控制了Dirty_Page在Buffer_Pool中所佔的比率，而且幸運的是innodb_max_dirty_pages_pct是可以動態改變的。所以，在關閉InnoDB之前先將innodb_max_dirty_pages_pct調小，強制數據塊Flush一段時間，則能夠大大縮短 MySQL關閉的時間。
http://www.taobaodba.com/html/221_innodb_max_dirty_pages_pct_checkpoint.html
28、 innodb_lock_wait_timeout = 120
# InnoDB 有其內置的死鎖檢測機制，能導致未完成的事務回滾。但是，如果結合InnoDB使用MyISAM的lock tables 語句或第三方事務引擎,則InnoDB無法識別死鎖。爲消除這種可能性，可以將innodb_lock_wait_timeout設置爲一個整數值，指示 MySQL在允許其他事務修改那些最終受事務回滾的數據之前要等待多長時間(秒數)
[mysqldump]
Quick
= 16M
指代mysql服務器端和客戶端在一次傳送數據包的過程當中數據包的大小
這個是定義mysql服務器端和客戶端在一次傳送數據包的過程當中數據包的大小
定義過大，比如max_allowed_packet=8092，有可能服務器端太忙，來不及接收，或者網絡太差，會容易造成丟包
定義過小，會因爲客戶端可能無法快速接收服務器端發過來的包，一般推薦是4096
[mysql]
no-auto-rehash
是自動補全的意思，就像我們在linux命令行裏輸入命令的時候，使用tab鍵的功能是一樣的
[myisamchk]
29、 key_buffer_size = 512M
#如果key_buffer_size設置太大，系統就會頻繁的換頁，降低系統性能。因爲MySQL使用操作系統的緩存來緩存數據，所以我們得爲系統留夠足夠的內存；在很多情況下數據要比索引大得多
http://www.cnblogs.com/sunss/archive/2011/03/11/1981373.html
30、 sort_buffer_size = 512M
#1 Sort_Buffer_Size 是一個connection級參數，在每個connection第一次需要使用這個buffer的時候，一次性分配設置的內存。
#2 Sort_Buffer_Size 並不是越大越好，由於是connection級的參數，過大的設置+高併發可能會耗盡系統內存資源。
#3 文檔說“On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation”
http://bbs.chinaunix.net/thread-1805254-1-1.html
31、 read_buffer = 8M
#主要用於表順序掃描的緩存，這個緩存的作用是不是多次查詢同一張表不用去磁盤取數據，直接從緩存中讀取(這裏有個疑問，如果數據發生了修改了緩存就會失效？)，還是僅僅只是作爲一次全表掃描的緩存，查詢完緩存空間直接釋放了，不會用於下一次查詢。
http://bbs.csdn.net/topics/390415865?page=1
32、 write_buffer = 8M
#cache和write buffer都是內置於CPU內部的一小段高速存儲器，cache中保存着最近一段時間被CPU使用過的內存數據，而write buffer則是用來應對內存的寫操作的，將原本要寫向內存的數據暫寫到write buffer中，等到CPU空閒的時候，數據纔會慢慢地被搬移到內存裏。
http://blog.chinaunix.net/uid-20662820-id-3917558.html
[mysqlhotcopy]
interactive-timeout
interactive_timeout是MySQL在等待一個活動連接關閉連接前等待的秒數
http://blog.itpub.net/26855487/viewspace-751504
[mysqld_safe]
open-files-limit = 8192
MySQL的變量open_files_limit，table_open_cache和max_connections是相互關聯的。如果對有些變量進行了設置，有的變量沒有設置，mysql會根據一定的計算公式進行計算得出其他的，當然有些時候會觸發mysql的一些警告來。具體的計算流程及如何得出最終的文件描述符有些許複雜
http://www.sudops.com/mysql-open-file-limit-max_connections-table-open-cache.html