好用的MYSQL圖形介面管理工具

• MySQL GUI Tools(free)

MySQL GUI Tools (MySQL Administrator) 是款免費的 MySQL 視覺化管理工具，它內建了三個 MySQL 工具。MySQL Administrator、MySQL Query Browser 以及 MySQL Migration Toolkit。不論是要管理設定 MySQL 或是執行 Query、資料庫修改、資料庫轉換…等，完全只要透過 MySQL GUI Tools 即可輕鬆達成。針對各種不同平台(MAC . LINUX . Windows)皆有提供各平台的安裝程式。

* MySQL Administrator 管理工具，提供伺服器運行資訊、使用者管理、資料庫備份及資料庫回存等......。

* MySQL Query Browser 圖型界面的 SQL 查詢工具。

*MySQL Migration Toolkit 資料庫轉移工具，提供將其他來源的資料庫 ( 例: Microsoft Access、Microsoft SQL 或 Oracle ) 轉移到 MySQL 資料庫。

實際測試之下，如果phpMyAdmin在設定上有問題，將會無法登入管理，這時使用MySQL Administrator依然可以做設定及管理你的MySQL。
重點不止如此，phpMyAdmin所擁有的功能，MySQL Administrator都有，但MySQL Administrator卻將這些的設定或管理選項，運用了一個簡潔而有力且視覺化的圖形介面讓使用者來有效的管理及設定MySQL，並且在速度上比phpMyAdmin還快。
＊MySQL Administrator僅能做管理及設定之功能，無法對於資料錄做修改的動作。

官網載點----MySQL GUI Tools

提供看官們1個快速備份mysql教學

使用mysqladministrator備份資料庫快速教學

• Navicat (商業軟體)

不詳加介紹..避免廣告之疑 總之Navicat 可以說是外表美觀簡單，管理功能強大的mysql圖形管理軟體

請看官方的簡介短片吧

附上MySQLAdministrator和SQL常用指令語法下載點省掉各位SEARCH的時間

防止ACCESS數據庫被下載

把 data.mdb 文件改名為 data.asp 文件後放在wwwroot目錄裏。然後在IE中輸入 data.asp 路徑後，發現 IE 顯示一片空白，右鍵->察看原始碼，跳出記事本，將內容另存為.mdb文件，用ACCESS打開，發現需要密碼， 也就是說至少文件檔頭被破壞。

然後用 Flashget 試驗下載 data.asp 文件，並另存為data.mdb 文件，發現用ACCESS 打開完好無損！看來，一些程式設計人員在開發的時候都認為，改了mdb 副檔名為 asp 就能防下載的概念，是錯的！後臺資料庫被下載對於一個asp+access 的網站來說無疑是一場慘絕人寰的災難。今天找了各方的文章，歸納一下有以下9種辦法防止資料庫被下載(歡迎補充)。

1.發揮你的想像力修改資料庫檔案名稱

不用說，這是最最偷懶的方法，但是若攻擊者通過第三方途徑獲得了資料庫的路徑，就玩完了。比如說攻擊者本來只能拿到 list 權限，結果意外看到了資料庫路徑，就可以冠冕堂皇地把資料庫下載回去研究了。另外，資料文件通常大小都比較大，所以再隱蔽的文件檔案名撐都瞞不了人。故保密性為最低。

2.資料庫名稱副檔名改為ASA、ASP等

此法須配合一些要進行一些設置，否則就會出現本文開頭的那種情況。

(1)二進制字段添加。

(2)在這個文件中加入，IIS就會按ASP語法來解析，然後就會報告500錯誤，自然不能下載了。可是如果只是簡單的在資料庫的文本或者備注字段加入<%是沒用的，因為ACCESS會對其中的內容進行處理，在資料庫裏他會以<%的形式存在，無效！正確的方法是將<%存入 OLE 對象字段裏，這樣我們的目的就能達到了。

操作方法：

首先，用notepad新建一個內容為<%的文本文件，隨便起個名字存檔。

接著，用Access打開您的資料庫文件，新建一個表，隨便起個名字，在表中添加一個OLE對象的字段，然後添加一個記錄，插入之前建立的文本文件，如果操作正確的話，應該可以看到一個新的名為”資料包”的記錄。即可。

3.資料庫檔案名稱前加"#"

只需要把資料庫文件前名加上#、然後修改資料庫連接文件（如conn.asp）中的資料庫地址。原理是下載的時候只能識別# 號前名的部分，對於後面的自動去掉，比如你要下載：http://www.pcdigest.com/date/#123.mdb(假設存在的話）。無論是 IE 還是 FLASHGET 等下到的都是http://www.test.com/date/index.htm (或 index.asp、default.jsp 等你原本在IIS設置的首頁檔名)。

另外在資料庫檔案名稱中保留一些空格也起到類似作用，由於HTTP協議對地址解析的特殊性，空格會被編碼為"%",如 http://www.test.com/date/123;456.mdb，下載的時http://www.test.com/date /123%456.mdb。而我們的目錄就根本沒有123%456.mdb 這個文件，所以下載也是無效的這樣的修改後，即使你暴露了資料庫地址，一般情況下別人也是無法下載！

4.加密資料庫

首先在選取"工具->安全->加密/解密資料庫，選取資料庫（如：employer.mdb），然後接確定，接著會出現 "資料庫加 密後另存為" 的窗口，存為：employer1.mdb。接著employer.mdb就會被編碼，然後存為employer1.mdb..要注意的是，以上的動作並不是對資料庫設置密碼，而只是對資料庫文件加以編碼，目的是為了防止他人使用別的工具來查看資料庫文件的內容。

接下來我們為資料庫加密，首先以打開經過編碼了的 employer1.mdb，在打開時，選擇 "獨佔" 方式。然後選取功能表的 "工具-> 安全->設定資料庫密碼"，接著輸入密碼即可。這樣即使他人得到了 employer1.mdb 文件，沒有密碼他是無法看到 employer1.mdb的。

加密後要修改資料庫連接頁，如：

conn.open "driver={ microsoft access driver&nb sp;
(*.mdb) };uid=admin;pwd=資料庫密碼;dbq=資料庫路徑"

這樣修改後，資料庫即使被人下載了，別人也無法打開（前提是你的資料庫連接頁中的密碼沒有被泄露）。
但值得注意的是，由於Access資料庫的加密機制比較簡單，即使設置了密碼，解密也很容易。該資料庫係統通過將用戶輸入的密碼與某一固定密鑰進行"異 或"來形成一個加密串，並將其存儲在 *.mdb 文件從地址 "&H42" 開始的區域內。所以一個好的程序員可以輕松制作一個幾十行的小程序就可以輕鬆地獲得任何Access資料庫的密碼。因此，只要資料庫被下載，其資訊安全依然是個未知數。

5.資料庫放在WEB目錄外或將資料庫連接文件放到其他虛擬目錄下

如你的WEB目錄是e:\webroot，可以把資料庫放到e:\data這個文件夾裏，在e:\webroot裏的資料庫連接頁中修改資料庫連接地址為："../data/資料庫名"的形式，這樣資料庫可以正常調用，但是無法下載的，因為它不在WEB目錄裏！這個方法一般也不適合購買虛擬空間的用戶。

6.使用ODBC資料源

在ASP等程序設計中，如果有條件，應盡量使用ODBC資料源，不要把資料庫名寫在程序中，否則，資料庫名稱將隨ASP原始碼的失竊而一同失竊，例如：

DBPath = Server.MapPath("../123/ abc/asfadf.mdb ")
conn.open "driver={ Microsoft Access Driver&nb sp;(*.mdb) };dbq="& DBPath

可見，即使資料庫名字起得再怪異，隱藏的目錄再深，ASP原始碼失密後，也很容易被下載下來。如果使用ODBC資料源，就不會存在這樣的問題 了：

conn.open "ODBC-DSN名"

，不過這樣是比較煩的，目錄移動的話又要重新設置資料源了，更方便的方法請看第7，8法！

7.添加資料庫名的如MDB的延伸副檔名對應

這個方法就是通過修改 IIS 設定來實現，適合有 IIS 控制權的朋友，但不適合購買虛擬主機用戶(除非管理員已經設定了）。這個方法我認為是目前最好的，只要修改一處，整個網站的資料庫都可以防止被下載，且無須修改原始碼即使是暴露目標地址也可以防止被下載。

我們在 IIS 屬性-->主目錄-->應用程式設定-->應用程式對應-->新增 那裏添加.mdb文件的應用解析。注意這裏所選擇的DLL（或EXE等） 似乎也不是任意的，選擇不當，這個MDB文件還是可以被下載的，注意最好不要選擇選擇 asp.dll 等。你可以自己多測試下，修改後下載資料庫，就出現 （404或500等錯誤）。

例如在執行檔輸入：c:\windows\system32\inetsrv\ism.dll

        副檔名輸入：.mdb

        限制於：GET,POST

8.使用.net的優越性

動網的木鳥就寫過一個防非法下載文件的"WBAL防盜鏈工具"。

不過那個只實現了防止非本地下載的，沒有起到真正的防下載資料庫的功能。不過這個方法已經跟5法差不多可以通過修改.NET文件，實現本地也不能下載！

這幾個方法中，只有第7和8個是統一性改的，一次修改設定後，整個網站的資料庫都可以防止下載，其他幾個就要分別修改資料庫名稱和連接文件，比較麻煩，不過對於虛擬主機的朋友也只能這樣了！

其實第6個方法應該是第5個方法的延伸，可以實現特殊的功能，但對於不支持.net的主機或者怕設定麻煩的話，還是直接用第5個方法了，而且預設情況下第6個方法，依然可以通過復制連接到同主機的論壇或留言本發表，然後就可以點擊下載了。（因為這樣的引用頁是來自同主機的）

9.利用NTFS磁區的文件權限設置

我們已經知道，ASP.NET中使用ADO.NET訪問資料庫，通過OleDb的連接可以訪問Access資料庫，我們非常常用的低端資料庫 之一。本文討論了ASP.NET中可能看到的若幹錯誤提示，從中看到Access2000和AccessXP創建的資料庫文件，在訪問出現錯誤時會出現不太相同的錯誤提示。希望對大家有所幫助。另一個要點是，希望通過此文，使大家對ASP.NET中Access資料庫文件的NTFS權限設置有所新的認識。

(一)實驗過程

為了敘述方便，舉個具體例子做個實驗：應用程序為/test，資料庫存放在D:\wwwroot\test\data\db1.mdb，我們已 經知道在ASP.NET中是以一個叫做ASPNET虛擬用戶的身份訪問資料庫的，我們需要給這個賬戶以特定的NTFS權限才能使ASP.NET程序正常運 行。

為了得到最嚴格的NTFS權限設置，實驗開始時我們給程序最低的NTFS權限：

a)D:\wwwroot\test\data\文件夾的給用戶ASPNET以如下權限：

允許
拒絕

完全控制

修改

讀取及運行
V

列出文件夾目錄
V

讀取
V

寫入

b) D:\wwwroot\test\data\db1.mdb文件本身給用戶ASPNET以如下權限：

√允許將來自父係的可繼承權限傳播給該對象

1.1：對於某個只包含有"SELECT"命令的aspx程序，上述權限設置運行時無障礙，即：上述權限已經滿足這類程序的運行了。

1.2：對於包含有"UPDATE""INSERT""UPDATE"等命令的aspx程序。

(a)如果db1.mdb是Access2000創建的資料庫，出現如下錯誤：

"/test"應用程序中的服務器錯誤。

MicrosoftJet資料庫引擎打不開文件'D:\wwwroot\test\data\'。它已經被別的用戶以獨佔方式打開，或沒有查看資料的權限。

說明：執行當前Web請求期間，出現未處理的異常。請檢查堆棧跟蹤資訊，以了解有關該錯誤以及原始碼中導致錯誤的出處的詳細資訊。

異常詳細資訊:System.Data.OleDb.OleDbException:MicrosoftJet資料庫引擎打不開文件'D:\wwwroot\test\data\'。它已經被別的用戶以獨佔方式打開，或沒有查看資料的權限。

(b)如果db1.mdb是AccessXP創建的資料庫，出現如下錯誤： "/test"應用程序中的服務器錯誤。

操作必須使用一個可更新的查詢。

說明：執行當前Web請求期間，出現未處理的異常。請檢查堆棧跟蹤資訊，以了解有關該錯誤以及原始碼中導致錯誤的出處的詳細資訊。

異常詳細資訊：System.Data.OleDb.OleDbException：操作必須使用一個可更新的查詢。

(c)原因初步分析：因為包含有"UPDATE""INSERT""UPDATE"等命令，需要對資料庫文件本身進行寫入操作，所以上述權限不能滿足此需求，我們需要進一步放開權限。

我們放開一些權限，

a) D:\wwwroot\test\data\ 文件夾不變；

b) D:\wwwroot\test\data\db1.mdb 文件本身給用戶ASPNET以如下權限；

允許
拒絕

完全控制

修改

讀取及運行
V

列出文件夾目錄
V

讀取
V

寫入
V

1.3：放開權限後繼續實驗

(a)如果db1.mdb是Access2000創建的資料庫，出現如下錯誤： "/test"應用程序中的服務器錯誤。

不能鎖定文件。

說明：執行當前Web請求期間，出現未處理的異常。請檢查堆棧跟蹤資訊，以了解有關該錯誤以及原始碼中導致錯誤的出處的詳細資訊。

異常詳細資訊：System.Data.OleDb.OleDbException:不能鎖定文件。

(b)如果db1.mdb是AccessXP創建的資料庫，沒有出現錯誤。

(c)原因初步分析：我們發現在打開Access資料庫時，同時會在所在目錄生成一個同名的*.ldb文件，這是一個Access的鎖定標記。 鑒於此，我們猜測，用戶ASPNET訪問Access資料庫時，也需要生成一個鎖定標記，而該目錄沒有允許其寫入，因此出錯。至於AccessXP創建的 資料庫為什么沒有這個錯誤，原因還不得而知。

我們進一步放開權限，

a)D:\wwwroot\test\data\文件夾  給用戶ASPNET以如下權限：

允許
拒絕

完全控制

修改

讀取及運行
V

列出文件夾目錄
V

讀取
V

寫入
V

b) D:\wwwroot\test\data\db1.mdb文件本身給用戶ASPNET以如下權限：

√允許將來自父係的可繼承權限傳播給該對象

1.4：繼續實驗，發現錯誤已解決，那么上面這個權限就是我們需要放開的"最低權限"。

(a)如果db1.mdb是Access2000創建的資料庫，我們會發現一個小問題：生成的*.ldb文件不會自己刪除，訪問後該文件依然存在，但這個問題不會影響ASP.NET的正常運行。

(b)如果db1.mdb是AccessXP創建的資料庫，沒有出現上面類似問題。

(c)原因初步分析：我們僅僅是給了ASPNET以寫入文件夾的權限，沒有給它修改的權限，所以文件一旦寫入，便無法修改其內容，*.ldb也就刪除不掉了。

如果非要解決這個問題，進一步放開權限為：

a)D:\wwwroot\test\data\文件夾給用戶ASPNET以如下權限：

允許
拒絕

完全控制

修改
V

讀取及運行
V

列出文件夾目錄
V

讀取
V

寫入
V

b) D:\wwwroot\test\data\db1.mdb 文件本身給用戶ASPNET以如下權限：

√允許將來自父係的可繼承權限傳播給該對象

1.5：附帶著，實驗另一種情形：我們把db1.mdb在Access打開編輯，同時訪問ASP.NET。

(a)如果db1.mdb是Access2000創建的資料庫，我們發現並沒有出現什麼問題。

(b)如果db1.mdb是AccessXP創建的資料庫，出現如下錯誤：&nb。

SQL 資料庫災難復原 (使用 Binary Log)

當 MySQL Server 因為各種無法預期的原因而損毀(Crash)的時候，你就必須要進行災難復原。若是您有做好定期的資料庫備份那麼災難還原的時候應該會輕鬆很多，只要將備份起來的資料還原回去即可，但光是這樣子還是會造成部份資料的遺失，例如 "現在" 至 "最後一次備份" 之間的資料，這時我們可以透過 MySQL 提供的 Binary Log 機制將可能遺失的資料降至最低。
Binary Log 的運作原理很簡單，它只是單純的將所有會修改到資料庫內容的操作記錄在 Log 檔案中，然後透過這個 Binary Log 你就可以重新執行所有會修改到資料庫內容的操作。例如若你最後一次備份的時間是 1/1 AM 0:00 ，並且有啟用 Binary Log 功能記錄 1/1 AM 0:00 這個時間點以後所有會修改到資料庫內容的操作，假設你的 MySQL Server 在 1/2 AM 10:00 故障，你就可以將 1/1 AM 0:00 備份的資料還原回去，然後利用 Binary Log 將 1/1 AM 0:00 ~ 1/2 AM 10:00 之間所有的操作重新執行一次，這樣子一來你就可以將資料庫還原到當機的那個時間點。
使用 Binary Log 進行災難復原的步驟：

1. 啟用 Binary Log
2. 使用 mysqlbinlog 將 Binary Log 轉換成可執行的 SQL 指令

在接下來的文章中會使用的範例與假設：

1. 最後一次備份的時間點為 1/1 AM 0:00
2. MySQL Server 在 1/2 AM 10:00 故障

一、啟用 Binary Log

修改 MySQL Server 的系統設定檔(eg. /etc/my.cnf)，在 [mysqld] 區塊中加上 log-bin=mysql-bin 選項，然後重新啟動 MySQL Server，例如：

引用:

[mysqld]
log-bin=mysql-bin

啟用後你應該可以在 MySQL 的 Data Dir 裡面發現如下的檔案：

mysql-bin.index
mysql-bin.000001
mysql-bin.000002
...............
mysql-bin.00000X

MySQL 在以下幾種情況會進行 lograrote：

1. 執行 Flush Logs 指令
2. MySQL Server 重新啟動
3. 設定檔中有進行額外的設定

註：
請注意，當您使用 mysqldump 進行資料庫備份時請記得加上 --flush-logs 選項，例如：

引用:

mysqldump --flush-logs -u root -p 資料庫名稱 > example.sql

這麼做的目的是在備份時讓 MySQL Server 進行 logrotate，這樣子日後要辨別 "最後一次備份時間點" 之後的 Binary Log 會比較方便，因為若你沒有主動(或透過設定)去刪除 Binary Log，則只要你的硬碟空間夠大，MySQL 會無限期的保存 Binary Log，也就是說你的 Binary Log 裡面所記載的資料有可能包含 "最後一次備份時間點" 之前的資料。

二、使用 mysqlbinlog 將 Binary Log 轉換成可執行的 SQL 指令

Binary Log 是無法被 MySQL Server 直接執行、也無法直接以人眼去閱讀的，必須要先使用 MySQL 所提供的 mysqlbinlog 程式，將 Binary Log 轉換為 MySQL Server 可以執行的 SQL 指令。mysqlbinlog 的語法如下：

引用:

mysqlbinlog -H --set-charset="utf8" --start-datatime="2007-01-01 00:00:00" --stop-datatime="2007-01-02 10:00:00" mysql-bin.[0-9]* > example.sql

-H：Display a hex dump of the log in comments.
--set-charset：設定編碼
--start-datatime：要轉換的開始時間點
--stop-datatime：要轉換的結束時間點
mysql-bin.[0-9]*：這裡要注意的是，要一次處理所有的 Binary Log，因為儲存在 Binary Log 中的資料有可能會 "跨檔案"，例如從 mysql-bin.000001 的結尾接到 mysql-bin.000002 的開頭。
example.sql：轉換出來的文字檔的檔案名稱，這個名稱可以自已取。
需要加 -H 選項的原因如下：

引用:

mysqlbinlog didn't escape the string content of user variables, and did not deal well when these variables were in non-ASCII character sets; this is now fixed by always printing the string content of user variables in hexadecimal. The character set and collation of the string is now also printed. (Bug #3875)

實際執行轉換後的 Binary Log

很簡單，只要一行簡單的指令：

引用:

mysql < example.sql

如果沒有什麼錯誤訊息發生，那麼只要等它執行完就大功告成了。話又說回來，要是執行失敗呢？這是有可能的。MySQL 在處理 Binary Log 時有一些 Bug 存在，它的 Bug Report 似乎是說在最新版本的 MySQL Server 中已修正此 Bug，我沒有實際測試過所以不清楚，但若是你和我一樣也遇到這個 Bug 的話，也不用太擔心。這些問題其實不難解決，自己 Workaround 即可。
目前我看到的情況有：

1. Comment 沒有正確標示
2. Comment 語法錯誤
3. 不正確的使用 DELIMITER
4. 奇怪的 STOP 指令(我不太確定這是做什麼用的)

自己用 sed 去修改轉換過後的 example.sql 即可。

引用:

sed -f replace.rules example.sql > final.sql

replace.rules檔案的內容：

引用:

s/\(Query.*thread\)/#\1/g
s/\(###.*###\)//g
s/DELIMITER ;//g
s/Stop//g

上面幾行的意義：
s/\(Query.*thread\)/#\1/g

MySQL 的 Binary Log 在處理 Comment 的時候，有的時候會漏加 "#" 符號在 Comment Line 的最前面。例如本來是：

引用:

Query thread_id=227528 exec_time=- error_code=0

要改成：

引用:

#Query thread_id=227528 exec_time=- error_code=0

s/\(###.*###\)//g

在某些 SQL statement(例如 REPLACE INTO search)的最後面會有一些 Comment 存在，但這些 Comment 的語法不正確反而會造成執行失敗，故刪除之。
類似以下的行都應該刪除：

引用:

### Bitfield: user.options ###
### SAVE ORDERED IDS TO SEARCH CACHE ###

........等等

s/DELIMITER ;//g

刪除不正確的 DELIMITER 指令，像以下這樣就是不正確的：

引用:

DELIMITER ;

s/Stop//g

有的時候會在 Binary Log 中出現 Stop 這個指令而導致執行失敗，故刪除之。但我不太確定這個 Stop 指令實質上的用途是什麼。

使用 mysqldump備份 DB

[MySQL] 使用 mysqldump備份 DB

用 mysqldump 做備份，如果要儘可能把完整的資料匯出，可以加上 --single-transaction，備份前 mysqldump 會先執行 BEGIN ，取得 READ LOCK 後，便能確定資料在執行 mysqldump 的過程中不會受到其它連線存取的干擾，也能 Dump 出較完整的資料。(使用此參數需有 READ LOCK 權限)

mysqldump --single-transaction --all-databases > all_db.sql

注意:
1.表單較大時可以加上 --quick
2.MySQL Cluster 不支援 --single-transaction

然而使用 --single-transaction 時最好搭配 --flush-logs 及 --master-data 來維持 Binary Log 的完整性。(使用這二個參數皆需有 RELOAD 權限)

mysqldump --single-transaction --flush-logs --master-data --all-databases > all_db.sql

Binary Log 採用的是遞增備份，--flush-logs 便是把目前的 Binary Log 給 flush 出來 (若目前 MASTER_LOG_FILE 已經到 mysql-bin.000005，產生出來的檔案便是 mysql-bin.000006)，完成之後才進行 Dump 的作業。

而 --master-data (預設值為1) 則是在 Dump 出來的 SQL 語法中加入下面這一行，以記錄目前 Dump 的時間點。

CHANGE MASTER TO MASTER_LOG_FILE=mysql-bin.000006',MASTER_LOG_POS=4;

如果在未來執行匯入時 SQL 語法時， MySQL 便能很清楚的知道這次 Dump 出來的 SQL 在 Binary Log 中是屬於哪個位置。

註: 若不需理會 Binary Log 的位置時 (例如進行完整備份作業)，只要將 --master-data 設為 2 便會將 CHANGE MASTER 給註解起來純供參考用。