本次的開放測試依然在進行中，昨天關於卡建號的問題大家討論了一下解決辦法，對邏輯方面也檢查了一下，不過邏輯方面很久都沒人改過了，如果出問題應該兩個專案都出問題，結果另外一個從來不卡的，所以應該不是邏輯上的問題，結果去檢查MySQL的配置，才發現了原因。

是MySQL中打Log過於頻繁導致的原因，原來的配置是 innodb_flush_log_at_trx_commit = 1，有一條處理就等待寫LLog到磁碟，寫入磁碟想對耗時比價多，所以非常卡，本次測試引數是1的測試結果是60-90毫秒，修改成2之後，使用客戶端建立一個角色的時間是0 ms，用機器人建立1000個角色壓力測試的結果是13ms，這個結果還可以接受，1分鐘3000多賬號，完全可以理解。前面運維測試的時間是200ms一個，所以呢，又被玩家罵了一頓啊，悲慘的命運。

簡單搜了一下MySQL優化的配置給大家分享下：

my.ini配置建議：

table_cache=1024
實體記憶體越大,設定就越大.預設為2402,調到512-1024最佳

innodb_additional_mem_pool_size=4M
預設為2M

innodb_flush_log_at_trx_commit=1
(設定為0就是等到innodb_log_buffer_size列隊滿後再統一儲存,預設為1)

innodb_log_buffer_size=2M
預設為1M

innodb_thread_concurrency=8
你的伺服器CPU有幾個就設定為幾,建議用預設一般為8

key_buffer_size=256M
預設為218         調到128最佳

tmp_table_size=64M
預設為16M        調到64-256最掛

read_buffer_size=4M
預設為64K

read_rnd_buffer_size=16M
預設為256K

sort_buffer_size=32M
預設為256K

max_connections=1024
預設為1210

thread_cache_size=120
預設為60

query_cache_size=32M

以下是另一個的my.ini配置建議：

port=3306
default-character-set=latin1
default-storage-engine=INNODB
sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_Create_USER,NO_ENGINE_SUBSTITUTION”

max_connections=120
query_cache_size=32M

#快取資料表數量,設定這個引數可以參見系統狀態中的 open_tables(表示當前開啟的資料表總數) 和 opened_tables(表示所有開啟的資料表總數)
table_cache=256

#臨時表的大小
tmp_table_size=12M

#快取可重用的執行緒數
thread_cache_size = 64

myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=64M

#這對MyISAM表來說非常重要。如果只是使用MyISAM表，可以把它設定為可用記憶體的 30-40%。合理的值取決於索引大小、資料量以及負載 — #記住，MyISAM表會使用作業系統的快取來快取資料，因此需要留出部分記憶體給它們，很多情況下資料比索引大多了。
key_buffer_size=128M

read_buffer_size=1M
read_rnd_buffer_size=512K
sort_buffer_size=1M

#這對innodb表來說非常重要
innodb_buffer_pool_size = 256M

#這取決於你需要的回覆速度.128M這個數值是適當的恢復時間和良好效能之間的一個好的平衡.
innodb_log_file_size = 128M

#大多數情況4M足夠,除非正將很大的blob資料匯入到Innodb中可以增加一點.
innodb_log_buffer_size=4M

#這個值取決於你的程式,可能高或者低.8是代表起始值.
innodb_thread_concurrency=8

innodb_additional_mem_pool_size=100M

#如果你不是很關心ACID,可以容許在系統完全crash的情況下丟失最後一兩秒的事務,那麼可以設定這個值.它可以極大的提高”短”的寫事務的效率.
innodb_flush_log_at_trx_commit=2
注意：
很多情況需要具體情況具體分析
1>如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
2>如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值

晚上聽到一個很悲劇的訊息，我們小組長和頭因為運維發了一個帶%的公告，導致伺服器宕機，被扣錢了，沒有做特殊字元檢測，同時忘記告訴運維了，這個本來應該是運維平臺發訊息過來，在發之前應該就遮蔽掉的，結果兩邊都沒有做檢查，就出現悲劇的事情了。下次還是小心一些微妙，仔細認真的態度做任何事情總是沒錯的。