在MySQL中如果要遷移一個(gè)表導(dǎo)另外一個(gè)服務(wù)器/環(huán)境中，常規(guī)的做法就是使用備份工具備份，比如mysqldump，然后拷貝備份到目標(biāo)服務(wù)器或者環(huán)境導(dǎo)入。如果某一個(gè)表數(shù)據(jù)量很大，導(dǎo)出dump文件很大的情況下，使用導(dǎo)出導(dǎo)入工具其實(shí)會(huì)花費(fèi)不少的時(shí)間.

怎么樣提高效率呢，可以有一種想法就是直接拷貝數(shù)據(jù)文件到目標(biāo)環(huán)境，當(dāng)然在早期版本中這么做是不可取的，因?yàn)闀?huì)有很多關(guān)聯(lián)數(shù)據(jù)在ibdata中，InnoDB的數(shù)據(jù)存在對(duì)應(yīng)的數(shù)據(jù)字典信息，是存放在共享表空間中，無法直接剝離出來，而在5.6/5.7中，就推出了一個(gè)很不錯(cuò)的特性，就是遷移表空間，可以把這個(gè)配置信息剝離出來，簡(jiǎn)單來說就是把數(shù)據(jù)文件直接拷貝到目標(biāo)環(huán)境，在目標(biāo)端掛載即可。

這樣一個(gè)操作的一個(gè)基本前提是使用了獨(dú)立表空間,開啟innodb_file_per_table.

>show variables like '%per_table%';

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| innodb_file_per_table | ON    |

+-----------------------+-------+

1 row in set (0.00 sec)

跨版本傳輸表空間-源端操作

我們做一個(gè)有代表意義的測(cè)試，比如把某一個(gè)表從MySQL 5.6環(huán)境遷移到MySQL 5.7環(huán)境中。

 我們選擇一個(gè)表users作為測(cè)試所用，數(shù)據(jù)量在2萬(wàn)條左右。數(shù)據(jù)文件情況：

-rw-rw---- 1 mysql mysql      8602 Feb 13 23:10 users.frm

-rw-rw---- 1 mysql mysql  11534336 Mar 12 22:55 users.ibd數(shù)據(jù)情況：

> select count(*) from users;

+----------+

| count(*) |

+----------+

|    20001 |

+----------+

1 row in set (0.01 sec)我們開始遷移數(shù)據(jù)，首先要生成一個(gè)cfg文件，導(dǎo)出配置信息。

-rw-rw---- 1 mysql mysql       599 Mar 13 08:17 users.cfg

-rw-rw---- 1 mysql mysql      8602 Feb 13 23:10 users.frm

-rw-rw---- 1 mysql mysql  11534336 Mar 12 22:55 users.ibd在flush table之后，這個(gè)表users就被鎖定了，DML操作是阻塞的，也就意味著遷移的過程中，是無法直接寫入數(shù)據(jù)的。

# strings users.cfg

mbionline.test.com    

test/users

userid

        username

DB_ROW_ID

DB_TRX_ID

DB_ROLL_PTR

PRIMARY

userid

DB_TRX_ID

DB_ROLL_PTR

        username

        username

        username

userid

idx_users

userid

username完成之后推出會(huì)話，設(shè)置unlock tables即可。

> alter table users import tablespace;

ERROR 1808 (HY000): Schema mismatch (Table flags don't match, server table has 0x5 and the meta-data file has 0x1)或者下面的錯(cuò)誤：

> alter table users import tablespace;

ERROR 1808 (HY000): Schema mismatch (Table has ROW_TYPE_DYNAMIC row format, .ibd file has ROW_TYPE_COMPACT row format.)通過錯(cuò)誤信息可以發(fā)現(xiàn)和表的一個(gè)屬性有關(guān)。我們先解決問題，添加屬性row_format

CREATE TABLE `users` (

  `userid` int(11) unsigned NOT NULL,

  `username` varchar(64) DEFAULT NULL,

  PRIMARY KEY (`userid`),

  KEY `username` (`username`),

  KEY `idx_users` (`userid`,`username`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 row_format=compact;然后繼續(xù)嘗試Import tablespace操作。

回到剛剛碰到的問題，為什么在5.6遷移至5.7會(huì)有報(bào)錯(cuò)。

> alter table users import tablespace;

ERROR 1808 (HY000): Schema mismatch (Table has ROW_TYPE_DYNAMIC row format, .ibd file has ROW_TYPE_COMPACT row format.)原因就是Innodb_file_format在5.6中是Antelope，在MySQL 5.7中是Barracuda，主要是在表壓縮和行的動(dòng)態(tài)格式上有所改變。更詳細(xì)的內(nèi)容可以參考：

https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-7.html

小結(jié)

其實(shí)這個(gè)特性在Oracle中已經(jīng)有耳熟能詳?shù)牡姆桨福琓TS,支持跨平臺(tái)，轉(zhuǎn)換字節(jié)順序，甚至可以支持基于增量備份的遷移方案，MySQL中的遷移方式和Oracle傳統(tǒng)的TTS有些相似。當(dāng)然上面的操作還可以使用Percona的工具innobackupex 來完成，我們下一篇來進(jìn)行演示。