Mysql資料庫最佳化技術之配置篇、索引篇 （ 必看 必看 ）

(一) 減少資料庫訪問

對於可以靜態化的頁面，儘可能靜態化

對一個動態網頁面中可以靜態局部，採用靜態化

部分資料可以產生XML，或者文字檔形式儲存

使用資料緩衝技術，例如： MemCached

(二)最佳化的檢測方法

1.使用者體驗檢測

2.Mysql狀態檢測

在Mysql命令列裡面使用show status命令，得到當前mysql狀態。

主要關注下列屬性：

key_read_requests (索引讀的請求數）(key_buffer_size設定影響)

key_reads（索引讀響應數)

Key_blocks_used

Qcache_*

Open_tables(通過table_cache的設定影響)

Opened_tables

table_locks

3. 第三方工具檢測

mysqlreporthttp://hackmysql.com/mysqlreport

mytophttp://jeremy.zawodny.com/mysql/mytop/

系統及Mysql的Log

系統命令： top, sar

Mysql的Log: slow_query.log

(三)硬體方面的最佳化

硬體方面，最容易成為Mysql瓶頸的部分是磁碟，其次是CPU和記憶體

磁碟方面

使用更快的磁碟，會對Mysql有很好的協助

使用更多的硬碟，通過Raid，可以提高單塊磁碟速度的問題

對於Raid方式，建議採用Raid 0+1 或者 Raid 1+0

CPU

毫無疑問，更高主頻的CPU和更多的CPU數量可以給Mysql更

高的效能

記憶體

更高的記憶體，往往可以讓Mysql中的更多的資料緩衝在記憶體中，

但是，一個重要的因素是，需要有正確的Mysql的配置

網卡

使用千兆網卡及千兆網路

(四)作業系統方面的最佳化

1.不使用交換區。如果記憶體不足，增加更多的記憶體或配置你的系統使用較少記憶體

2. 不要使用NFS磁碟

3.增加系統和MySQL伺服器的開啟檔案數量

使用ulimit –n 65535

4.增加系統的進程和線程數量。

5.關閉不必要的應用，最佳化硬碟參數，使用hdparm測試

(五)應用級的最佳化

1.使用多伺服器負載平衡(多台讀和寫,用複製技術進行資料同步)

2.表的分區 (自訂分區,mysql5.1開始支援內建資料分割函數)

3.使用資料緩衝技術memcached

(六)Mysql配置的最佳化

1.key_buffer(=512):索引緩衝使用的記憶體數量

這對MyISAM表來說非常重要,設定在可用記憶體的25%-30%較好,通過檢查狀態值 Key_read_requests和 Key_reads,

可以知道key_buffer設定是否合理。比例key_reads / key_read_requests應該儘可能的低，至少是1:100，1:1000更好 ,否則說明 key_buffer 設定有點偏小

2.innodb_buffer_pool_size(= 512):索引緩衝使用的記憶體數量

3.table_cache (=1024):資料表緩衝區的尺寸

每當 MySQL 訪問一個表時，如果在表緩衝區中還有空間，該表就被開啟並放入其中，這樣可以更快地訪問表內容。

通過檢查運行峰值時間的 Open_tables 和 Opened_tables 狀態值，可以決定是否需要調整 table_cache 的值。

如果你發現 open_tables 的值等於 table_cache，並且發現 opened_tables 狀態值在不斷增長，那麼你就需要增加 table_cache 參數值了,

也不能盲目地把 table_cache 參數設定成很大的值，如果設定得太高，可能會造成檔案描述符不足，從而造成效能不穩定或者串連失敗。

4.sort_buffer_size (=256):指定排序用緩衝區的長度

該參數對應的分配記憶體是每串連獨佔！如果有100個串連，那麼實際分配的總共排序緩衝區大小為100 × 6 ＝ 600MB。

所以，對於記憶體在4GB左右的伺服器推薦設定為6-8M

5.join_buffer_size :關聯查詢用緩衝區的長度

4G記憶體以上，建議大於32M,該參數對應的分配記憶體也是每串連獨享！

6.max_connections (=1024):可以複用的線程數量

允許同時串連MySQL伺服器的客戶數量 ,可以觀察和估計系統在峰值最大的並發串連數來設定

7.thread_cache(=*):可以複用的線程數量

一般設定為CPU數×2

8.innodb_buffer_pool_size(= 512):innodb表緩衝池大小

這對Innodb表來說非常重要。Innodb相比MyISAM表對緩衝更為敏感。MyISAM可以在預設的 key_buffer_size 設定下啟動並執行可以，

然而Innodb在預設的innodb_buffer_pool_size 設定下卻跟蝸牛似的。

由於Innodb把資料和索引都緩衝起來，無需留給作業系統太多的記憶體，因此如果只需要用Innodb的話則可以設定它高達 70-80% 的可用記憶體。

一些應用於 key_buffer 的規則有 -- 如果你的資料量不大，並且不會暴增，那麼無需把innodb_buffer_pool_size 設定的太大了.

9.innodb_flush_logs_at_trx_commit(=1) :事務提交後的日誌重新整理模式

是否為Innodb比MyISAM慢1000倍而頭大?看來也許你忘了修改這個參數了。預設值是 1，這意味著每次提交的更新事務(或者每個事務之外的語句)都會重新整理到磁碟中，

而這相當耗費資源，尤其是沒有電池備用緩衝時。很多應用程式，尤其是從 MyISAM轉變過來的那些，把它的值設定為 2 就可以了，也就是不把日誌重新整理到磁碟上，

而只重新整理到作業系統的緩衝上。日誌仍然會每秒重新整理到磁碟中去，因此通常不會丟失每秒1-2次更新的消耗。如果設定為0就快很多了，不過也相對不安全了,

MySQL伺服器崩潰時就會丟失一些事務。設定為2指揮丟失重新整理到作業系統緩衝的那部分事務.

(七)表的最佳化

1. 選擇合適的資料引擎

MyISAM:適用於大量的讀操作的表

InnoDB:適用於大量的寫讀作的表

 

2.選擇合適的列類型

使用 SELECT * FROM TB_TEST PROCEDURE ANALYSE()可以對這個表的每一個欄位進行分析，給出最佳化列類型建議

 

3.對於不儲存NULL值的列使用NOT NULL，這對你想索引的列尤其重要

 

4.建立合適的索引

 

5.使用定長欄位,速度比變長要快

(八)建立索引原則

1.合理使用索引

一個Table在一次query中只能使用一個索引,使用EXPLAIN語句來檢驗最佳化程式的操作情況

使用analyze協助最佳化程式對索引的使用效果做出更準確的預測

2.索引應該建立在搜尋、排序、歸組等操作所涉及的資料列上

3.盡量將索引建立在重複資料少的資料列中，唯一所以最好

例如：生日列，可以建立索引，但性別列不要建立索引

4.盡量對比較短的值進行索引

降低磁碟IO操作，索引緩衝中可以容納更多的索引值，提高命中率

如果對一個長的字串建立索引，可以指定一個前置長度

5.合理使用多列索引

如果多個條件經常需要組合起來查詢,則要使用多列索引(因為一個表一次查詢只能使用一個索引,建立多個單列索引也只能使用一個)

6.充分利用最左首碼

也就是要合理安排多列索引中各列的順序，將最常用的排在前面

7.不要建立過多的索引

只有經常應用於where,order by,group by中的欄位需要建立索引.

8.利用慢查詢日誌尋找出慢查詢(log-slow-queries, long_query_time)

(九)充分利用索引

1.盡量比較資料類型相同的資料列

2.儘可能地讓索引列在比較運算式中獨立, WHERE mycol < 4 / 2 使用索引,而WHERE mycol * 2 < 4不使用

3.儘可能不對查詢欄位加函數,

如WHERE YEAR(date_col) < 1990改造成WHERE date_col < ’1990-01-01’

WHERE TO_DAYS(date_col) - TO_DAYS(CURDATE()) < cutoff 改造成WHERE date_col < DATE_ADD(CURDATE(), INTERVAL cutoff DAY)

4.在LIKE模式的開頭不要使用萬用字元5.使用straight join可以強制最佳化器按照FROM子句的次序來進行連接,可以select straight join,強制所有連接,也可以select * from a straight join b強制兩個表的順序.6.使用force index強制使用指定的索引.如 select * from song_lib force index(song_name) order by song_name比不用force index效率高7.盡量避免使用MySQL自動類型轉換,否則將不能使用索引.如將int型的num_col用where num_col=‘5’

(十)SQL語句的最佳化

1.建立合適的統計中間結果表，降低從大表查詢資料的幾率

2.盡量避免使用子查詢，而改用串連的方式.例如：

SELECT a.id, (SELECT MAX(created) FROM posts WHERE author_id = a.id) AS latest_post

FROM authors a

可以改成：

SELECT a.id, MAX(p.created) AS latest_post

FROM authors AS a

INNER JOIN posts p ON (a.id = p.author_id)

GROUP BY a.id

select song_id from song_lib where singer_id in

(select singer_id from singer_lib

where first_char='A'

) limit 2000改成:

select song_id from song_lib a

inner join singer_lib b on a.singer_id=b.singer_id and first_char='A' limit 2000

3.插入判斷重複鍵時,使用ON DUPLICATE KEY UPDATE :

insert into db_action.action_today(user_id,song_id,action_count) values(1,1,1) ON DUPLICATE KEY UPDATE action_count=action_count+1;

4.避免使用遊標

遊標的運行效率極低，可以通過增加暫存資料表，運用多表查詢，多表更新等方式完成任務,不要使用遊標.

(十一)使用Explain分析SQL語句使用索引的情況

當你在一條SELECT語句前放上關鍵詞EXPLAIN，MySQL解釋它將如何處理SELECT，提供有關表如何連接和以什麼次序連接的資訊,藉助於EXPLAIN，可以知道什麼時候必須為表加入索引以得到一個使用索引來尋找記錄的更快的SELECT,你也能知道最佳化器是否以一個最佳次序連接表。為了強制最佳化器對一個SELECT語句使用一個特定連接次序，增加一個STRAIGHT_JOIN子句。 。

EXPLAIN命令的一般文法是：EXPLAIN <SQL命令> 如：explain select * from a inner join b on a.id=b.id

EXPLAIN的分析結果參數詳解:

1.table：這是表的名字。

2.type：串連操作的類型。

system:表中僅有一條記錄（實際應用很少只有一條資料的表)

const:表最多有一個匹配行,用於用常數值比較PRIMARY KEY或UNIQUE索引的所有部分時,

如：select * from song_lib where song_id=2(song_id為表的primary key)

eq_ref:對於每個來自於前面的表的行組合，從該表中用UNIQUE或PRIMARY KEY的索引讀取一行,

如：select * from song_lib a inner join singer_lib b on a.singer_id=b.singer_id（b的type值為eq_ref)

ref:對於每個來自於前面的表的行組合，從該表中用非UNIQUE或PRIMARY KEY的索引讀取一行

如：select * from song_lib a inner join singer_lib b on a.singer_name=b.singer_name和

select * from singer_lib b where singer_name=‘ccc’ （b的type值為ref,因為b.singer_name是普通索引)

ref_or_null:該聯結類型如同ref，但是添加了MySQL可以專門搜尋包含NULL值的行,

如：select * from singer_lib where singer_name=‘ccc’ or singer_name is null

index_merge:該聯結類型表示使用了索引合并最佳化方法

Key： 它顯示了MySQL實際使用的索引的名字。如果它為空白（或NULL），則MySQL不使用索引。

key_len： 索引中被使用部分的長度，以位元組計。

3.ref：ref列顯示使用哪個列或常數與key一起從表中選擇行

4.rows： MySQL所認為的它在找到正確的結果之前必須掃描的記錄數。顯然，這裡最理想的數字就是1。

5.Extra：這裡可能出現許多不同的選項，其中大多數將對查詢產生負面影響。一般有：

using where：表示使用了where條件

using filesort: 表示使用了檔案排序,也就是使用了order by子句，並且沒有用到order by 裡欄位的索引，從而需要

額外的排序開銷，所以如果出現using filesort就表示排序的效率很低，需要進行最佳化,比如採用強制索引

的方法(force index)

===============================================

mysql 最佳化 （show variables， show status）。

安裝好mysql後，配製檔案應該在/usr/local/mysql/share/mysql目錄中，配製檔案有幾個，有my- huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網站和不同配製的伺服器環境，當然需要有不同的配製檔案了。

一般的情況下，my-medium.cnf這個配製檔案就能滿足我們的大多需要；一般我們會把設定檔拷貝到/etc/my.cnf 只需要修改這個設定檔就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的參數，有３個配置參數是最重要的，即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只對MyISAM表起作用，

key_buffer_size指定索引緩衝的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M,實際上稍微大一點的網站　這個數字是遠遠不夠的，通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設定是否合理。比例key_reads / key_read_requests應該儘可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。 或者如果你裝了phpmyadmin 可以通過伺服器運行狀態看到,筆者推薦用phpmyadmin管理mysql，以下的狀態值都是本人通過phpmyadmin獲得的執行個體分析:

這個伺服器已經運行了20天

key_buffer_size – 128M
key_read_requests – 650759289
key_reads - 79112

比例接近1:8000 健康情況非常好

另外一個估計key_buffer_size的辦法　把你網站資料庫的每個表的索引所佔空間大小加起來看看以此伺服器為例:比較大的幾個表索引加起來大概125M 這個數字會隨著表變大而變大。

從4.0.1開始，MySQL提供了查詢緩衝機制。使用查詢緩衝，MySQL將SELECT語句和查詢結果存放在緩衝區中，今後對於同樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。根據MySQL使用者手冊，使用查詢緩衝最多可以達到238%的效率。

通過調節以下幾個參數可以知道query_cache_size設定得是否合理

Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks

Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不夠的情況,同時Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，此時需要增加緩衝大小Qcache_hits的值不大，則表明你的查詢重複率很低，這種情況下使用查詢緩衝反而會影響效率，那麼可以考慮不用查詢緩衝。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩衝。

Qcache_free_blocks，如果該值非常大，則表明緩衝區中片段很多query_cache_type指定是否使用查詢緩衝

我設定:

query_cache_size = 32M
query_cache_type= 1

得到如下狀態值:

Qcache queries in cache 12737 表明目前緩衝的條數
Qcache inserts 20649006
Qcache hits 79060095 　看來重複查詢率還挺高的
Qcache lowmem prunes 617913　有這麼多次出現緩衝過低的情況
Qcache not cached 189896 　　
Qcache free memory 18573912　　目前剩餘緩衝空間
Qcache free blocks 5328 這個數字似乎有點大　片段不少
Qcache total blocks 30953

如果記憶體允許32M應該要往上加點

table_cache指定表快取的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被開啟並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設定成很大的值。如果設定得太高，可能會造成檔案描述符不足，從而造成效能不穩定或者串連失敗。

對於有1G記憶體的機器，推薦值是128－256。

筆者設定table_cache = 256

得到以下狀態:

Open tables 256
Opened tables 9046

雖然open_tables已經等於table_cache，但是相對於伺服器已耗用時間來說,已經運行了20天，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。如果運行了6個小時就出現上述值 那就要考慮增大table_cache。

如果你不需要記錄2進位log 就把這個功能關掉，注意關掉以後就不能恢複出問題前的資料了，需要您手動備份，二進位日誌包含所有更新資料的語句，其目的是在恢複資料庫時用它來把資料儘可能恢複到最後的狀態。另外，如果做同步複製( Replication )的話，也需要使用二進位記錄傳送修改情況。

log_bin指定記錄檔，如果不提供檔案名稱，MySQL將自己產生預設檔案名稱。MySQL會在檔案名稱後面自動添加數字引，每次啟動服務時，都會重建一個新的二進位檔案。此外，使用log-bin-index可以指定索引檔案；使用binlog-do-db可以指定記錄的資料庫；使用binlog-ignore-db可以指定不記錄的資料庫。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個資料庫，指定多個資料庫需要多個語句。而且，MySQL會將所有的資料庫名稱改成小寫，在指定資料庫時必須全部使用小寫名字，否則不會起作用。

關掉這個功能只需要在他前面加上#號

#log-bin

開啟慢查詢日誌( slow query log ) 慢查詢日誌對於跟蹤有問題的查詢非常有用。它記錄所有查過long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個慢查詢日誌的例子：

開啟慢查詢日誌，需要設定參數log_slow_queries、long_query_times、log-queries-not-using-indexes。

log_slow_queries指定記錄檔，如果不提供檔案名稱，MySQL將自己產生預設檔案名稱。long_query_times指定慢查詢的閾值，預設是10秒。log-queries-not-using-indexes是4.1.0以後引入的參數，它指示記錄不使用索引的查詢。筆者設定long_query_time=10

筆者設定:

sort_buffer_size = 1M
max_connections=120
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
interactive_timeout=120
thread_concurrency = 4

參數說明:

back_log

要求MySQL能有的串連數量。當主要MySQL線程在一個很短時間內得到非常多的串連請求，這就起作用，然後主線程花些時間(儘管很短) 檢查串連並且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多串連，你需要增加它，換句話說，這值對到來的TCP/IP串連的偵聽隊列的大小。你的作業系統在這個隊列大小上有它自己的限制。 Unix listen(2)系統調用的手冊頁應該有更多的細節。檢查你的OS文檔找出這個變數的最大值。試圖設定back_log高於你的作業系統的限制將是無效的。

max_connections

並發串連數目最大，120 超過這個值就會自動回復，出了問題能自動解決

thread_cache

沒找到具體說明，不過設定為32後 20天才建立了400多個線程 而以前一天就建立了上千個線程 所以還是有用的

thread_concurrency

#設定為你的cpu數目x2,例如，只有一個cpu,那麼thread_concurrency=2
#有2個cpu,那麼thread_concurrency=4
skip-innodb
#去掉innodb支援

代碼:
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
#socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 128M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
net_buffer_length = 16K
myisam_sort_buffer_size = 1M
max_connections=120
#addnew config
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
skip-innodb
skip-bdb
skip-name-resolve
join_buffer_size=512k
query_cache_size = 32M
interactive_timeout=120
long_query_time=10
log_slow_queries= /usr/local/mysql4/logs/slow_query.log
query_cache_type= 1
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

補充

最佳化table_cachetable_cache指定表快取的大小。每當MySQL訪問一個表時，如果在表緩衝區中還有空間，該表就被開啟並放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值Open_tables和Opened_tables，可以決定是否需要增加 table_cache的值。如果你發現open_tables等於table_cache，並且opened_tables在不斷增長，那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設定成很大的值。如果設定得太高，可能會造成檔案描述符不足，從而造成效能不穩定或者串連失敗。對於有1G記憶體的機器，推薦值是128－256。

案例1：該案例來自一個不是特別繁忙的伺服器table_cache – 512open_tables – 103 opened_tables – 1273 uptime – 4021421 (measured in seconds)該案例中table_cache似乎設定得太高了。在峰值時間，開啟表的數目比table_cache要少得多。

案例2：該案例來自一台程式開發伺服器。table_cache – 64open_tables – 64opened-tables – 431uptime – 1662790 (measured in seconds)雖然open_tables已經等於table_cache，但是相對於伺服器已耗用時間來說，opened_tables的值也非常低。因此，增加table_cache的值應該用處不大。
案例3：該案例來自一個upderperforming的伺服器table_cache – 64 open_tables – 64 opened_tables – 22423uptime – 19538該案例中table_cache設定得太低了。雖然已耗用時間不到6小時，open_tables達到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。最佳化key_buffer_sizekey_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得知詳情。對於1G記憶體的機器，如果不使用 MyISAM表，推薦值是16M（8-64M）。

案例1：健康情況key_buffer_size – 402649088 (384M) key_read_requests – 597579931 key_reads - 56188案例2：警報狀態key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads - 53832731案例1中比例低於1:10000，是健康的情況；案例2中比例達到1:11，警報已經拉響。================================

Mysql調優中兩個重要參數table_cache和key_buffer

本文根據我自己的一點經驗，討論了Mysql伺服器最佳化中兩個非常重要的參數，分別是table_cache，key_buffer_size。   table_cache指示表快取的大小。當Mysql訪問一個表時，如果在Mysql表緩衝區中還有空間，那麼這個表就被開啟並放入表緩衝區，這樣做的好處是可以更快速地訪問表中的內容。一般來說，可以通過查看資料庫運行峰值時間的狀態值Open_tables和Opened_tables，用以判斷是否需要增加table_cache的值，即如果open_tables接近table_cache的時候，並且Opened_tables這個值在逐步增加，那就要考慮增加這個值的大小了。   在mysql預設安裝情況下，table_cache的值在2G記憶體以下的機器中的值預設時256到512，如果機器有4G記憶體,則預設這個值是2048，但這決意味著機器記憶體越大，這個值應該越大，因為table_cache加大後，使得mysql對SQL響應的速度更快了，不可避免的會產生更多的死結（dead lock），這樣反而使得資料庫整個一套操作慢了下來，嚴重影響效能。所以平時維護中還是要根據庫的實際情況去作出判斷，找到最適合你維護的庫的table_cache值，有人說：“效能最佳化是一門藝術”，這話一點沒錯。大凡藝術品，大都是經過千錘百鍊，精雕細琢而成。    這裡還要說明一個問題，就是table_cache加大後碰到檔案描述符不夠用的問題，在mysql的設定檔中有這麼一段提示 引用 “The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires. Therefore you have to make sure to set the amount of open files allowed to at least 4096 in the variable "open-files-limit" in” section [mysqld_safe]” 說的就是要注意這個問題，一想到這裡，部分兄弟可能會用ulimit -n 作出調整，但是這個調整實際是不對的，換個終端後，這個值又會回到原始值，所以最好用sysctl或者修改/etc/sysctl.conf檔案，同時還要在設定檔中把open_files_limit這個參數增大，對於4G記憶體伺服器，相信現在購買的伺服器都差不多用4G的了，那這個這個open_files_limit至少要增大到4096，如果沒有什麼特殊情況，設定成8192就可以了。    下面說說key_buffer_size這個參數，key_buffer_sizeO表示索引緩衝的大小，嚴格說是它決定了資料庫索引處理的速度，尤其是索引讀的速度。根據網路一些高手寫的文章表示可以檢查狀態值Key_read_requests和Key_reads，即可知道key_buffer_size設定是否合理。比例key_reads / key_read_requests應該儘可能的低，至少是1:100，1:1000更好，雖然我還沒有找到理論的依據，但是，我在自己維護的幾台實際運行良好的庫做過的測試後表明，這個比值接近1：20000，這從結果證明了他們說這話的正確性，我們不妨用之。 後記：    我前面說過，效能最佳化是一件細活，影響mysql效能的因素很多，本文中只是選取了其中我認為比較重要的兩個參數，期待和網友一起探討更多mysql效能最佳化的技術。