補充：正常情況下，建議資料庫備份最好用工具進行備份，通過拷貝資料庫表進行資料遷移，不同的環境會出現各種不同的意外問題。

背景：今天在整理一個網站的時候，作業系統由於系統自動更新導致一直出現系統藍屏宕機，唉，悲劇了，於是重新安裝了系統 windows server 2008 enterprise 32bit。

詳情：

      系統安裝完成後，重新配置之前那個網站，appache服務配好之後，再配置資料的時候是這樣做的，將原來Mysql 資料夾（C:\Windows.old\ProgramData\MySQL\MySQL Server 5.1\data）下的資料庫資料夾及"*.frm"

拷貝到新安裝的myql資料庫資料夾下面（C:\ProgramData\MySQL\MySQL Server 5.1\data），重啟mysql服務，通過使用navicate for mysql 工具檢視資料庫 “xxdatabase”中某張表，結果顯示“ mysql table 'xxtable' doesn`t exist ”,

這個可把我給急壞了，心想這下可玩大了，網站的資料要是出問題了，領導還不把我給燒烤了啊。

    於是我就google 啊，百度啊，bing啊，stackoverflow啊等幾大常用的搜尋全用上了，搜尋出來的答案全部都不能解決問題啊，一不留神時間到了該吃飯的點了，唉，心想先吃飽飯，然後在思考更有思路，哈哈。於是回去猛吃了一頓，可把我給撐的啊，廢話少說，回來後又找啊找啊，結果還是沒能找到合適解決方案，於是認真查看了下mysql 的data檔案加下的檔案，發現了WIN-4FA0WLP5F0V.err和WIN-4FA0WLP5F0V.pid 兩個檔案，於是看了具體的錯誤內容如下

120622 12:00:36 [Note] Plugin 'FEDERATED' is disabled.
120622 12:00:37  InnoDB: Initializing buffer pool, size = 300.0M
120622 12:00:37  InnoDB: Completed initialization of buffer pool
InnoDB: The first specified data file .\ibdata1 did not exist:
InnoDB: a new database to be created!
120622 12:00:37  InnoDB: Setting file .\ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
120622 12:00:37  InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 60 MB
InnoDB: Database physically writes the file full: wait...
120622 12:00:37  InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 60 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
120622 12:00:39  InnoDB: Started; log sequence number 0 0
120622 12:00:39 [Note] Event Scheduler: Loaded 0 events
120622 12:00:39 [Note] D:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld: ready for connections.
Version: '5.1.55-community'  socket: ''  port: 3306  MySQL Community Server (GPL)
120622 12:02:49 [ERROR] Cannot find or open table magento/catalog_product_bundle_selection_price from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See 

 感覺應該是資料庫引擎配置的問題，於是搜尋了有關InnoDB 和MyISAM的相關資料，如下這段內容很有意義

以表”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版本或是備份工具的版本不同，也可能引起資料恢復有問題。