本文的作者Daniel Nichter是MySQL工具的開發(fā)者，他為MySQL管理員推薦了十款必備工具。以下是全文內容：

MySQL是一套需要大量輔助工具加以修復、診斷及優(yōu)化的復雜系統(tǒng)。幸運的是，對于管理員來說，MySQL的高普及度吸引了大量軟件開發(fā)商為其打造高品質的各類開源工具，內容涵蓋MySQL系統(tǒng)的復雜性均衡、性能表現維持及穩(wěn)定運行保障，而且其中大部分是免費工具。

下列十款開源工具對于使用MySQL的用戶來說是極為寶貴的財富，其內容覆蓋從單獨實例到多節(jié)點環(huán)境的各類情況。該盤點比較用心，大家能夠從中找到足以幫助自己備份MySQL數據、提高性能、防止基準偏差以及在出現問題時從記錄中篩選關鍵性數據的各類工具。

比起親自動手創(chuàng)建內部工具，使用此類工具有下列幾項優(yōu)勢。首先，由于使用范圍廣，它們在系統(tǒng)成熟性及功能實踐方面都要更勝一籌。其次，因為它們都是免費的開源工具，所以能夠得到不斷拓展的MySQL社區(qū)提供的知識及使用經驗的加持。再有，這些開發(fā)人員在研發(fā)環(huán)節(jié)中態(tài)度嚴謹，很多工具還具備專業(yè)技術支持 (無論是免費版還是商業(yè)版)，因此能夠持續(xù)得到完善進而保持對不斷變化的新MySQL業(yè)界態(tài)勢的適應性。

請記住，總有許多我們未曾留心的實用工具值得關注。我在推薦工具的選擇中更為側重于免費及開源特質，功能性及可用性標準則作為稍次之的標準。另外需要強調的是，這些工具中除了一款以外，其余全部屬于Unix指令行程序，因為總體來說MySQL在Unix系統(tǒng)中的部署及開發(fā)工作更為常見。如果各位讀者在我的推薦中沒有找到自己偏愛的某款工具，希望能在文章下方的評論欄中留言，與大家共享你的心得。

閑言少敘，十大必備MySQL工具推薦就此開始。

MySQL必備工具***位: mk-query-digest

沒有什么比低下的MySQL性能表現更讓人抓狂的了。盡管大家常常下意識地認為是硬件配置滯后導致此類問題，但事實上在大多數情況中真正的癥結并不在這里。性能表現不佳往往由以下原因造成，即某些執(zhí)行緩慢的查詢阻塞了其它查詢指令的順暢進行，并由此產生了一個響應時間遲緩的惡性循環(huán)。由于優(yōu)化查詢指令比起升級硬件來說能夠節(jié)約大量成本，因此合乎邏輯的優(yōu)化方式應該從分析查詢指令日志文件入手。

數據庫管理員們應該經常分析查詢日志，進而把握運行環(huán)境的各類波動。而如果大家從來沒有進行過該項分析，請立即著手進行吧。如果對此缺乏經驗，依靠第三方軟件的幫助也是不錯的選擇;盡管很多人認為那些軟件只會在瞎忙一氣之后給出一個虛構的漂亮結果，但我得說，實際上它們通常情況下還是確切有效的。

在當前的諸多選擇中，mk- query-digest是查詢日志分析工具中最棒的一款。它由Baron Schwartz和我本人聯合編寫，功能成熟性、記錄充分性以及測試徹底性都做得相當到位。MySQL本身包含了一款名為mysqldumpslow的查詢日志分析器，但該工具不僅陳舊過時、驗證規(guī)范不準確，而且缺乏廣泛的實際應用加以支持。而其它幾款較為著名的查詢日志分析器，包括我前幾年編寫的 mysqlsla，都與mysqldumpslow具備相同的缺點。

mk-query-digest能夠分析查詢日志內容并根據匯總得出的執(zhí)行時間及其它各項指標的統(tǒng)計信息自動生成報告。由于查詢日志中的信息量極為巨大，有時甚至包含數以百萬計的條目，因此此類分析工作必須依靠特定工具來完成。

mk-query-digest可以幫助大家找出那些與其它查詢指令相比耗時最長的條目。對這些低速查詢加以優(yōu)化將使整套MySQL體系的運行速度大幅提高，***響應延遲也將相應下降。查詢指令的優(yōu)化工作本身堪稱藝術，其中包含諸多細致入微的技巧，但整個流程的基本原則總是共通的：尋獲低速查詢指令、進行優(yōu)化、提高查詢響應時間。

該工具使用起來非常簡便，執(zhí)行mk-query-digest slow-query.log，那些運行速度遲緩的查詢指令將被輸出至slow-query.log文件。工具中還提供了“查詢指令復核”功能，意在列出那些我們尚未加以核對或批準的查詢指令。如此一來，我們就可以僅僅對那些新出現的查詢指令進行有針對性的處理，繁瑣枯燥的日志分析工作也隨之變得更加快速、高效。

下載地址: http://maatkit.org/get/mk-query-digest

維護負責人: Daniel Nichter and Baron Schwartz

更多信息: http://maatkit.org/ | http://code.google.com/p/maatkit/

#p#

MySQL必備工具第二位: mydumper

能夠快速生成數據轉儲在服務器及備份信息克隆工作中至關重要。遺憾的是，MySQL自身包含的mysqldump組件只支持單線程工作，這就使得它無法迅速解決數據密集型用戶所面臨的實際問題。不過好消息還是有的，mydumper作為新生代實用工具，能夠良好支持多線程工作，這使得它在處理速度方面十倍于傳統(tǒng)的mysqldump。

另一款知名的同類工具是MySQL Data Dumper，它的問題是無法單獨管理備份集合、差異點或是一套完整備份計劃中的其它組成部分。該工具只是單純將MySQL中的數據以盡可能快的速度進行轉儲，這在完成限時任務方面倒是具備一定價值，例如趁員工沒有在線操作的時段抓緊時間進行備份。另外，如果大家在實際使用中需要異常頻繁地執(zhí)行備份，那么 MySQL Data Dumper是比較理想的選擇。

從技術角度分析mydumper的話，其特征之一是在處理過程中需要對列表加以鎖定，因此如果我們需要在工作時段執(zhí)行備份工作，那么它恐怕沒什么用武之地。但話說回來，專業(yè)級數據恢復的費用是每小時數百美元，而且即使數據沒能得到恢復，我們收到的也不可能是道歉信而仍然是一紙賬單。相比之下，mydumper完全免費，并且在基本備份工作中表現頗佳。

mydumper在克隆整體服務器方面也比較方便。其它工具往往會對硬盤內容進行整體復制，但大家需要的往往只是MySQL中的數據，這個時候mydumper就能迅速準確地完成任務。設置于云平臺上的服務器特別適合使用mydumper進行克隆，只需將MySQL中的數據從現有服務器復制到新的實例中即可。

在創(chuàng)建從屬服務器、基準確定及模板應用方面采用克隆方案確實行之有效，但克隆真正能夠發(fā)揮作用的領域無疑還是在開發(fā)及測試環(huán)節(jié)當中。對于動態(tài)MySQL 環(huán)境來說，在將軟件推至臺面之前迅速對其進行復制并加以測試可說是至關重要的步驟。有了mydumper，大家能夠快速創(chuàng)建一套幾乎與母體完全相同的服務器來模擬生產服務器，運行于其上的測試結果也將更接近于實際運行結果。

下載地址: https://launchpad.net/mydumper/+download

維護負責人: Domas Mituzas, Andrew Hutchings, Mark Leith

更多信息: http://www.mydumper.org/ | https://launchpad.net/mydumper/

#p#

MySQL必備工具第三位: xtrabackup 以及 xtrabackup-manager

如果大家每天都要用到自己的數據庫，也就是說全天侯使用(晚間也需要運行)，那么鎖定列表以進行備份的方案就無法奏效。這種情況之下，xtrabackup是我們的上上之選。這款工具又被稱為Percona XtraBackup，它在備份過程中無需鎖定列表，且是此類工具中惟一的免費開源產品。相比之下，那些專用的無鎖定備份軟件就顯得相當昂貴，其使用成本達到每臺服務器五千美元以上。

xtrabackup 還具備增量備份功能，允許大家在新一輪備份工作中只對那些相對上次備份結果有所變更的內容進行處理。增量備份功能非常貼心，能夠在那些基礎數據量龐大但變動相對較小的備份工作中發(fā)揮***的功效。

此外，另一款衍生于xtrabackup的工具也日趨成熟，它就是用于簡化完整備份計劃管理工作的xtrabackup-manager。盡管這款工具面世時間不長，且仍處于開發(fā)階段，但其潛在能力不容忽視。它所提供的功能極為先進，包括集群備份整合及備份集合期限管理。綜合來看，xtrabackup 與xtrabackup-manager是一套強大且免費的備份工作解決方案。

下載地址: http://www.percona.com/software/percona-xtrabackup/downloads/

維護負責人: Percona

更多信息：

http://www.percona.com/docs/wiki/percona-xtrabackup:start |https://launchpad.net/percona-xtrabackup

下載地址: http://code.google.com/p/xtrabackup-manager/

維護負責人: Lachlan Mulcahy

更多信息: http://code.google.com/p/xtrabackup-manager/ | http://mysqlsoapbox.blogspot.com/

#p#

MySQL必備工具第四位: tcprstat

tcprstat可能是此次推薦的十款工具中最為艱深的項目。該工具用于監(jiān)視TCP請求，并對低級別的響應時間進行統(tǒng)計及打印輸出。當大家習慣于以響應時間來衡量性能表現，tcprstat的作用是相當可觀的。

整套原則在Cary Millsap及Jeff Holt聯合撰寫的“甲骨文產品性能優(yōu)化”一書中有詳細闡述，而且該原則同樣適用于MySQL。從基本思路上來說，MySQL也不例外，服務項目的運作遵循接收請求(即查詢過程)、滿足該請求(即執(zhí)行時間)以及回饋響應結果(即結果集)。服務項目的實際響應時間指的正是從接收請求開始到發(fā)送響應之間的時間跨度。響應時間超短，相同時段內允許提交的請求數量就越多。

并行處理效能及其它低級別因素也在這一過程中扮演著重要角色，但我們應該將整個過程化繁為簡，即把每個八小時工作日的實際運行時間按28800秒計算。因此如果能將每條請求的響應時間在原有基礎上縮短400毫秒(即從原有的 500毫秒縮短至100毫秒)，那么就意味著我們每天可以多處理230，400條請求。Tcprstat正是幫我們達成這一目標的利器。

由于篇幅所限，我在本文中只能在功能性方面略加描述(即講解MySQL響應時間優(yōu)化工作的***步)以激起諸位讀者的興趣。如果大家在驚鴻一瞥之后決定加深了解，請在閱讀“甲骨文產品性能優(yōu)化”一書之后嘗試使用tcprstat。

下載地址: (source) https://launchpad.net/tcprstat | (binary)http://www.percona.com/docs/wiki/tcprstat:start

維護負責人: Percona

更多信息: http://www.percona.com/docs/wiki/tcprstat:start | https://launchpad.net/tcprstat

#p#

MySQL必備工具第五位: mk-table-checksum

“數據偏差”是廣泛存在于動態(tài)MySQL環(huán)境之中的一項重大問題。其實際含義為：從屬數據未能與主體數據正確同步，發(fā)生的原因主要是從屬數據端出現寫入操作或者主體數據端執(zhí)行了具備不確定性的查詢指令。更糟糕的是，數據偏差情況很可能會被管理人員所忽視，直到爆發(fā)嚴重后果。Mk-table-checksum該登場了，這款工具的作用是在執(zhí)行復雜、敏感的計算時，并行驗證兩個或多個列表中相關數據內容的一致性。

mk-table-checksum 能夠分別為獨立服務器及同步架構中的服務器提供幫助，這也是該工具***的亮點所在。主體服務器與從屬服務器之間的數據一致性在同步時必須得到充分的重視。由于主體數據變更在向從屬數據同步的過程中存在一定程度的滯后(即延遲)，因此直接讀取服務器數據的方式無法嚴格保證信息的一致性，因為數據在同步完全結束之前，一直處于不斷變化且并不完整的狀態(tài)下。鎖定列表、等等所有數據同步結束之后再進行驗證當然行之有效，但這種方案意味著我們不得不同時中止服務器服務的正常響應。mk-table- checksum允許大家在不鎖定列表的前提下，對主體及從屬數據間的差異性進行驗證(至于該技術的具體實現方法，請單擊此處參閱工具文檔)。 http://www.maatkit.org/doc/mk-table-checksum.html

除了同步過程中的一致性，數據驗證在其它一些方面也頗具意義，例如列表尺寸問題。MySQL的CHECKSUM TABLE指令對于小型列表來說完全夠用，但規(guī)模龐大的列表往往需要“分塊”處理，以避免在校驗及計算的過程中CPU或內存發(fā)生長期鎖死或超載的狀況。

分塊處理能夠應付的第二個大問題是對數據一致性定期檢查的要求。雖然數據偏差可能只是一次偶然的意外，但事實上遇到臉丑手黑的管理員，這類問題也許會反復發(fā)作。mk-table-checksum的設計初衷正是對列表進行定期檢查，且整個驗證過程分步分塊、循序漸進，直到整套大規(guī)模列表處理完畢。這種持續(xù)性處理方式有助于管理員對數據偏差進行經常性校對。

下載地址: http://maatkit.org/get/mk-table-checksum

維護負責人: Daniel Nichter & Baron Schwartz

更多信息: http://maatkit.org/ | http://code.google.com/p/maatkit/

#p#

MySQL必備工具第六位: stalk 及collect

有時候，問題會在我們疏于監(jiān)控或回家睡覺的時間段內發(fā)生，大家都知道在問題發(fā)生之后才對MySQL及服務器運行狀態(tài)進行診斷往往很難甚至不可能得出正確結論。這時大家普遍的做法往往是親自編寫一套腳本然后靜待檢測結果，或者是對額外數據進行記錄，畢竟沒人比自己更了解自己所使用的系統(tǒng)。但問題是，系統(tǒng)正常工作時大家當然對其分外熟悉，如果系統(tǒng)當前的工作狀態(tài)可能存在各類隱患，我們也往往會試圖簡單地將其解決掉而非進行深入的探索及分析。

值得慶幸的是，有人對MySQL崩潰狀態(tài)下的狀況非常了解，并針對那些常見多發(fā)的問題編寫了兩款分別名為 stalk及 collect的故障排查工具。前一款工具的作用是在第二款真正運行實例之前等待設備狀態(tài)符合故障發(fā)生時的情形。盡管粗看起來這一點似乎無關緊要，但事實上該工具確實簡單高效地收集了各類可能引發(fā)問題的細節(jié)變化。

首先，stalk根據配置內容的要求每隔一段時間運行一次collect，該步驟能夠消除記錄中那些繁雜無用的冗余數據，使對此前故障的分析更有條理。接下來，collect會將MySQL對自身運行情況的報告及其它各類我們可能想都沒想過的數據進行匯總，其中包括：曾經打開的文件夾、應用程序接受及調用的系統(tǒng)信息、網絡通信量以及其它種種。如此一來，如果最終大家不得不求助于解決MySQL故障的專業(yè)咨詢團隊，那么他們在詢問中所要涉及到的各類信息我們就都已經掌握了。

stalk 與collect能夠根據需要進行配置，因此它們能夠應付幾乎所有故障情況。惟一的要求是為stalk的觸發(fā)建立一項可定義的條件。如果有多項條件都是引發(fā)故障的嫌疑對象，那么大家可能需要與自己的MySQL運行環(huán)境專家進行磋商，以部署更廣泛的審查工作。事實上，導致MySQL崩潰的根本原因也可能潛伏于該系統(tǒng)之外。

stalk 與 collect也可以用于主動防御。舉例來說，如果大家了解到相同時間段內不應該同時存在50個以上的活躍MySQL連接，那么stalk可以主動監(jiān)控這一問題。換句話說，這兩款工具能夠幫你解決許多初顯端倪以及尚不明朗的麻煩。

下載地址:

http://aspersa.googlecode.com/svn/trunk/stalk |http://aspersa.googlecode.com/svn/trunk/collect

維護負責人: Baron Schwartz

更多信息: http://aspersa.googlecode.com/svn/html/index.html |http://code.google.com/p/aspersa/

#p#

MySQL必備工具第七位: mycheckpoint

沒人希望問題確切發(fā)生之后才忙著想辦法補救，因此通過可視化儀表對MySQL運行環(huán)境進行實時監(jiān)控是防患于未燃的一項重要途徑。

MySQL相關的免費或商業(yè)化監(jiān)控應用程序很多，有些是專門服務于MySQL的、有些則是具備MySQL插件或模板的通用型工具。Mycheckpoint值得關注的原因是：它不僅免費開源，而且只針對MySQL，同時各類功能一應俱全。

跟當下大多數監(jiān)控解決方案一樣， mycheckpoint基于見面運行。以下圖為例：

mycheckpoint可以經由設置對MySQL及服務器各項指示同時進行監(jiān)控，例如InnoDB緩沖池刷新、臨時列表創(chuàng)建、操作系統(tǒng)負載、內存使用情況等等。如果大家不喜歡閱讀圖表，mycheckpoint還能夠生成文字報告。

正如 stalk的功能，警報條件可以定義為電子郵件通知，但不必運行collect這類收集額外故障排查數據的工具。Mycheckpoint的另一項實用功能是通過監(jiān)控MySQL中的變量揪出可能導致問題的隱患，或者是阻止那些本不該存在的對MySQL的修改。

監(jiān)控MySQL不僅僅對數據中心或者龐大的設備部署生效。即使大家只擁有一臺MySQL服務器，監(jiān)控措施仍然是不可或缺的;經由此類媒介，我們能夠確切了解自己系統(tǒng)的相關運行情況，進而有效地預見或規(guī)避可能發(fā)生的故障。

下載地址: http://code.google.com/p/mycheckpoint/downloads/list

維護負責人: Shlomi Noach

更多信息: http://code.openark.org/forge/mycheckpoint

#p#

MySQL必備工具第八位: shard-query

還在為針對諸多分區(qū)或是數據碎片集合的查詢速率低下而煩惱?其實只需使用shard-query，整個處理速度會大大加快。那些基于下列架構的查詢指令能夠從shard-query工具中得到***的提升：

• 通過FROM串聯自子句的子查詢
• UNION 及 UNION ALL
• IN
• BETWEEN

復合函數 SUM, COUNT, MIN, and MAX 等也能夠使用上述架構。舉例來說，下面這條查詢指令即可由shard-query并行執(zhí)行:

SELECT DayOfWeek, COUNT(*) AS c 
FROM ontime_fact 
JOIN dim_date USING(date_id) 
WHERE Year 
BETWEEN 2000 AND 2008 
GROUP BY DayOfWeek 
ORDER BY c DESC; 

根據基準測試的結果顯示，通過并行處理的方式，該查詢指令的響應時間縮短了85%左右，從原先的21秒降低至3秒。

Shard-query并不是一款能夠獨立運行的工具;它需要諸如Gearman之類的其它程序提供支持，而且設置過程也相對比較復雜。但如果大家的數據分區(qū)及查詢指令符合上面列出的構造，那么付出一些努力也是值得的，畢竟優(yōu)化效果非常明顯。

下載地址: (svn checkout) http://code.google.com/p/shard-query/source/checkout

維護負責人: Justin Swanhart

更多信息: http://code.google.com/p/shard-query/

#p#

MySQL必備工具第九位: mk-archiver

隨著列表體積的日益增大，查詢指令生效時間也每況愈“長”。響應時間不理想的干擾因素當然很多，但如果我們已經對各個角度實施了優(yōu)化，那么***仍然制約性能表現的瓶頸所在就是列表的規(guī)模了。將龐大列表中的各行內容進行歸檔操作能夠有效縮短查詢指令的響應時間。

除非列表內容并不重要，否則大家千萬不能貿然刪除其中的內容行。歸檔也需要技巧，因為首先數據不能缺失、列表也不能過分鎖定以免影響訪問，還要注意歸檔操作不能導致MySQL及服務器的超載。我們的目標是讓整個歸檔過程穩(wěn)定可靠，除了縮短查詢響應時間外不產生任何負面效果。mk-archiver 能夠幫我們達到愿望。

mk-archiver有兩條基本工作要求，***是歸檔對象必須能夠被識別。舉例來說，如果列表中存在日期列，而且一般來說只有幾年之內的數據有實際價值，那么在這幾年之前的數據行可以進行歸檔。另外，必須具備一套惟一的索引系統(tǒng)以幫助mk-archiver 工具進行定位，而不必掃描整個列表中的內容行。掃描一套巨型列表在時間及經濟方面的成本都相當高昂，因此關鍵指數及特定的SELECT語句在避免整體掃描方面至關重要。

在實際應用當中，mk-archiver 會自動處理各類技術細節(jié)。大家需要做的只是告知該工具哪個列表需要歸檔、如何識別可歸檔的內容行以及將這些行歸至何處。如果需要的話，也可以將這些行剪切至另一個新列表中，或者是以書面的形式生成一個轉儲文件，方便日后需要的時候另行導入。一旦熟悉了這款工具的用法，其中的大量細微調節(jié)選項能夠幫我們實現各種特殊的歸檔要求。此外，mk-archiver 具備嵌入式端口，因此它可以在未經代碼修正的情況下解決諸多復雜的歸檔需求。

下載地址: http://maatkit.org/get/mk-archiver

維護負責人: Daniel Nichter and Baron Schwartz

更多信息: http://maatkit.org/ | http://code.google.com/p/maatkit/

#p#

MySQL必備工具第十位: oak-security-audit

大家***一次全面審核自己MySQL服務器安全性是在什么時候?如果答案是“從來沒有”，其實也不必擔心，因為從不搞安全檢查的群體相當龐大。許多企業(yè)提供安全審核服務，但除非在審計之后不存在任何大規(guī)模變更，否則我們MySQL環(huán)境的安全性應該得到定期的檢查。

外部威脅是執(zhí)行MySQL安全審核的一大重要原因，但內部威脅，尤其是來自現任或前任雇員的因素往往更加危險，因為他們目前(或曾經)具備信任和權限。安全性在隱私性信息的保障(例如醫(yī)療及健康保險方面)方面同樣不容忽視，必須盡力阻止意外訪問(例如登錄至生產服務器而非開發(fā)服務器)或者第三方程序與系統(tǒng)之間的交互。

對于那些希望增進安全性的用戶來說，oak-security-audit大有可為，它是一款免費的開源工具，能夠應對基本的MySQL安全審核。它不需要進行任何設置，將其運行于自己的MySQL服務器之上，它就會打印出一份關于賬戶、賬戶權限、密碼、一般改進方案以及潛在風險的建議報告，例如推薦暫時禁用網絡訪問。以下是報告中的部分內容：

-- Looking for anonymous user accounts(尋找匿名用戶賬戶) 
-- ----------------------------------- 
-- Passed(未發(fā)現問題) 
-- 
-- Looking for accounts accessible from any host(尋找能夠從任何主機實施訪問的賬號) 
-- --------------------------------------------- 
-- Found 1 accounts accessible from any host. 
Recommended actions: 
RENAME USER 'msandbox'@'%' TO 'msandbox'@''; 
(找到1個此類賬戶。建議操作: 
將用戶名 'msandbox'@'%' 重命名為 'msandbox'@'';) 

oak-security-audit的工作重點在于MySQL的安全性方面，因此它并不能代替一套完整的、由技術人員提出的安全審核方案，但它作為***道防線能夠起到相當了不起的防護作用，而且操作簡單。大家可以將其固化進cron指令，每周按時運行，并將生成的報告通過電子郵件發(fā)送給自己并加以審閱。

下載地址: http://openarkkit.googlecode.com/svn/trunk/openarkkit/src/oak/oak-security-audit.py

維護負責人: Shlomi Noach

更多信息:

http://openarkkit.googlecode.com/svn/trunk/openarkkit/doc/html/oak-security-audit.html

原文鏈接：http://www.infoworld.com/d/data-management/10-essential-mysql-tools-admins-168018?page=0,0

【編輯推薦】

1. 教你如何利用MySQL學習MongoDB
2. Craigslist采用MongoDB替代MySQL
3. MySQL中的NoSQL插件
4. SQL與NoSQL——MySQL與NoSQL的融合
5. 論MySQL何時使用索引，何時不使用索引