當企業內部使用的數據庫種類繁雜時，或者有需求更換數據庫種類時，均可能會作不少數據遷移的工做。有些遷移很簡單，有些遷移可能就會很複雜，你們有沒有考慮過爲了順利完成複雜的數據庫遷移任務，都須要考慮並解決哪些問題呢？html
在之前的工做中，我遷移過Oracle到Informix、Oracle和SQLServer、Oracle到MySQL。 在目前的公司又由於去O的關係，作了大量的遷移工做，栽了很多坑，因此和你們交流一下在遷移的過程當中的一些實踐。python
分享大綱：sql
-
去O前的準備與考慮數據庫
-
肯定目標數據庫編程
-
表和數據對象的遷移及工具比較windows
-
其它對象的遷移緩存
-
一些性能參數服務器
1、去O前的準備與考慮架構
由於成本預算等多方面緣由，公司決定要去O，在去O以前首先要決定拿什麼來替代Oracle，拿什麼工具將源數據庫的數據導到目標數據庫、怎麼導等的。導的過程的增量數據怎麼處理。導的時候源數據和目標，以及數據的數據類型差別如何處理，像視圖、存儲過程、觸發器這種數據庫對象之間的不一樣怎麼解決，導的時候如何不影響源數據庫性能。導完之後的數據比對以及數據無誤後應用的性能問題都是要考慮的。併發
2、肯定目標數據庫
在咱們作數據遷移以前先確認的就是target database ，就是要遷到什麼數據庫上，通過了一些調研，從速度、流行度等多個方面選擇最終了MySQL。由於相信被Oracle收購後表現會愈來愈好。
固然也想過使用PosgreSQL，不過作了一個測試，發現MySQL5.7的QPS在比一樣配置的PG要高，基於在線事務對性能的要求，最終仍是選擇了MySQL。選擇了MySQL之後，對於MySQL的分支和版本的選擇也很頭痛。Percona增長了不少性能相關補丁，MariaDB支持更多的引擎，官方的版本也能知足目前的需求，從保守的原則上，咱們的核心數據庫最終仍是使用了官方的版本，一些不是太核心的數據庫，其它的分支也有在用。
由於MyCat的支持關係最終選擇的是5.6的版本（目前MyCat1.6對MySQL5.7的支持不是太好），爲了達到像Oracle的DG／OGG同樣穩定的架構，咱們把MySQL的架構作成了雙機房的MHA，而且用了MyCat作了讀寫分離。一樣的Oracle這邊由於同時還有應用在跑，爲了分散Oracle的壓力，全部的同步做業也是在備庫和異機房的OGG端進行的操做。
3、表和數據對象的遷移及工具對比
在選擇了合適的DB來替換Oracle後，下一步就是選擇一個合適的遷移工具來作遷移。咱們在遷移工具的選擇方面花費了大量時間和精力。遷移是一個漫長而困難的工做，咱們在遷移的過程當中也歷經了不一樣的階段，使用了不一樣的方法。從最初級的load csv升級成自已寫的程序，再去找Oracle和MySQL官方推薦的工具，最後也嘗試了一些 ETL的工具，被這麼多工具摧殘以後，幸運的是可以在不一樣的場情下使用不一樣的方式。
接下來咱們對每一種都進行一個簡單的介紹和使用中遇到的一些問題。
一、SQL LOAD
咱們在最先的時候只是進行某個項目的遷移工做，由於時間的關係並無進行遷移工具的選型以及使用，使用了最簡單的方式就是SQL LOAD。
全部的操做步驟比把大象放進冰箱還要簡單，簡單得只要分兩步，第一步把Oracle的數據導成CSV或者SQL，而後再load或者source到MySQL中就能夠了。
把Oracle的數據導成CSV或者SQL能夠用不少工具，好比SQL developer或者toad，不過我仍是更推薦spool，你們應該都用過spool，他能夠結合set把內容輸出到指定的文件中，而後選擇合理的行列分隔符，就能夠產生csv文件了。
使用SQL LOAD的優勢就是速度快和超級簡單，不過一樣的，它也會有不少弊端，它很難作成自動化和全面普及到不少張表上，每有一張表的操做就要寫SQL拼CSV，而後還不能保證是同樣的分隔符，大多數時候對lob字段操做也很麻煩。對相似於comments的評論字段也很難原樣的copy過去。
咱們來看一個簡單的例子：
第一步我先在Oracle這邊建立了一張表，很簡單隻有四列，而後insert了三條數據查看了一下內容。
作了一些簡單的可能會用到的查詢。
看一下導出用的spool的內容，實際用的時候確定會比這個更復雜，要對換行、time、lob等進行更多的函數處理。而後把數據導了出來看一下。
接着我又在MySQL建立一張同樣的表把數據load了進去。load的語法不是咱們今天要分享的重點，它的做用就是把file load into table.能夠指定行列分隔符。 能夠看到數據load進去了三行，同時也給出了三個警告，第二行一個，第三行兩個，分別是int類型的列傳了一個空字符串和時間類型的被截取了。查看一下表裏的數據，發現和預期的不同。
而後把剛剛在Oracle那邊進行的查詢再次查詢一下，發現結果都變得不同了。
這是由於在MySQL裏int類型若是插入的爲空，結果會自動轉成0。
官方文檔上有明確的說明：
An empty field value is interpreted different from a missing field:
For string types, the column is set to the empty string.
For numeric types, the column is set to 0.
For date and time types, the column is set to the appropriate 「zero」 value for the type.
咱們再看一下用etl工具遷移過來的數據，能夠發現數據被insert成了null ，符合了Oracle的意思，其實這就是sqlload時一些弊端，數據類型可能弄得不是原來的數據了。一樣的，咱們也能夠設置成嚴格的模式，int類型的不容許插入null，咱們會在下面的sql_mode裏講到。
二、Python
遷了部分數據以後以爲load數據雖然簡單和快，可是瑜不掩瑕，老是有這樣那樣的問題，遷移以後每每還會同時伴隨着大量的數據修復工做。
很快的，咱們就棄用了這種操做，在這裏要說明一下SQL LOAD的操做由於速度又快又不依賴其它組件，因此適用於數據類型並不複雜的單表操做，而後就寫了python代碼來接替它來完成數據遷移的操做，使用python的話其實也很簡單，能夠分爲三步，第一步就是創建配置表，同時和MySQL的表進行mapping，標識出是全量的仍是增量的，若是是增量的，以什麼作爲增量來處理。第二步就是根據mapping進行code、code、code，最後根據不一樣的入參寫好crontab就能夠進行調度就能夠了。
使用python處理的過程當中能夠對一些數據進行轉換，也更加靈活地配置了一些選項，實現了較強的邏輯控制，固然也有一些缺點：它的速度慢了太多（不過也只比load慢，比起來後面要介紹的Java編寫的軟件仍是快不少）。對於異常的處理也花費了大量的代碼邏輯，同時也要會寫代碼。
咱們能夠簡單來看一下它的實現：
這一個代碼片段，顯示了增量同步每一天的數據邏輯。
這是天天跑批以後生成的log，能夠看出來把warning和error都列了出來，同時也對行數進行了統計。已經能夠說是一個不錯的小型產品了。可看出來6w條數據用了4s和load來比算是慢的，可是和Java之類的比算是快的了。
三、OGG
由於python開發的這一套東西雖然也不算太慢，但由於要本身用代碼實現較強的邏輯，而且有些需求在Oracle的業務尚未徹底下線以前要實時地同步到MySQL裏來，因此咱們又研究了一下OGG的作法。先提早說一下，OGG的應用場景就是那種要求實時而且可能須要回寫數據的。
OGG的用法提及來很簡單，只要配置好Oracle端，配置好MySQL端，而後對應的進程起起來就能夠了。但用過OGG的人都知道配置一套OGG自己就很麻煩了，異構數據庫之間再進行同步的話，調通並可用須要好久的配置時間，因此我大體說一下作法，除非真的有這種硬性需求，否則不推薦使用。
簡單說一下用OGG的過程和注意事項：
一、 5.6版本須要12.1.2版本的OGG才支持
二、異構數據庫之間不支持DDL複製
-
從Oracle同步到MySQL，屬於異構架構，不支持DDL同步，包括添加和刪除字段，添加和刪除索引，重命名錶，表分析統計數據。
-
如果涉及到源端和目標端DDL操做，須要進行源端和目標端同時手工操做。
三、必需要配置defgen，且文件必須放在相同的目錄。
四、若是要是雙向的話，就必須把MySQL端的binglog設置成row
binlog_format: This parameter sets the format of the logs. It must be set to the value of ROW, which directs the database to log DML statements in binary format. Any other log format (MIXED or STATEMENT) causes Extract to abend.
五、GoldenGate對MySQL只支持InnoDB引擎。因此，在建立MySQL端的表的時候，要指定表爲InnoDB引擎。
create table MySQL (name char(10)) engine=innodb;
全部的幫助能夠online help裏去看
http://docs.Oracle.com/goldengate/c1221/gg-winux/GIMYS/system_requirements.htm#GIMYS122
四、MySQL Migration Toolkit
OGG是Oracle官方推薦的工具，使用原理就是基於日誌的結構化數據複製，經過解析源數據庫在線日誌或歸檔日誌得到數據的增量變化，再將這些變化應用到目標數據庫，那MySQL官方沒有提供工具呢？答應是確定的。
MySQL官方一樣也提供一個用於異構之間的數據遷移工具，從MySQL到其它數據庫，或者從其它數據庫到MySQL都是能夠的。這個工具就是MySQL Migration Toolkit。這個工具能夠單獨被下載，也被集成到了MySQL wrokbench裏。不過若是單獨下載的話 只有windows的版本。
https://downloads.MySQL.com/archives/migration/
這是一個基於Java的程序，因此依賴於jar包，使用它的第一步就是load一個odbc.jar。接着就能夠把源端和目標端進行配置鏈接，選擇要導入的對象（能夠包含視圖，可是通常有子查詢的會報錯），進行導入就能夠了。
使用它的優勢就是能夠在MySQL端自動建立表，但有可能自動convert的類型如有問題，須要人爲參與一下進行處理，好比Oracle中一般會對Timestamp類型的數據設置默認值sysdate，但在MySQL中是不能識別的。
缺點就是隻有windows的平臺有，在導大數據量時，極有可能就hang住了。因此我的感受它的適用場景就是一次性導入的小批量的數據。
五、KETTLE
上面提到的幾種工具都是一步一個坑使用過以後發現並無盡善盡美，總有這樣或者那樣的不足，接下來咱們來推薦的就是終級必殺的好用的etl工具：KETTLE。
它是一款純Java編寫的軟件，就像它的名字（水壺）同樣，是用來把各類數據放到一個壺裏，而後以一種指定的格式流出。固然你也可使用DS(datastage)或者Informatica。不過這兩個是收費的，而kettle是免費開源的。
這裏只介紹它最簡單的能知足咱們把數據從Oracle遷移到MySQL的功能。
同理，第一步把jar包load進去，不一樣的是，此次要load的是MySQL的jar包。須要注意的是，若是你的MySQL版本不一樣可能須要load不一樣的jar包。第二步同也是配置鏈接信息，保證你的源和目標都鏈接成功，最後一步就是簡單的拖拖拽拽。最後run一下就能夠了。
它的優勢就是配置起來比OGG快，可是一樣能夠經過job作到實時同步，處理速度和Python旗鼓至關，卻不用本身來寫mapping關係，而且提供了圖形化界面。也能和Migration Toolkit同樣同時建立表（新增一個Java腳本），進行類型轉換，但日誌更詳細。只是可能學習成本高一點，要看的懂一些Java報錯方便調試。
接下來咱們簡單看一個demo：
咱們運行spoon.sh以後能夠打開這個界面。view一界顯示了這個轉換的名字、數據源、處理步驟等，中間區域是你拖拽出來的操做，一個輸入，一個輸出。這就是一個簡單的數據遷移的全部步驟。
打開input的內容，就是很簡單的一條SQL在哪一個源數據庫上抽取數據，固然這條SQL也能夠是拖拽生成出來，相似於congos的拖拽生成報表。千萬要注意的是，不要加分號！
output的內容就顯示豐富了不少，選擇目標數據源，以及會自動的mapping列的信息，還有在遷移之間要不要先清空，遷移過程當中若是遇到問題了會不會停止。
這裏就是顯示了它超越Migration tools的log最細粒度到行級別，能夠更快地分析出問題。
這裏則是詳細的日誌輸出。通常若是定時跑批處理的話，把它重定向到具體的log裏，而後當作發送郵件。
4、其它對象的遷移
上面用了很長的篇幅介紹了一下幾種遷移的工具，每種遷移的方式都是各有千秋，在合適的場景下選擇適合本身的方法進行操做。不過剛剛遷移的都是表和數據對象。咱們都知道在數據庫還有一些其它的對象，像視圖、物化視圖、存儲過程、函數、包，或者一個索引，一樣的SQL是否是也須要改寫，都是咱們須要考慮到的一個因素。
接下來咱們來看一下其它對象怎麼遷移。
一、view
在MySQL裏view是不能夠嵌套子查詢的：
create view v_test as select * from (select * from test) t;
ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause
解決方法就是view的嵌套：
create view v_sub_test as select * from test;
Query OK, 0 rows affected (0.02 sec)
create view v_test as select * from v_sub_test;
Query OK, 0 rows affected (0.00 sec)
二、物化視圖
物化視圖用於預先計算並保存錶鏈接或彙集等耗時較多的操做結果，這樣在執行查詢時，就能夠避免進行這些耗時的操做，而從快速獲得結果。可是MySQL裏沒有這個功能。經過事件調度和存儲過程模擬物化視圖，實現的難點在於更新物化視圖，若是要求實時性高的更新，而且表太大的話，可能會有一些性能問題。
三、Trigger、存儲過程、package
1）Oracle建立觸發器時容許or，可是MySQL不容許。因此遷移時若是有須要寫兩個。
2）兩種數據庫定義變量的位置不一樣，並且MySQL裏不支持%type。這個在Oracle中用得太頻繁了，是個好習慣。
3）elseif的邏輯分支語法不一樣，而且MySQL裏也沒有for循環。
4）在MySQL中不能夠返回cursor，而且聲明時就要賦對象。
5）Oracle用包來把存儲過程分門別類，並且在package裏能夠定義公共的變量/類型，既方便了編程，又減小了服務器的編譯開銷。可MySQL里根本沒有這個概念。因此MySQL的函數也不能夠重載。
6）預約義函數。MySQL裏沒有to_char() to_date()之類的函數，也並非全部的Oracle都是好的，就像substring()和load_file()這樣的函數，MySQL有，Oracle卻沒有。
7）MySQL裏可使用set和=號給變量賦值，但不可使用：=。 並且在MySQL裏沒 || 來拼接字符串。
8）MySQL的註釋必需要求-- 和內容之間有一個空格。
9）MySQL存儲過程當中只能使用leave退出當前存儲過程，不可使用return。
10）MySQL異常對象不一樣，MySQL一樣的能夠定義和處理異常，但對象名字不同。
4､分頁語句
MySQL中使用的是limit關鍵字，但在Oracle中使用的是rownum關鍵字。因此每有的和分頁相關的語句都要進行調整。
5､JOIN
若是你的SQL裏有大量的（+），這絕對是一個很頭疼的問題。須要改寫。
6､group by語句
Oracle裏在查詢字段出現的列必定要出如今group by後面，而MySQL裏卻不用。只是這樣出來的結果可能並非預期的結果。形成MySQL這種奇怪的特性的歸因於sql_mode的設置，一會會詳細說一下sql_mode。不過從Oracle遷移到MySQL的過程當中，group by語句不會有跑不通的狀況，反過來遷移可能就須要很長的時間來調整了。
7､bitmap位圖索引
在Oracle裏能夠利用bitmap來實現布隆過濾，進行一些查詢的優化，同時這一特性也爲Oracle一些數據倉庫相關的操做提供了很好的支持，但在MySQL裏沒有這種索引，因此之前在Oracle裏利於bitmap進行優化的SQL可能在MySQL會有很大的性能問題。
目前也沒有什麼較好的解決方案，能夠嘗試着建btree的索引看是否能解決問題。要求MySQL提供bitmap索引在MySQL的bug庫裏被人看成一箇中級的問題提交了上去，不過至今仍是沒有解決。
8､分區表（Partitioned table）
須要特殊處理，與Oracle的作法不一樣，MySQL會將分區鍵視做主鍵和惟一鍵的一部分。爲確保不對應用邏輯和查詢產生影響，必須用恰當的分區鍵從新定義目標架構。
9､角色
MySQL8.0之前也沒有role的對象。在遷移過程當中若是遇到的角色則是須要拼SQL來從新賦權。不過MySQL更好的一點是MySQL的用戶與主機有關。
10､表情和特殊字符
在Oracle裏咱們通常都選擇AL32UTF8的字符集，已經能夠支付生僻字和emoji的表情了，由於在遷移的時候有的表包含了大量的表情字符，在MySQL裏設置了爲utf8卻不行，導過去以後全部的都是問號，後來改爲了utf8mb4才解決問題，因此推薦默認就把全部的DB都裝成utf8mb4吧。
Oracle和MySQL差別遠遠不止這些，像閃回、AWR這些有不少，這裏只談一些和遷移工做相關的。
5、數據校驗
當數據遷移完成後，如何確保數據的正確遷移、沒有遺漏和錯誤是一個很難的問題。這裏的難不是實現起來困難，而是要把它自動化，達到節省人力的目標有點難，由於二者的數據類型不一樣，數據量偏大，寫一些腳本去作檢查效果不大。
咱們的數據校檢工做主要分爲在導入過程當中的log和警告，在load的時候SHOW WARNINGS和errors，在使用Python、OGG、Kettle等工具時詳細去看每一個errors信息。
一、count(*)
遷移或增量操做完成之後，用最簡單的count(*)去檢查，在MySQL和Oracle上檢查進行比對。若是數據量一致，再進行數據內容的驗證。因爲數據量太大，只進行了抽樣檢測。人工的手動檢驗若是沒有問題了，可使用應用程序對生產數據庫的副本進行測試，在備庫上進行應用程序的測試，從而進行再一次的驗檢。
二、etl工具
另外推薦的一種方式就是使用etl工具配置好MySQL和Oracle的數據源，分別對數據進行抽取，而後生成cube，進行多緯度的報表展示。數據是否有誤差，能夠一目瞭然看清。
數據的完整性驗證是十分重要的，千萬不要怕驗證到錯誤後要花好長時候去抽取同步的操做這一步。由於一旦沒有驗證到錯誤，讓數據進行了使用卻亂掉了，後果將更嚴重。
三、SQL_MODE
https://dev.MySQL.com/doc/refman/5.5/en/sql-mode.html
MySQL服務器可以工做在不一樣的SQL模式下，針對不一樣的客戶端，以不一樣的方式應用這些模式。這樣應用程序就能對服務器操做進行量身定製，以知足本身的需求。這類模式定義了MySQL應支持的SQL語法，以及應該在數據上執行何種確認檢查。
-
TRADITIONAL
設置「嚴格模式」，限制可接受的數據庫輸入數據值（相似於其它數據庫服務器），該模式的簡單描述是當在列中插入不正確的值時「給出錯誤而不是警告」。
-
ONLY_FULL_GROUP_BY
在MySQL的sql_mode=default的狀況下是非ONLY_FULL_GROUP_BY語義，也就是說一條select語句，MySQL容許target list中輸出的表達式是除彙集函數、group by column之外的表達式，這個表達式的值可能在通過group by操做後變成undefined，沒法肯定(實際上MySQL的表現是分組內第一行對應列的值)
select list中的全部列的值都是明確語義。
簡單來講，在ONLY_FULL_GROUP_BY模式下，target list中的值要麼是來自於彙集函數的結果，要麼是來自於group by list中的表達式的值。
Without Regard to any trailing spaces
All MySQL collations are of type PADSPACE. This means that all CHAR, VARCHAR, and TEXT values in MySQL are compared without regard to any trailing spaces. 「Comparison」 in this context does not include the LIKE pattern-matching operator, for which trailing spaces are significant.
MySQL校對規則屬於PADSPACE，MySQL對CHAR和VARCHAR值進行比較都忽略尾部空格，和服務器配置以及MySQL版本都不要緊。
-
explicit_defauls_for_timestamp
MySQL中TIMESTAMP類型和其它的類型有點不同(在沒有設置explicit_defaults_for_timestamp=1的狀況下），在默認狀況下，若是TIMESTAMP列沒有顯式的指明null屬性，那麼該列會被自動加上not null屬性(而其餘類型的列若是沒有被顯式的指定not null，那麼是容許null值的)，若是往這個列中插入null值，會自動設置該列的值爲current timestamp值，表中的第一個TIMESTAMP列，若是沒有指定null屬性或者沒有指定默認值，也沒有指定ON UPDATE語句，那麼該列會自動被加上DEFAULT 。
CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP屬性。第一個TIMESTAMP列以後的其它的TIMESTAMP類型的列，若是沒有指定null屬性，也沒有指定默認值，那該列會被自動加上DEFAULT '0000-00-00 00:00:00'屬性。若是insert語句中沒有爲該列指定值，那麼該列中插入'0000-00-00 00:00:00'，而且沒有warning。
若是咱們啓動時在配置文件中指定了explicit_defaults_for_timestamp=1，MySQL會按照以下的方式處理TIMESTAMP列。
此時若是TIMESTAMP列沒有顯式的指定not null屬性，那麼默認的該列能夠爲null，此時向該列中插入null值時，會直接記錄null，而不是current timestamp。而且不會自動的爲表中的第一個TIMESTAMP列加上DEFAULT CURRENT_TIMESTAMP 和ON UPDATE CURRENT_TIMESTAMP屬性，除非你在建表時顯式的指明。
6、一些性能參數
咱們能夠在導入數據的時候預先的修改一些參數，來獲取最大性能的處理，好比能夠把自適應hash關掉，Doublewrite關掉，而後調整緩存區，log文件的大小，把能變大的都變大，把能關的都關掉來獲取最大的性能，咱們接下來講幾個經常使用的：
-
innodb_flush_log_at_trx_commit
若是innodb_flush_log_at_trx_commit設置爲0，log buffer將每秒一次地寫入log file中，而且log file的flush(刷到磁盤)操做同時進行。該模式下，在事務提交時，不會主動觸發寫入磁盤的操做。
若是innodb_flush_log_at_trx_commit設置爲1，每次事務提交時MySQL都會把log buffer的數據寫入log file，而且flush(刷到磁盤)中去。
若是innodb_flush_log_at_trx_commit設置爲2，每次事務提交時MySQL都會把log buffer的數據寫入log file。可是flush(刷到磁盤)的操做並不會同時進行。該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操做。
注意：因爲進程調度策略問題,這個「每秒執行一次 flush(刷到磁盤)操做」並非保證100%的「每秒」。
-
sync_binlog
sync_binlog 的默認值是0，像操做系統刷其它文件的機制同樣，MySQL不會同步到磁盤中去，而是依賴操做系統來刷新binary log。
當sync_binlog =N (N>0) ，MySQL 在每寫N次 二進制日誌binary log時，會使用fdatasync()函數將它的寫二進制日誌binary log同步到磁盤中去。
注：若是啓用了autocommit，那麼每個語句statement就會有一次寫操做；不然每一個事務對應一個寫操做。
-
max_allowed_packet
在導大容量數據特別是CLOB數據時，可能會出現異常：「Packets larger than max_allowed_packet are not allowed」。這是因爲MySQL數據庫有一個系統參數max_allowed_packet，其默認值爲1048576(1M)，能夠經過以下語句在數據庫中查詢其值：show VARIABLES like '%max_allowed_packet%';
修改此參數的方法是在MySQL文件夾找到my.cnf文件，在my.cnf文件[MySQLd]中添加一行：max_allowed_packet=16777216
-
innodb_log_file_size
InnoDB日誌文件太大，會影響MySQL崩潰恢復的時間，過小會增長IO負擔，因此咱們要調整合適的日誌大小。在數據導入時先把這個值調大一點。避免無謂的buffer pool的flush操做。但也不能把 innodb_log_file_size開得太大，會明顯增長 InnoDB的log寫入操做，並且會形成操做系統須要更多的Disk Cache開銷。
-
innodb_log_buffer_size
InnoDB用於將日誌文件寫入磁盤時的緩衝區大小字節數。爲了實現較高寫入吞吐率，可增大該參數的默認值。一個大的log buffer讓一個大的事務運行，不須要在事務提交前寫日誌到磁盤，所以，若是你有事務好比update、insert或者delete 不少的記錄，讓log buffer 足夠大來節約磁盤I/O。
-
innodb_buffer_pool_size
這個參數主要緩存InnoDB表的索引、數據、插入數據時的緩衝。爲InnoDN加速優化首要參數。通常讓它等於你全部的innodb_log_buffer_size的大小就能夠，
innodb_log_file_size要越大越好。
-
innodb_buffer_pool_instances
InnoDB緩衝池拆分紅的區域數量。對於數GB規模緩衝池的系統，經過減小不一樣線程讀寫緩衝頁面的爭用，將緩衝池拆分爲不一樣實例有助於改善併發性。
總結
-
必定要選擇合適你的遷移工具，沒有哪個工具是最好的。
-
數據的檢驗很是重要，有的時候咱們遷過去很開心，校驗時發生錯誤，這個時候必需要重來。
-
重複地遷移是很正常的，合乎每次遷移可能須要很長時間，總會是有錯誤的，要作好再遷的心態。轉 http://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650760496&idx=1&sn=5d983117b0f5402362d3f6751497b4ac&chksm=f3f9d0a5c48e59b3f4c7e8dda11a4aa1b1e24cb0e9ee30c6c0abdde75a2d546a1b5df3dc3fc7&mpshare=1&scene=23&srcid=0607Yvy0TXxRKJasZ8j1JIUy#rd 做者：馮帥