MySQL 拷貝數據庫表方式備份，還原後提示 table xxx '' doesn`t exist

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 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這樣數據混雜的形式，每每很容易讓使用者在備份時忘記了備份「ibdata1」，從而致使了上述錯誤。

意思就是說在數據庫引擎類型爲InnoDB時，拷貝數據文件的同時還須要拷貝ibdata1，因而把ibdata1也拷貝過去覆蓋，發現仍是有點問題，因而中止MySQL服務，將目錄下的ib_logfile*文件所有刪除掉，從新啓動MySQL服務，能夠了。 

 小結： 

一、若是都是MyISAM引擎，直接拷貝原有數據庫文件"*.frm"、"*.MYD"、"*.MYI"便可，若是原數據庫引擎是InnoDB，切記還需拷貝ibdata1文件； 

二、備份數據庫的時候，最好是用專業的工具進行備份或是導出sql文件，以避免浪費時間在數據庫恢復上。