MySQL除了有些表類型會用到事務(wù)日志外，還使用了7種日志文件，這些日志文件都是可選項。

二進制日志存儲修改數(shù)據(jù)庫中表數(shù)據(jù)的所有動作，包含了所有更新了數(shù)據(jù)或者已經(jīng)潛在更新了數(shù)據(jù)的所有語句。潛在跟新了數(shù)據(jù)的SQL語句例如：無法匹配行的DELETE語句；設(shè)置列為當(dāng)前值的UPDATE語句。除此之外，該日志還存儲了語句執(zhí)行期間耗時的相關(guān)信息。二進制日志文件以一種更有效并且是事務(wù)安全的方式包含更新日志中可用的所有信息。MySQL在執(zhí)行語句之后，但在釋放鎖之前，馬上將修改寫入二進制日志中，

       使用--log-bin[=file_name]選項啟動該日志類型，mysqld寫入包含所有更新數(shù)據(jù)的SQL命令的日志文件。如果未給出file_name值，默認名為“HOSTNAME-bin.nnnnn”；如果給出了文件名，但沒有包含路徑，則文件被寫入數(shù)據(jù)目錄。如果在日志名中提供了擴展名(例如，--log-bin=file_name.extension)，則擴展名被悄悄除掉并忽略。二進制日志文件名的.nnnn表示，mysqld在每個二進制日志名后面添加一個數(shù)字擴展名。每次啟動服務(wù)器或刷新日志（flush logs）時該數(shù)字增加1。如果當(dāng)前的日志大小達到設(shè)定的max_binlog_size，還會自動創(chuàng)建新的二進制日志。如果在該文件的末尾正使用大的事務(wù)，二進制日志還有肯呢個會超過max_binlog_size：事務(wù)全寫入一個二進制日志中，絕對不要寫入不同的二進制日志中。

--binlog-do-db=db_name

告訴主服務(wù)器，如果當(dāng)前的數(shù)據(jù)庫(即USE選定的數(shù)據(jù)庫)是db_name，應(yīng)將更新記錄到二進制日志中。其它所有沒有明顯指定的數(shù)據(jù)庫被忽略。

如果數(shù)據(jù)庫啟動時使用選項--binlog-do-db=DB_A，使用語句“use DB_B”置DB_B為當(dāng)前數(shù)據(jù)庫，此時使用update語句修改DB_A的表數(shù)據(jù)時出現(xiàn)如下情況：

數(shù)據(jù)庫DB_B不在允許binlog的列表內(nèi)，該語句不寫入二進制日志文件

數(shù)據(jù)庫DB_B在允許binlog的列表內(nèi)，該語句寫入二進制日志文件

--binlog-ignore-db=db_name

告訴主服務(wù)器，如果當(dāng)前的數(shù)據(jù)庫(即USE選定的數(shù)據(jù)庫)是db_name，不將更新保存到二進制日志中。

如果數(shù)據(jù)庫啟動時使用選項--binlog-ignore-db=DB_A，使用語句“use DB_B”置DB_B為當(dāng)前數(shù)據(jù)庫，此時使用update語句修改DB_A的表數(shù)據(jù)時出現(xiàn)如下情況：

數(shù)據(jù)庫DB_B不在允許binlog的列表內(nèi)，該語句不寫入二進制日志文件

數(shù)據(jù)庫DB_B在允許binlog的列表內(nèi)，該語句寫入二進制日志文件

       綜上所述，使用這個兩個選項時決定是否將該語句寫入日志文件還有參考當(dāng)前數(shù)據(jù)庫的屬性，如果指定了這兩個選項盡量使指定的數(shù)據(jù)庫為當(dāng)前數(shù)據(jù)庫，才能按照邏輯來記錄日志。但CREATE DATABASE、ALTER DATABASE和DROP DATABASE等語句，有一個例外，即通過操作的數(shù)據(jù)庫來決定是否應(yīng)記錄語句。

如果使用調(diào)試的方式來編譯MySQL客戶機或服務(wù)器，則可以生成一個調(diào)試日志文件。默認情況下，MySQL將調(diào)試日志寫到/tmp/mysql.trace，也可以使用debug命令行選項來修改該位置。

該日志文件包含了當(dāng)mysqld啟動和停止時，以及服務(wù)器在運行過程中發(fā)生任何嚴重錯誤時的相關(guān)信息。可以用--log-error[=file_name]選項來指定mysqld保存錯誤日志文件的位置。

當(dāng)使用mysqld_safe啟動服務(wù)器時，該腳本自動在啟動項上加上--log-error但沒有加上file_name，或者直接在libexec目錄下使用./mysqld --user=mysql  --log-error啟動服務(wù)器，此時沒有給定file_name值，mysqld將使用錯誤日志名host_name.err 并在數(shù)據(jù)目錄中寫入日志文件。

將錯誤信息寫入錯誤日志文件的原理是，服務(wù)器將對標(biāo)準(zhǔn)錯誤輸出重定向到該日志文件，所以如果不指定--log-error，錯誤被寫入標(biāo)準(zhǔn)錯誤輸出stderr，通常標(biāo)準(zhǔn)輸出為你的終端。如果在程序中有printf等語句的話，這些函數(shù)打印出的信息也被寫入該日志文件。

如果執(zhí)行FLUSH LOGS，錯誤日志用-old重新命名后綴并且mysqld創(chuàng)建一個新的空日志文件。如第一次生成的錯誤日志為：linux-8tpn.err。執(zhí)行該命令后將該文件重命名為：linux-8tpn.err-old。

該日志文件供MySQL開發(fā)小組使用該日志來調(diào)試MyISAM表處理器。使用--log-isam選項開啟該日志類型，服務(wù)器在數(shù)據(jù)目錄下創(chuàng)建myisam.log文件。

可以使用myisamlog使用程序從myisam.log文件中提取統(tǒng)計信息，除非用戶正在調(diào)試MyISAM表處理器，否則對該日志可能不感興趣。

下面為使用myisamlog的輸出實例，暫不清楚各項是什么意思。

該日志文件記錄服務(wù)器上所做的所有查詢。可以使用--log[=file_name]或-l [file_name]選項啟動它。如果沒有給定file_name的值， 默認名是host_name.log；如果file_name為絕對路徑則在該目錄下創(chuàng)建日志文件，否則在數(shù)據(jù)目錄下創(chuàng)建該日志文件。

mysqld按照它接收的順序而不是按照語句執(zhí)行的順序記錄語句到查詢?nèi)罩?。這就有可能與執(zhí)行的順序不同。與更新日志和二進制日志不同，它們在查詢執(zhí)行后，但是任何一個鎖釋放之前記錄日志。(查詢?nèi)罩具€包含所有語句，而二進制日志不包含只查詢數(shù)據(jù)的語句）。

服務(wù)器重新啟動和日志刷新不會產(chǎn)生新的一般查詢?nèi)罩疚募?/span>(盡管刷新關(guān)閉并重新打開一般查詢?nèi)罩疚募?/span>)。在所有日志類型中查詢?nèi)罩驹鲩L的最快，不要不間斷的運行查詢?nèi)罩尽?/span>

該日志類型用來收集那些花費太長時間（超過指定時間）執(zhí)行的SQL語句，該指定時間由long_query_time服務(wù)器變量設(shè)定。用--log-slow-queries[=file_name]選項啟動，如果沒有給出file_name值，默認未主機名，后綴為-slow.log，如果給出了文件名，但不是絕對路徑名，文件則寫入數(shù)據(jù)目錄。

慢查詢?nèi)罩究梢杂脕碚业綀?zhí)行時間長的查詢，可以用于優(yōu)化\，使用mysqldumpslow命令獲得日志中顯示的查詢摘要來處理慢查詢?nèi)罩尽?/span>

在MySQL 5.1中,通過--log-slow-admin-statements服務(wù)器選項，可以請求將慢管理語句，例如OPTIMIZE TABLE、ANALYZE TABLE和 ALTER TABLE寫入慢查詢?nèi)罩尽?/span>

在MySQL 5.1的慢查詢?nèi)罩局?，不使用索引的慢查詢同使用索引的查詢一樣記錄。要想防止不使用索引的慢查詢記入慢查詢?nèi)罩?，使?/span>--log-short-format選項。

使用--log-long-format選項，可以把不使用索引的查詢也加入到慢查詢?nèi)罩局小?/span>

注：

[1] 獲得初使表鎖定的時間不算作執(zhí)行時間。

[2] 語句執(zhí)行完并且所有鎖釋放后記入慢查詢?nèi)罩?。記錄順序可以與執(zhí)行順序不相同

[3] 用查詢緩存處理的查詢不加到慢查詢?nèi)罩局?，因為表有零行或一行而不能從索引中受益的查詢也不寫入慢查詢?nèi)罩?/span>

更新日志提供查詢信息，但只有修改數(shù)據(jù)庫內(nèi)容的查詢。使用--log-update服務(wù)器選項，開啟更新日志。當(dāng)啟用該日志類型后，MySQL將在數(shù)據(jù)目錄下創(chuàng)建一個名稱為：HOSTNAME.nnn的文件。但在5.0以上的MySQL上使用該選項的時候，會有如下的提示：

       也就是說在MySQL V5.0以上，系統(tǒng)已經(jīng)不在支持該日志類型，取而代之的是二進制日志。

MySQL自5.5版本以后，就開始使用CMake編譯工具了，因此，你在安裝源文件中找不到configure文件是正常的。很多人下到了新版的MySQL，因為找不到configure文件，不知道該怎么繼續(xù)下去。有沒有一篇可供參考的文章呢？其實在http://forge.mysql.com網(wǎng)站上有一篇文章，專門介紹了如何用CMake工具進行新版MySQL的編譯安裝。

原文地址為：http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide。

介紹

本頁將介紹常用編譯工具的一些配置選項和這些配置選項在CMake中又是如何進行配置的，然后介紹如何使用CMake工具來構(gòu)建編譯MySQL。

命令調(diào)用語法

下表列出了常用編譯工具的調(diào)用語法和等效的CMake命令。“.”表示你當(dāng)前的工作目錄路徑，請根據(jù)你所在的目錄，適當(dāng)?shù)奶鎿Q掉路徑“.”。

在重新配置或重新構(gòu)建之前，需要先清除舊的對象文件和緩存信息，方法如下：

Autotools：

view plain   copy
make clean 
rm config.cache 

CMake (Unix/Linux)：

view plain   copy
make clean 
rm CMakeCache.txt 

CMake (Windows)：

view plain   copy
devenv MySQL.sln /clean 
del CMakeCache.txt 

安裝參數(shù)選項

在下表中，“CMAKE_INSTALL_PREFIX”的值表示的是安裝根目錄，其他參數(shù)值的路徑都是相對于根目錄的，當(dāng)然你也可以直接使用絕對路徑，具體如下：

存儲引擎選項

存儲引擎是以插件的形式存在的，所以，該選項可以控制插件的構(gòu)建，比如指定使用某個特定的引擎。

--with-plugins配置選項接受兩種形式的參數(shù)值，它沒有對應(yīng)的CMake配置參數(shù)：

① 以逗號(,)分隔的引擎名稱列表；

② a "group name" value that is shorthand for a set of engines

在CMake中，引擎被作為單個的選項來進行控制。假設(shè)有以下配置選項：

view plain   copy
--with-plugins=csv,myisam,myisammrg,heap,innobase,archive,blackhole  

上面的參數(shù)指定MySQL數(shù)據(jù)庫可以支持哪些數(shù)據(jù)庫引擎，將上述編譯選項轉(zhuǎn)換成CMake編譯選項時，下面的幾個引擎名字可以被省略，因為編譯時，默認就支持：

view plain   copy
csv myisam myisammrg heap 

然后使用下面的編譯參數(shù)，以啟用InnoDB、ARCHIVE和BLACKHOLE引擎支持：

view plain   copy
-DWITH_INNOBASE_STORAGE_ENGINE=1 
-DWITH_ARCHIVE_STORAGE_ENGINE=1 
-DWITH_BLACKHOLE_STORAGE_ENGINE=1 

當(dāng)然也可以使用“ON”來替代數(shù)字1，它們是等效的。

如果你想除去對某種引擎的支持，則在CMake編譯選項中使用-DWITHOUT_<ENGINE>_STORAGE_ENGINE，例如：

view plain   copy
-DWITHOUT_EXAMPLE_STORAGE_ENGINE=1 
-DWITHOUT_FEDERATED_STORAGE_ENGINE=1 
-DWITHOUT_PARTITION_STORAGE_ENGINE=1 

庫文件加載選項

該選項指明Mysql使用庫的情況：

其他選項

CMake編譯選項支持大部分之前版本的MySQL編譯選項，新老編譯選項的差別在于：之前的是小寫，現(xiàn)在全部變成了大寫，之前采用雙橫線，現(xiàn)在使用單橫線，之前使用的破折號，現(xiàn)在取而代之的是使用下劃線，例如：

view plain   copy
--with-debug => WITH_DEBUG=1 
--with-embedded-server => WITH_EMBEDDED_SERVER 

下面是編譯MySQL的新老參數(shù)對照表：

要優(yōu)化配置參數(shù)，首先要了解當(dāng)前的配置參數(shù)以及運行情況。使用下列命令可以獲得目前服務(wù)器使用的配置參數(shù)：
mysqld –verbose –help
mysqladmin variables extended-status –u root –p

在MySQL控制臺里面，運行下列命令可以獲取狀態(tài)變量的值：
mysql> SHOW STATUS;

如果只要檢查某幾個狀態(tài)變量，可以使用下列命令：
mysql> SHOW STATUS LIKE ‘[匹配模式]’; ( 可以使用%、?等 )

2．優(yōu)化參數(shù)

參數(shù)優(yōu)化基于一個前提，就是在我們的數(shù)據(jù)庫中通常都使用InnoDB表，而不使用MyISAM表。在優(yōu)化MySQL時，有兩個配置參數(shù)是最重要的，即table_cache和key_buffer_size。

table_cache
table_cache指定表高速緩存的大小。每當(dāng)MySQL訪問一個表時，如果在表緩沖區(qū)中還有空間，該表就被打開并放入其中，這樣可以更快地訪問表內(nèi)容。通過檢查峰值時間的狀態(tài)值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果你發(fā)現(xiàn)open_tables等于table_cache，并且opened_tables在不斷增長，那么你就需要增加table_cache的值了（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables’獲得）。注意，不能盲目地把table_cache設(shè)置成很大的值。如果設(shè)置得太高，可能會造成文件描述符不足，從而造成性能不穩(wěn)定或者連接失敗。

對于有1G內(nèi)存的機器，推薦值是128－256。

案例1：該案例來自一個不是特別繁忙的服務(wù)器
table_cache – 512
open_tables – 103
opened_tables – 1273
uptime – 4021421 (measured in seconds)
該案例中table_cache似乎設(shè)置得太高了。在峰值時間，打開表的數(shù)目比table_cache要少得多。
案例2：該案例來自一臺開發(fā)服務(wù)器。
table_cache – 64
open_tables – 64
opened-tables – 431
uptime – 1662790 (measured in seconds)
雖然open_tables已經(jīng)等于table_cache，但是相對于服務(wù)器運行時間來說，opened_tables的值也非常低。因此，增加table_cache的值應(yīng)該用處不大。
案例3：該案例來自一個性能不佳的服務(wù)器
table_cache – 64
open_tables – 64
opened_tables – 22423
uptime – 19538
該案例中table_cache設(shè)置得太低了。雖然運行時間不到6小時，open_tables達到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。

key_buffer_size
key_buffer_size指定索引緩沖區(qū)的大小，它決定索引處理的速度，尤其是索引讀的速度。通過檢查狀態(tài)值Key_read_requests和Key_reads，可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低，至少是1:100，1:1000更好（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。

key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內(nèi)部的臨時磁盤表是MyISAM表，也要使用該值?？梢允褂脵z查狀態(tài)值created_tmp_disk_tables得知詳情。

對于1G內(nèi)存的機器，如果不使用MyISAM表，推薦值是16M（8-64M）。

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

query_cache_size
從4.0.1開始，MySQL提供了查詢緩沖機制。使用查詢緩沖，MySQL將SELECT語句和查詢結(jié)果存放在緩沖區(qū)中，今后對于同樣的SELECT語句（區(qū)分大小寫），將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶手冊，使用查詢緩沖最多可以達到238％的效率。
通過檢查狀態(tài)值Qcache_*，可以知道query_cache_size設(shè)置是否合理（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Qcache%’獲得）。如果Qcache_lowmem_prunes的值非常大，則表明經(jīng)常出現(xiàn)緩沖不夠的情況，如果Qcache_hits的值也非常大，則表明查詢緩沖使用非常頻繁，此時需要增加緩沖大??；如果Qcache_hits的值不大，則表明你的查詢重復(fù)率很低，這種情況下使用查詢緩沖反而會影響效率，那么可以考慮不用查詢緩沖。此外，在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。
與查詢緩沖有關(guān)的參數(shù)還有query_cache_type、query_cache_limit、query_cache_min_res_unit。query_cache_type指定是否使用查詢緩沖，可以設(shè)置為0、1、2，該變量是SESSION級的變量。query_cache_limit指定單個查詢能夠使用的緩沖區(qū)大小，缺省為1M。query_cache_min_res_unit是在4.1版本以后引入的，它指定分配緩沖區(qū)空間的最小單位，缺省為4K。檢查狀態(tài)值Qcache_free_blocks，如果該值非常大，則表明緩沖區(qū)中碎片很多，這就表明查詢結(jié)果都比較小，此時需要減小query_cache_min_res_unit。

開啟二進制日志( Binary Log )
二進制日志包含所有更新數(shù)據(jù)的語句，其目的是在恢復(fù)數(shù)據(jù)庫時用它來把數(shù)據(jù)盡可能恢復(fù)到最后的狀態(tài)。另外，如果做同步復(fù)制( Replication )的話，也需要使用二進制日志傳送修改情況。
開啟二進制日志，需要設(shè)置參數(shù)log-bin。log_bin指定日志文件，如果不提供文件名，MySQL將自己產(chǎn)生缺省文件名。MySQL會在文件名后面自動添加數(shù)字索引，每次啟動服務(wù)時，都會重新生成一個新的二進制文件。
此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以指定記錄的數(shù)據(jù)庫；使用binlog-ignore-db可以指定不記錄的數(shù)據(jù)庫。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個數(shù)據(jù)庫，指定多個數(shù)據(jù)庫需要多個語句。而且，MySQL會將所有的數(shù)據(jù)庫名稱改成小寫，在指定數(shù)據(jù)庫時必須全部使用小寫名字，否則不會起作用。
在MySQL中使用SHOW MASTER STATUS命令可以查看目前的二進制日志狀態(tài)。

開啟慢查詢?nèi)罩? slow query log )
慢查詢?nèi)罩緦τ诟櫽袉栴}的查詢非常有用。它記錄所有查過long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個慢查詢?nèi)罩镜睦樱?br />開啟慢查詢?nèi)罩?，需要設(shè)置參數(shù)log_slow_queries、long_query_times、log-queries-not-using-indexes。log_slow_queries指定日志文件，如果不提供文件名，MySQL將自己產(chǎn)生缺省文件名。long_query_times指定慢查詢的閾值，缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的參數(shù)，它指示記錄不使用索引的查詢。

配置InnoDB
相對于MyISAM表來說，正確配置參數(shù)對于InnoDB表更加關(guān)鍵。其中，最重要的參數(shù)是innodb_data_file_path。它指定表數(shù)據(jù)和索引存儲的空間，可以是一個或者多個文件。最后一個數(shù)據(jù)文件必須是自動擴充的，也只有最后一個文件允許自動擴充。這樣，當(dāng)空間用完后，自動擴充數(shù)據(jù)文件就會自動增長（以8MB為單位）以容納額外的數(shù)據(jù)。例如：
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:50M:autoextend

兩個數(shù)據(jù)文件放在不同的磁盤上。數(shù)據(jù)首先放在ibdata1中，當(dāng)達到900M以后，數(shù)據(jù)就放在ibdata2中。一旦達到50MB，ibdata2將以8MB為單位自動增長。

如果磁盤滿了，你需要在另外的磁盤上面增加一個數(shù)據(jù)文件。為此，你需要查看最后一個文件的尺寸，然后計算最接近的整數(shù)（MB）。然后手工修改該文件的大小，并添加新的數(shù)據(jù)文件。例如：假設(shè)ibdata2已經(jīng)有109MB數(shù)據(jù)，那么可以修改如下：
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:109M;/disk3/ibdata3:500M:autoextend

flush_time
如果系統(tǒng)有問題并且經(jīng)常鎖死或重新引導(dǎo)，應(yīng)將該變量設(shè)置為非零值，這將導(dǎo)致服務(wù)器按flush_time 秒來刷新表的高速緩存。用這種方法來寫出對表的修改將降低性能，但可減少表訛誤或數(shù)據(jù)丟失的機會。
一般使用缺省值。

Binlog_cache_size
The size of the cache to hold the sql statements for the binary log during a transaction. A binary log cache is allocated for each client if the server supports any transactional storage engines and if the server has binary log enabled(–log-bin option). If you often use big, multiple-statement transactions, you can increase this to get more performance. The Binlog_cache_use and Binlog_cache_disk_use status variables can be useful for tuning the size of this variable.

3．存儲引擎

在MYSQL 3.23.0版本中，引入了MyISAM存儲引擎。它是一個非事務(wù)型的存儲引擎，成為了MYSQL的缺省存儲引擎。但是，如果使用設(shè)置向?qū)碓O(shè)置參數(shù)，則它會把InnoDB作為缺省的存儲引擎。InnoDB是一個事務(wù)型的存儲引擎。

創(chuàng)建表的時候，可以為表指定存儲引擎，語法如下：
CREATE table t (i INT) ENGINE = MyISAM
CREATE table t (i INT) TYPE = MyISAM

如果沒有指定，則使用缺省的存儲引擎。也可以使用ALTER TABLE來更換表引擎，語法如下：
ALTER table t ENGINE = MyISAM

同一數(shù)據(jù)庫中可以包含不同存儲引擎的表。

事務(wù)型表具有以下特點：
Ø Safer. Even if MySQL crashes or you get hardware problems, you can get your data back, either by automatic recovery or from a backup plus the transaction log.
Ø You can combine many statements and accept them all at the same time with the COMMIT statement (if autocommit is disabled).
Ø You can execute ROLLBACK to ignore your changes (if autocommit is disabled).
Ø If an update fails, all your changes will be restored. (With non-transaction-safe tables, all changes that have taken place are permanent.)
Ø Transaction-safe storage engines can provide better concurrency for tables that get many updates concurrently with reads.

非事務(wù)型表具有以下優(yōu)點：
Ø Much faster
Ø Lower disk space requirements
Ø Less memory required to perform updates

4．MyISAM存儲引擎

下面MyISAM的參數(shù)是MySQL手冊推薦的參數(shù)，據(jù)說適應(yīng)于大部分情況。對于如何監(jiān)視參數(shù)設(shè)置是否合理，仍然沒有頭緒。
max_connections=200
read_buffer_size=1M
read_rnd_buffer_size＝8M
sort_buffer_size=1M
Read_buffer_size

Each thread that does a sequential scan allocates a buffer of this size for each table it scans. If you do many sequential scans, you might want to increse this value.

Read_rnd_buffer_size
When reading rows in sorted order after a sort, the rows are read through this buffer to avoid disk seeks. Setting the variable to a large value can improve ORDER BY performance by a lot. However, this is a buffer allocated for each client, so you should not set the global variable to a large value. Instead, change the session variable only from within those clients that need to run large queries.

Bulk_insert_buffer_size
該參數(shù)于4.0.3中引入。MyISAM使用一個樹型的緩沖區(qū)來加速大量的插入，如INSERT…SELECT，INSERT…VALUES(…),VALUES(…),…,LOAD DATA INFILE等。該參數(shù)指定了緩沖區(qū)的大小。缺省值為8M，設(shè)置為0則表示不使用該優(yōu)化。
如果不使用MyISAM表，則可以將其設(shè)置為0。

5．InnoDB存儲引擎

參考了很多資料，都沒有明確地表明如何優(yōu)化InnoDB參數(shù)，以及如何監(jiān)視這些參數(shù)設(shè)置是否合理，只有根據(jù)MySQL用戶手冊上面的介紹來進行設(shè)置。

innodb_buffer_pool_size
對于InnoDB表來說，innodb_buffer_pool_size的作用就相當(dāng)于key_buffer_size對于MyISAM表的作用一樣。InnoDB使用該參數(shù)指定大小的內(nèi)存來緩沖數(shù)據(jù)和索引。對于單獨的MySQL數(shù)據(jù)庫服務(wù)器，最大可以把該值設(shè)置成物理內(nèi)存的80%。

根據(jù)MySQL手冊，對于2G內(nèi)存的機器，推薦值是1G（50%）。

innodb_flush_log_at_trx_commit
該值指定InnoDB記錄日志的方式。如果設(shè)置為1，則每個事務(wù)提交的時候，MySQL都會將事務(wù)日志寫入磁盤。如果設(shè)置為0或者2，則大概每秒中將日志寫入磁盤一次。（還不清楚0和2的區(qū)別）

實際測試發(fā)現(xiàn)，該值對插入數(shù)據(jù)的速度影響非常大，設(shè)置為2時插入10000條記錄只需要2秒，設(shè)置為0時只需要1秒，而設(shè)置為1時則需要229秒。因此，MySQL手冊也建議盡量將插入操作合并成一個事務(wù)，這樣可以大幅提高速度。

根據(jù)MySQL手冊，在存在丟失最近部分事務(wù)的危險的前提下，可以把該值設(shè)為0。

innodb_log_file_size
The size of each log file in a log group. The default is 5MB. The larger the value, the less checkpoint flush activity is needed in the buffer pool, saving disk I/O. But large log files also mean that recovery will be slower in case of a crash.

根據(jù)MySQL手冊，推薦值是innodb_buffer_pool_size的25%。

注意：在重新設(shè)置該值時，好像要把原來的文件刪除掉。

innodb_log_buffer_size
The size of the buffer that InnoDB uses to write to the log files on disk. Sensible values range from 1MB to 8MB. The default is 1MB. A large log buffer allows large transactions to run without a need to write the log to disk before the transactions commit. Thus, if you have big transactions, making the log buffer larger will save disk I/O.
根據(jù)MySQL手冊，推薦值是8M。

innodb_additional_mem_pool_size
該參數(shù)指定InnoDB用來存儲數(shù)據(jù)字典和其他內(nèi)部數(shù)據(jù)結(jié)構(gòu)的內(nèi)存池大小。缺省值是1M。通常不用太大，只要夠用就行，應(yīng)該與表結(jié)構(gòu)的復(fù)雜度有關(guān)系。如果不夠用，MySQL會在錯誤日志中寫入一條警告信息。
根據(jù)MySQL手冊，對于2G內(nèi)存的機器，推薦值是20M。