由於在一台測試機器上打算重新安裝Mysql數據庫，由於簡單粗暴的直接卸載了，沒有備份公司Discuz和Redmine使用的Mysql數據庫，過程可想的悲慘。
還好的是只是卸載掉了Mysql的程序，所有的數據文件還是存在的。
下面是在恢復數據庫的過程
1. Discuz數據庫
Discuz數據庫的恢復非常順利， 在安裝好新版本的Mysql後，直接將原來的數據庫文件copy到新的數據目錄中，重新啟動mysql, 就能看到恢復的數據庫了
2. Redmine數據庫
本打算直接使用上面的經驗，也能看到所有的表，但是就是執行查詢的時候，總是報錯"表不存在".
後來查了一些資料，發現，原因應該是Discuz和Redmine使用的Mysql引擎不一樣導致的。
Discuz使用的是MyISAM, 而Redmine使用的是InnoDB.
解決的辦法是,
除了要copy數據目錄外，還要記得覆蓋ibdata1文件。
以表”Table”為例: 如類型是MyISAM, 數據文件則以”Table.frm””Table.MYD””Table.MYI””三個文件存儲於”/data/$databasename/”目錄中. 如類型是InnoDB, 數據文件則存儲在”$innodb_data_home_dir/″中的ibdata1文件中(一般情況)，結構文件存在於table_name.frm中. MySQL的數據庫文件直接復制便可以使用，但是那是指“MyISAM”類型的表。 而使用MySQL-Front直接創建表，默認是“InnoDB”類型，這種類型的一個表在磁盤上只對應一個“*.frm”文件，不像MyISAM那樣還“*.MYD,*.MYI”文件。 MyISAM類型的表直接拷到另一個數據庫就可以直接使用，但是InnoDB類型的表卻不行。解決方法就是:
同時拷貝innodb數據庫表“*.frm”文件和innodb數據“ibdata1”文件到合適的位置。啟動MySQL的Windows服務 由於MySQL這樣數據混雜的形式, 往往很容易讓使用者在備份時忘記了備份InnoDB, 從而導致了上述錯誤.
意思就是說在數據庫引擎類型為InnoDB時，拷貝數據文件的同時還需要拷貝ibdata1，於是把ibdata1也拷貝過去覆蓋，發現還是有點問題，於是停止mysql服務，將目錄下的ib_logfile*文件全部刪除掉，重新啟動mysql服務，well done，可以了
高興啊，於是稍微總結了，希望以後遇到相同的問題，能夠快速解決。
1，在進行mysql數據庫備份的或遷移的時候，盡量備份完成所需要的數據；
2，如果直接拷貝原有數據庫文件"*.frm"、"*.MYD"、"*.MYI"等文件時候，如果原數據庫引擎是InnoDB,切記還需拷貝ibdata1文件
3，備份數據庫的時候，最好是用相關的工具進行備份或是導出sql文件，以免浪費時間在數據庫恢復上
4，msyql版本或是備份工具的版本不同，也可能引起數據恢復有問題。
實踐證明以上問題是存在的，解決方案是可行的，哈哈，為了以後方便，寫了這篇博客隨筆，希望大牛看到了不要鄙視，歡迎拍磚。
1：MyISAM類型的數據文件可以在不同操作系統中COPY，這點很重要，布署的時候方便點。（只需要拷貝 數據庫名字文件夾下面的文件，這樣數據庫就拷貝完了）
2: InnoDB類型的 要注意多拷貝 ibdata1 , 最好不要是直接復制文件夾，而是應該用sql導入導出
