在apache, php, mysql的體系架構中，mysql對於效能的影響最大，也是關鍵的核心部分。對於discuz!論壇程式也是如此，mysql的設定是否合理優化，直接 影響到論壇的速度和承載量！同時，mysql也是優化難度最大的乙個部分，不但需要理解一些mysql專業知識，同時還需要長時間的觀察統計並且根據經驗 進行判斷，然後設定合理的引數。
下面我們了解一下mysql優化的一些基礎，mysql的優化我分為兩個部分，一是伺服器物理硬體的優化，二是mysql自身(my.cnf)的優化。
一、伺服器硬體對mysql效能的影響
① 磁碟尋道能力（磁碟i/o）,以目前高轉速scsi硬碟(7200轉/秒)為例，這種硬碟理論上每秒尋道7200次，這是物理特性決定的，沒有辦法改變。 mysql每秒鐘都在進行大量、複雜的查詢操作，對磁碟的讀寫量可想而知。所以，通常認為磁碟i/o是制約mysql效能的最大因素之一，對於日均訪問量 在100萬pv以上的discuz!論壇，由於磁碟i/o的制約，mysql的效能會非常低下！解決這一制約因素可以考慮以下幾種解決方案： 使用raid-0+1磁碟陣列，注意不要嘗試使用raid-5，mysql在raid-5磁碟陣列上的效率不會像你期待的那樣快。
②cpu 對於mysql應用，推薦使用s.m.p.架構的多路對稱cpu，例如：可以使用兩顆intel xeon 3.6ghz的cpu，現在我較推薦用4u的伺服器來專門做資料庫伺服器，不僅僅是針對於mysql。
③物理記憶體對於一台使用mysql的database server來說，伺服器記憶體建議不要小於2gb，推薦使用4gb以上的物理記憶體，不過記憶體對於現在的伺服器而言可以說是乙個可以忽略的問題，工作中遇到了高階伺服器基本上記憶體都超過了16g。
二、 mysql自身因素
當解決了上述伺服器硬體制約因素後，讓我們看看mysql自身的優化是如何操作的。對mysql自身的優化主要是對其配置檔案 my.cnf中的各項引數進行優化調整。下面我們介紹一些對效能影響較大的引數。 由於my.cnf檔案的優化設定是與伺服器硬體配置息息相關的，因而我們指定乙個假想的伺服器硬體環境：
下面，我們根據以上硬體配置結合乙份已經優化好的my.cnf進行說明：
**如下 複製**
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
skip-name-resolve
back_log = 384
key_buffer_size = 256m
max_allowed_packet = 4m
thread_stack = 256k
table_cache = 128k
sort_buffer_size = 6m
read_buffer_size = 4m
join_buffer_size = 8m
myisam_sort_buffer_size = 64m
table_cache = 512
thread_cache_size = 64
query_cache_size = 64m
tmp_table_size = 256m
max_connections = 768
max_connect_errors = 10000000
wait_timeout = 10
thread_concurrency = 8
skip-networking
table_cache=1024
innodb_additional_mem_pool_size=4m
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=2m
innodb_thread_concurrency=8
key_buffer_size=256m
tmp_table_size=64m
read_buffer_size=4m
read_rnd_buffer_size=16m
sort_buffer_size=32m
thread_cache_size=120
query_cache_size=32m
如果從資料庫平台應用出發，我還是會首選myisam.
ps:可能有人會說你myisam無法抗太多寫操作，但是我可以通過架構來彌補，說個我現有用的資料庫平台容量：主從資料總量在幾百t以上，每天十多億 pv的動態頁面，還有幾個大專案是通過資料介面方式呼叫未算進pv總數，(其中包括乙個大專案因為初期memcached沒部署,導致單台資料庫每天處理 9千萬的查詢)。而我的整體資料庫伺服器平均負載都在0.5-1左右。
myisam和innodb優化：
key_buffer_size – 這對myisam表來說非常重要。如果只是使用myisam表，可以把它設定為可用記憶體的 30-40%。合理的值取決於索引大小、資料量以及負載 — 記住，myisam表會使用作業系統的快取來快取資料，因此需要留出部分記憶體給它們，很多情況下資料比索引大多了。儘管如此，需要總是檢查是否所有的 key_buffer 都被利用了 — .myi 檔案只有 1gb，而 key_buffer 卻設定為 4gb 的情況是非常少的。這麼做太浪費了。如果你很少使用myisam表，那麼也保留低於 16-32mb 的 key_buffer_size 以適應給予磁碟的臨時表索引所需。
innodb_buffer_pool_size – 這對innodb表來說非常重要。innodb相比myisam表對緩衝更為敏感。myisam可以在預設的 key_buffer_size 設定下執行的可以，然而innodb在預設的 innodb_buffer_pool_size 設定下卻跟蝸牛似的。由於innodb把資料和索引都快取起來，無需留給作業系統太多的記憶體，因此如果只需要用innodb的話則可以設定它高達 70-80% 的可用記憶體。一些應用於 key_buffer 的規則有 — 如果你的資料量不大，並且不會暴增，那麼無需把 innodb_buffer_pool_size 設定的太大了。
innodb_additional_pool_size – 這個選項對效能影響並不太多，至少在有差不多足夠記憶體可分配的作業系統上是這樣。不過如果你仍然想設定為 20mb(或者更大)，因此就需要看一下innodb其他需要分配的記憶體有多少。
innodb_log_file_size 在高寫入負載尤其是大資料集的情況下很重要。這個值越大則效能相對越高，但是要注意到可能會增加恢復時間。我經常設定為 64-512mb，跟據伺服器大小而異。
innodb_log_buffer_size 默 認的設定在中等強度寫入負載以及較短事務的情況下，伺服器效能還可 以。如果存在更新操作峰值或者負載較大，就應該考慮加大它的值了。如果它的值設定太高了，可能會浪費記憶體 — 它每秒都會重新整理一次，因此無需設定超過1秒所需的記憶體空間。通常 8-16mb 就足夠了。越小的系統它的值越小。
innodb_flush_logs_at_trx_commit 是否為innodb比myisam慢1000倍而頭大？看來也許你忘了修改這個引數了。預設值是 1，這意味著每次提交的更新事務（或者每個事務之外的語句）都會重新整理到磁碟中，而這相當耗費資源，尤其是沒有電池備用快取時。很多應用程式，尤其是從 myisam轉變過來的那些，把它的值設定為 2 就可以了，也就是不把日誌重新整理到磁碟上，而只重新整理到作業系統的快取上。日誌仍然會每秒重新整理到磁碟中去，因此通常不會丟失每秒1-2次更新的消耗。如果設定 為 0 就快很多了，不過也相對不安全了 — mysql伺服器崩潰時就會丟失一些事務。設定為 2 指揮丟失重新整理到作業系統快取的那部分事務。
thread_cache — 執行緒的建立和銷毀的開銷可能很大，因為每個執行緒的連線/斷開都需要。我通常至少設定為 16。如果應用程式中有大量的跳躍併發連線並且 threads_created 的值也比較大，那麼我就會加大它的值。它的目的是在通常的操作中無需建立新執行緒。
query_cache — 如果你的應用程式有大量讀，而且沒有應用程式級別的快取，那麼這很有用。不要把它設定太大了，因為想要維護它也需要不少開銷，這會導致mysql變慢。通 常設定為 32-512mb。設定完之後最好是跟蹤一段時間，檢視是否執行良好。在一定的負載壓力下，如果快取命中率太低了，就啟用它。
sort_buffer_size –如果你只有一些簡單的查詢，那麼就無需增加它的值了，儘管你有 64gb 的記憶體。搞不好也許會降低效能。
MySQL資料庫高併發優化配置
在apache,php,mysql的體系架構中，mysql對於效能的影響最大，也是關鍵的核心部分。對於discuz 論壇程式也是如此，mysql的設定是否合理優化，直接 影響到論壇的速度和承載量！同時，mysql也是優化難度最大的乙個部分，不但需要理解一些mysql專業知識，同時還需要長時間的觀察統...
MySQL 高併發配置優化
最近在搞乙個報表系統，不是很負責，但是就是資料量比較大，單次寫入上萬條資料，加上在同乙個事務裡面，部署到linux伺服器後，發現特別慢，後面發現mysql安裝後沒有優化配置檔案，導致寫入特別慢。伺服器mysql版本 mysql配置檔案預設路徑 vim etc my.cnf 配置後重啟 service...
mysql資料庫高併發處理
總體思想 短,少,分流 短 1.頁面靜態化,2.使用快取 3.使用儲存過程,對於處理一次請求需要多次訪問資料庫的操作,將操作整合到儲存過程,這樣只需要一次資料庫訪問 4.延遲修改,將修改請求儲存到記憶體中,但可能會斷電丟失資料 5.使用索引 少 1.分表,但應盡量避免多表關聯查詢 2.分離活躍資料,...