MySQL很强大，支持直接拷贝数据库文件快速备份，那数据库文件在哪里呢？
打开MySQL的配置文件 my.ini，找到 datadir 节点，如
datadir="D:/Program Files/MySQL/MySQL Server 5.1/data"
进入上述文件夹，就可以看到MySQL中新建的数据库文件夹了，每个文件夹以数据库名命名的，你想备份哪个数据库，把这个文件夹拷贝走即可。到时还原数据库，把它拷贝到data目录下即可，就这么简单！
但是，今天在一台MySQL服务器上拷贝备份了一个数据库后，在另外一台服务器上还原后，重启MySQL服务，通过使用 navicate for mysql 工具查看数据库 “xxx database”中某张表，结果显示“mysql table 'xxx table' doesn`t exist”。
查看了下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 FilesMySQLMySQL Server 5.1inmysqld: 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这样数据混杂的形式，往往很容易让使用者在备份时忘记了备份“ibdata1”，从而导致了上述错误。
意思就是说在数据库引擎类型为InnoDB时，拷贝数据文件的同时还需要拷贝ibdata1，于是把ibdata1也拷贝过去覆盖，发现还是有点问题，于是停止MySQL服务，将目录下的ib_logfile*文件全部删除掉，重新启动MySQL服务，可以了。
小结：
1、如果都是MyISAM引擎，直接拷贝原有数据库文件"*.frm"、"*.MYD"、"*.MYI"即可，如果原数据库引擎是InnoDB，切记还需拷贝ibdata1文件；
2、备份数据库的时候，最好是用专业的工具进行备份或是导出sql文件，以免浪费时间在数据库恢复上。