补充：正常情况下，建议数据库备份最好用工具进行备份，通过拷贝数据库表进行数据迁移，不同的环境会出现各种不同的意外问题。
背景：今天在整理一个网站的时候，操作系统由于系统自动更新导致一直出现系统蓝屏死机，唉，悲剧了，于是重新安装了系统 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版本或是备份工具的版本不同，也可能引起数据恢复有问题。
实践证明以上问题是存在的，解决方案是可行的，哈哈，为了以后方便，写了这篇博客随笔，希望大牛看到了不要鄙视，欢迎拍砖。
