補充：正常情況下，建議數據庫備份最好用工具進行備份，通過拷貝數據庫表進行數據遷移，不同的環境會出現各種不同的意外問題。
背景：今天在整理一個網站的時候，操作系統由於系統自動更新導致一直出現系統藍屏死機，唉，悲劇了，於是重新安裝了系統 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 http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html
how you can resolve the problem.
感覺應該是數據庫引擎配置的問題，於是搜索了有關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版本或是備份工具的版本不同，也可能引起數據恢復有問題。
實踐證明以上問題是存在的，解決方案是可行的，哈哈，為了以后方便，寫了這篇博客隨筆，希望大牛看到了不要鄙視，歡迎拍磚。