mysql編譯安裝優化（mysql 優化配置）

本文目錄一覽：

• 1、小內存編譯安裝mysql要加什麼參數
• 2、在linux安裝MySQL時採用源碼編譯安裝，但是如何讓MySQL的編譯時間縮短呢？
• 3、網站訪問量大 怎樣優化mysql數據庫
• 4、數據庫如何優化
• 5、如何優化mysql寫入速

小內存編譯安裝mysql要加什麼參數

MySQL內存參數配置推薦：

1.慢查詢日誌：

slow_launch_time=2 查詢大於某個時間的值(單位：s)

slow_query_log=on/off 開啟關閉慢查詢日誌

slow_query_log_file=/opt/data/host-slow.log 慢查詢日誌位置

2.連接數:

max_connections MySQL最大連接數

back_log 當連接數滿了後，設置一個值，允許多少個連接進入等待堆棧

max_connect_errors 賬號連接到服務器允許的錯誤次數

connect_timeout 一個連接報文的最大時間(單位：s)

skip-name-resolve 加入my.cnf即可，MySQL在收到連接請求的時候，會根據請求包

中獲得的ip來反向追查請求者的主機名。然後再根據返回

的主機名又一次去獲取ip。如果兩次獲得的ip相同，那麼連接就成功建立了。

加了次參數，即可省去這個步驟

NOTES:

查詢當前連接數:show global status like ‘connections’;

3.key_buffer_size 索引緩存大小，是對MyISAM表性能影響最大的一個參數

32bit平台上，此值不要超過2GB，64bit平台不用做此限制，但也不要超過4GB

根據3點計算：

a.系統索引總大小

b.系統物理內存

c.系統當前keycache命中率

粗略計算公式：

Key_Size =key_number*(key_length+4)/0.67

Max_key_buffer_size

Threads_Usage = max_connections * (sort_buffer_size + join_buffer_size +

read_buffer_size+read_rnd_buffer_size+thread_stack)

key_cache_block_size ，是key_buffer緩存塊的單位長度，以字節為單位，默認值為1024。

key_cache_division_limit 控制着緩存塊重用算法。默認值為100，此值為key_buffer_size中暖鏈所佔的大小百分比(其中有暖鏈和熱鏈)，100意味着全是暖鏈。(類似於Oracle Data Buffer Cache中的default、keep、recycle)

key_cache_age_threshold 如果key_buffer里的熱鏈里的某個緩存塊在這個變量所設定的時間裡沒有被訪問過，MySQL服務器就會把它調整到暖鏈里去。這個參數值越大，緩存塊在熱鏈里停留的時間就越長。

這個參數默認值為 300，最小值為100。

Myisam索引默認是緩存在原始key_buffer中的，我們可以手動創建新的key_buffer，如在my.cnf中加入參數new_cache.key_buffer_size=20M。指定將table1和table2的索引緩存到new_cache的key_buffer中：

cache index table1,table2 in new_cache;

(之前默認的key_buffer為default，現在手動創建的為new_cache)

手動將table1和table2的索引載入到key_buffer中：

load index into cache table1,table2;

系統中記錄的與Key Cache相關的性能狀態參數變量： global status

◆Key_blocks_not_flushed，已經更改但還未刷新到磁盤的DirtyCacheBlock；

◆Key_blocks_unused，目前未被使用的CacheBlock數目；

◆Key_blocks_used，已經使用了的CacheBlock數目；

◆Key_read_requests，CacheBlock被請求讀取的總次數；

◆Key_reads，在CacheBlock中找不到需要讀取的Key信息後到“.MYI”文件中(磁盤)讀取的次數；

◆Key_write_requests，CacheBlock被請求修改的總次數；

◆Key_writes，在CacheBlock中找不到需要修改的Key信息後到“.MYI”文件中讀入再修改的次數；

索引命中緩存率：

key_buffer_read_hits=(1-Key_reads/Key_read_requests)*100%

key_buffer_write_hits=(1-Key_writes/Key_write_requests)*100%

該命中率就代表了MyISAM類型表的索引的cache

4.臨時表 tmp_table_size (用於排序)

show global status like ‘created_tmp%’;

| Variable_name | Value |

| Created_tmp_disk_tables | 21197 | #在磁盤上創建臨時表的次數

| Created_tmp_files | 58 | #在磁盤上創建臨時文件的次數

| Created_tmp_tables | 1771587 | #使用臨時表的總次數

TmpTable的狀況主要是用於監控MySQL使用臨時表的量是否過多，

是否有臨時表過大而不得不從內存中換出到磁盤文件上。

a.如果：

Created_tmp_disk_tables/Created_tmp_tables10%，則需調大tmp_table_size

比較理想的配置是：

Created_tmp_disk_tables/Created_tmp_tables=25%

b.如果：

Created_tmp_tables非常大 ，則可能是系統中排序操作過多，或者是表連接方式不是很優化。

相關參數：

tmp_table_size 內存中，臨時表區域總大小

max_heap_table_size 內存中，單個臨時表的最大值，超過的部分會放到硬盤上。

5.table cache相關優化 ：

參數table_open_cache，將表的文件描述符打開，cache在內存中

global status：

open_tables 當前系統中打開的文件描述符的數量

opened_tables 系統打開過的文件描述符的數量

如果：

Opened_tables數量過大，說明配置中table_open_cache值可能太小

比較合適的值為：

Open_tables / Opened_tables * 100% = 85%

Open_tables / table_open_cache * 100% = 95%

6.進程的使用情況

在MySQL中，為了儘可能提高客戶端請求創建連接這個過程的性能，實現了一個ThreadCache池，

將空閑的連接線程存放在其中，而不是完成請求後就銷毀。這樣，當有新的連接請求的時候，

MySQL首先會檢查ThreadCache池中是否存在空閑連接線程，如果存在則取出來直接使用，

如果沒有空閑連接線程，才創建新的連接線程。

參數：thread_cache_size

thread cache 池中存放的最大連接數

調整參考：

在短連接的數據庫應用中，數據庫連接的創建和銷毀是非常頻繁的，

如果每次都需要讓MySQL新建和銷毀相應的連接線程，那麼這個資源消耗實際上是非常大的，因此

thread_cache_size的值應該設置的相對大一些，不應該小於應用系統對數據庫的實際並發請求數。

參數：thread_stack – 每個連接線程被創建的時候，MySQL給他分配的內存大小，

類似PGA中存放數據的內存部分(不包括排序的空間)

show status like ‘connections’;

+—————+——-+

| Variable_name | Value |

+—————+——-+

| Connections | 80 | #接受到的來自客戶端的總連接數，包括以前和現在的連接。

+—————+——-+

show status like ‘thread%’;

+——————-+——-+

| Variable_name | Value |

+——————-+——-+

| Threads_cached | 0 | #當前系統中，緩存的連接數

| Threads_connected | 1 | #當前系統中正連接的線程數

| Threads_created | 77 | #創建過的總線程數

| Threads_running | 1 |

+——————-+——-+

a.如果：

Threads_created 值過大，說明MySQL一直在創建線程，這是比較消耗資源的，應該適當增大

thread_cache_size的值

b.如果：

Threads_cached的值比參數thread_cache_size小太多，則可以適當減小thread_cache_size的值

ThreadCache命中率：

Threads_Cache_Hit=(Connections-Threads_created)/Connections*100%

一般來說，當系統穩定運行一段時間之後，我們的ThreadCache命中率應該保持在90%

左右甚至更高的比率才算正常。

7.查詢緩存(Query Cache) — optional

將客戶端的SQL語句(僅限select語句)通過hash計算，放在hash鏈表中，同時將該SQL的結果集

放在內存中cache。該hash鏈表中，存放了結果集的內存地址以及所涉及到的所有Table等信息。

如果與該結果集相關的任何一個表的相關信息發生變化後(包擴：數據、索引、表結構等)，

就會導致結果集失效，釋放與該結果集相關的所有資源，以便後面其他SQL能夠使用。

當客戶端有select SQL進入，先計算hash值，如果有相同的，就會直接將結果集返回。

Query Cache的負面影響：

a.使用了Query Cache後，每條select SQL都要進行hash計算，然後查找結果集。對於大量SQL

訪問，會消耗過多額外的CPU。

b.如果表變更比較頻繁，則會造成結果集失效率非常高。

c.結果集中保存的是整個結果，可能存在一條記錄被多次cache的情況，這樣會造成內存資源的

過度消耗。

Query Cache的正確使用：

a.根據表的變更情況來選擇是否使用Query Cache，可使用SQL Hint：SQL_NO_CACHE和SQL_CACHE

b.對於 變更比較少 或 數據基本處於靜態 的表，使用SQL_CACHE

c.對於結果集比較大的，使用Query Cache可能造成內存不足，或擠占內存。

可使用1.SQL_NO_CACHE 2.query_cache_limit控制Query Cache的最大結果集(系統默認1M)

mysql show variables like ‘%query_cache%’;

+——————————+———+

| Variable_name | Value |

+——————————+———+

| have_query_cache | YES | #是否支持Query Cache

| query_cache_limit | 1048576 | #單個結果集的最大值，默認1M

| query_cache_min_res_unit | 4096 | #每個結果集存放的最小內存，默認4K

| query_cache_size | 0 | #Query Cache總內存大小，必須是1024的整數倍

| query_cache_type | ON | #ON,OFF,DEMAND(包含SQL_CACHE的查詢中才開啟)

| query_cache_wlock_invalidate | OFF |

+——————————+———+

#query_cache_wlock_invalidate：

針對於MyISAM存儲引擎，設置當有WRITELOCK在某個Table上面的時候，

讀請求是要等待WRITE LOCK釋放資源之後再查詢還是允許直接從QueryCache中讀取結果，

默認為FALSE（可以直接從QueryCache中取得結果）

此為部分內容，附上原文出處：

在linux安裝MySQL時採用源碼編譯安裝，但是如何讓MySQL的編譯時間縮短呢？

可以試試在使用make make install 時添加-j參數，不限制內核進行編譯安裝。或者-j 後加內核數 。例如 make -j 4 make install -j 4

優點：速度快會相對提高很多

缺點：消耗大量CPU，內存資源。

我做過一個測試，如果不限定內核 （16核 80GB內存 ）的服務器編譯安裝mysql 5.0.7 安裝時長大致在10分鐘左右，但是測試時服務器CPU跑滿100% ，內存消耗至少32GB。直接使用 make make install 安裝耗時45分鐘，內存4GB ，CPU 10%左右。

網站訪問量大 怎樣優化mysql數據庫

　單機MySQL數據庫的優化

一、服務器硬件對MySQL性能的影響

①磁盤尋道能力 （磁盤I/O），我們現在上的都是SAS15000轉的硬盤。MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁 盤I/O是制約MySQL性能的最大因素之一，對於日均訪 問量在100萬PV以上的Discuz!論壇，由於磁盤I/O的制約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案： 使用RAID1+0磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不會像你期待的那樣快。

②CPU 對於MySQL應用，推薦使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我現在比較喜歡DELL R710，也在用其作Linuxakg 虛擬化應用；

③物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存，不過內存對於現在的服務器而言可以說是一個可以忽略的問題，工作中遇到高端服務器基本上內存都超過了32G。

我們工作中用得比較多的數據庫服務器是HP DL580G5和DELL R710，穩定性和性能都不錯；特別是DELL R710，我發現許多同行都是採用它作數據庫的服務器，所以重點推薦下。

　 　二、MySQL的線上安裝我建議採取編譯安裝的方法，這樣性能上有較大提升，服務器系統我建議用64bit的Centos5.5，源碼包的編譯參數會默 認以Debgu模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，所以當我們編譯準備安裝的產品代碼時，一定不要忘記使用“— without-debug”參數禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二 個編譯參數設置為—all-static的話，可以告訴編譯器以靜態方式編譯和編譯結果代碼得到最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能 差距可能會達到5%至10%之多。我參考了簡朝陽先生的編譯參數，特列如下，供大家參考

./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎麼了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock

三、MySQL自身因素當解決了上述服務器硬件制約因素後，讓我們看看MySQL自身的優化是如何操作的。對 MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。

下面，根據以上硬件配置結合一份已經優化好的my.cnf進行說明：

#vim /etc/my.cnf

以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。

[mysqld]

port = 3306

serverid = 1

socket = /tmp/mysql.sock

skip-locking

#避免MySQL的外部鎖定，減少出錯幾率增強穩定性。

skip-name-resolve

#禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！

back_log = 384

　 　#back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。 如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自 己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。

key_buffer_size = 384M

#key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低！

max_allowed_packet = 4M

thread_stack = 256K

table_cache = 614K

sort_buffer_size = 6M

#查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨佔，如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。

read_buffer_size = 4M

#讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。

join_buffer_size = 8M

#聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。

myisam_sort_buffer_size = 64M

table_cache = 512

thread_cache_size = 64

query_cache_size = 64M

　 　#指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台觀察，如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不 夠 的情況；如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩 沖；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。

tmp_table_size = 256M

max_connections = 768

#指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提 示，則需要增大該參數值。

max_connect_errors = 1000

wait_timeout = 10

#指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。

thread_concurrency = 8

#該參數取值為服務器邏輯CPU數量*2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4*2=8；這個目前也是雙四核主流服務器配置。

skip-networking

#開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！

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

thread_cache_size=120

#默認為60

query_cache_size=32M

※值得注意的是：

很多情況需要具體情況具體分析

一、如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。

二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。

　 　很多時候我們發現，通過參數設置進行性能優化所帶來的性能提升，可能並不如許多人想象的那樣產生質的飛躍，除非是之前的設置存在嚴重不合理的情況。我們 不能將性能調優完全依託於通過DBA在數據庫上線後進行的參數調整，而應該在系統設計和開發階段就儘可能減少性能問題。

【51CTO獨家特稿】如果單MySQL的優化始終還是頂不住壓力時，這個時候我們就必須考慮MySQL的高可用架構（很多同學也愛說成是MySQL集群）了，目前可行的方案有：

一、MySQL Cluster

優勢：可用性非常高，性能非常好。每份數據至少可在不同主機存一份拷貝，且冗餘數據拷貝實時同步。但它的維護非常複雜，存在部分Bug，目前還不適合比較核心的線上系統，所以這個我不推薦。

二、DRBD磁盤網絡鏡像方案

　 　優勢：軟件功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足數據庫對數據一致 性的苛刻要求。但非分布式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於 MySQL Replication。另外，DRBD也是官方推薦的可用於MySQL高可用方案之一，所以這個大家可根據實際環境來考慮是否部署。

三、MySQL Replication

　 　在實際應用場景中，MySQL Replication是使用最為廣泛的一種提高系統擴展性的設計手段。眾多的MySQL使用者通過Replication功能提升系統的擴展性後，通過 簡單的增加價格低廉的硬件設備成倍 甚至成數量級地提高了原有系統的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。

比較常規的MySQL Replication架構也有好幾種，這裡分別簡單說明下

MySQL Replication架構一：常規複製架構–Master-slaves，是由一個Master複製到一個或多個Salve的架構模式，主要用於讀壓力大的應用數據庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。

MySQL Replication架構二：級聯複製架構，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。

MySQL Replication架構三：Dual Master與級聯複製結合架構，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的複製帶來的影響，而且保證了主Master的單點故障。

以上就是比較常見的MySQL replication架構方案，大家可根據自己公司的具體環境來設計 ，Mysql 負載均衡可考慮用LVS或Haproxy來做，高可用HA軟件我推薦Heartbeat。

　 　MySQL Replication的不足：如果Master主機硬件故障無法恢復，則可能造成部分未傳送到slave端的數據丟失。所以大家應該根據自己目前的網絡 規劃，選擇自己合理的Mysql架構方案，跟自己的MySQL DBA和程序員多溝涌，多備份（備份我至少會做到本地和異地雙備份），多測試，數據的事是最大的事，出不得半點差錯，切記切記。

數據庫如何優化

body{

line-height:200%;

}

如何優化MySQL數據庫

當MySQL數據庫邂逅優化，它有好幾個意思，今天我們所指的是性能優化。

我們究竟該如何對MySQL數據庫進行優化呢？下面我就從MySQL對硬件的選擇、Mysql的安裝、my.cnf的優化、MySQL如何進行架構設計及數據切分等方面來說明這個問題。

1.服務器物理硬件的優化

1)磁盤(I/O)，MySQL每一秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知，所以推薦使用RAID1+0磁盤陣列，如果資金允許，可以選擇固態硬盤做RAID1+0；

2)cpu對Mysql的影響也是不容忽視的，建議選擇運算能力強悍的CPU。

2.MySQL應該採用編譯安裝的方式

MySQL數據庫的線上環境安裝，我建議採取編譯安裝，這樣性能會較大的提升。

3.MySQL配置文件的優化

1)skip

-name

-resolve，禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間；

2)back_log

=

384，back_log指出在MySQL暫時停止響應新請求之前，短時間內的多少個請求可以被存在堆棧中，對於Linux系統而言，推薦設置小於512的整數。

3)如果key_reads太大，則應該把my.cnf中key_buffer_size變大，保持key_reads/key_read_requests至少在1/100以上，越小越好。

4.MySQL上線後根據status狀態進行適當優化

1)打開慢查詢日誌可能會對系統性能有一點點影響，如果你的MySQL是主-從結構，可以考慮打開其中一台從服務器的慢查詢日誌，這樣既可以監控慢查詢，對系統性能影響也會很小。

2)MySQL服務器過去的最大連接數是245，沒有達到服務器連接數的上限256，應該不會出現1040錯誤。比較理想的設置是：Max_used_connections/max_connections

*

100%

=85%

5.MySQL數據庫的可擴展架構方案

1)MySQL

cluster，其特點為可用性非常高，性能非常好，但它的維護非常複雜，存在部分Bug;

2)DRBD磁盤網絡鏡像方案，其特點為軟件功能強大，數據可在底層塊設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。

如何優化mysql寫入速

單機MySQL數據庫的優化

一、服務器硬件對MySQL性能的影響

①磁盤尋道能力 （磁盤I/O），我們現在上的都是SAS15000轉的硬盤。MySQL每秒鐘都在進行大量、複雜的查詢操作，對磁盤的讀寫量可想而知。所以，通常認為磁 盤I/O是制約MySQL性能的最大因素之一，對於日均訪 問量在100萬PV以上的Discuz!論壇，由於磁盤I/O的制約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案： 使用RAID1+0磁盤陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁盤陣列上的效率不會像你期待的那樣快。

②CPU 對於MySQL應用，推薦使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我現在比較喜歡DELL R710，也在用其作Linuxakg 虛擬化應用；

③物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存，不過內存對於現在的服務器而言可以說是一個可以忽略的問題，工作中遇到高端服務器基本上內存都超過了32G。

我們工作中用得比較多的數據庫服務器是HP DL580G5和DELL R710，穩定性和性能都不錯；特別是DELL R710，我發現許多同行都是採用它作數據庫的服務器，所以重點推薦下。

二、MySQL的線上安裝我建議採取編譯安裝的方法，這樣性能上有較大提升，服務器系統我建議用64bit的Centos5.5，源碼包的編譯參數會默 認以Debgu模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，所以當我們編譯準備安裝的產品代碼時，一定不要忘記使用“— without-debug”參數禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二 個編譯參數設置為—all-static的話，可以告訴編譯器以靜態方式編譯和編譯結果代碼得到最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能 差距可能會達到5%至10%之多。我參考了簡朝陽先生的編譯參數，特列如下，供大家參考

./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎麼了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock

三、MySQL自身因素當解決了上述服務器硬件制約因素後，讓我們看看MySQL自身的優化是如何操作的。對 MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。

下面，根據以上硬件配置結合一份已經優化好的my.cnf進行說明：

#vim /etc/my.cnf

以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。

[mysqld]

port = 3306

serverid = 1

socket = /tmp/mysql.sock

skip-locking

#避免MySQL的外部鎖定，減少出錯幾率增強穩定性。

skip-name-resolve

#禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！

back_log = 384

#back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。 如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自 己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。

key_buffer_size = 384M

#key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低！

max_allowed_packet = 4M

thread_stack = 256K

table_cache = 614K

sort_buffer_size = 6M

#查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨佔，如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。

read_buffer_size = 4M

#讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。

join_buffer_size = 8M

#聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。

myisam_sort_buffer_size = 64M

table_cache = 512

thread_cache_size = 64

query_cache_size = 64M

#指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台觀察，如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不 夠 的情況；如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩 沖；Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。

tmp_table_size = 256M

max_connections = 768

#指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提 示，則需要增大該參數值。

max_connect_errors = 1000

wait_timeout = 10

#指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。

thread_concurrency = 8

#該參數取值為服務器邏輯CPU數量*2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4*2=8；這個目前也是雙四核主流服務器配置。

skip-networking

#開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項！否則將無法正常連接！

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

thread_cache_size=120

#默認為60

query_cache_size=32M

※值得注意的是：

很多情況需要具體情況具體分析

一、如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。

二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。

很多時候我們發現，通過參數設置進行性能優化所帶來的性能提升，可能並不如許多人想象的那樣產生質的飛躍，除非是之前的設置存在嚴重不合理的情況。我們 不能將性能調優完全依託於通過DBA在數據庫上線後進行的參數調整，而應該在系統設計和開發階段就儘可能減少性能問題。

【51CTO獨家特稿】如果單MySQL的優化始終還是頂不住壓力時，這個時候我們就必須考慮MySQL的高可用架構（很多同學也愛說成是MySQL集群）了，目前可行的方案有：

一、MySQL Cluster

優勢：可用性非常高，性能非常好。每份數據至少可在不同主機存一份拷貝，且冗餘數據拷貝實時同步。但它的維護非常複雜，存在部分Bug，目前還不適合比較核心的線上系統，所以這個我不推薦。

二、DRBD磁盤網絡鏡像方案

優勢：軟件功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足數據庫對數據一致 性的苛刻要求。但非分布式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於 MySQL Replication。另外，DRBD也是官方推薦的可用於MySQL高可用方案之一，所以這個大家可根據實際環境來考慮是否部署。

三、MySQL Replication

在實際應用場景中，MySQL Replication是使用最為廣泛的一種提高系統擴展性的設計手段。眾多的MySQL使用者通過Replication功能提升系統的擴展性後，通過 簡單的增加價格低廉的硬件設備成倍 甚至成數量級地提高了原有系統的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。

比較常規的MySQL Replication架構也有好幾種，這裡分別簡單說明下

MySQL Replication架構一：常規複製架構–Master-slaves，是由一個Master複製到一個或多個Salve的架構模式，主要用於讀壓力大的應用數據庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。

MySQL Replication架構二：級聯複製架構，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。

MySQL Replication架構三：Dual Master與級聯複製結合架構，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的複製帶來的影響，而且保證了主Master的單點故障。

以上就是比較常見的MySQL replication架構方案，大家可根據自己公司的具體環境來設計 ，Mysql 負載均衡可考慮用LVS或Haproxy來做，高可用HA軟件我推薦Heartbeat。

MySQL Replication的不足：如果Master主機硬件故障無法恢復，則可能造成部分未傳送到slave端的數據丟失。所以大家應該根據自己目前的網絡 規劃，選擇自己合理的Mysql架構方案，跟自己的MySQL DBA和程序員多溝涌，多備份（備份我至少會做到本地和異地雙備份），多測試，數據的事是最大的事，出不得半點差錯，切記切記。