經(jīng)常會有一些朋友咨詢我一些數(shù)據(jù)庫的問題，我注意到一個很有意思的現(xiàn)象，凡是數(shù)據(jù)導入的問題，基本上都是Oracle類的，MySQL類的問題腦子里想了下竟然一次都沒有。

我禁不住開始思考這個未曾注意的問題：

為什么Oracle導入數(shù)據(jù)會碰到很多的問題？

我們來梳理一下這個問題，分別從導出導入的方式來聊聊。

首先Oracle導出的文件格式就沒打算讓你拿來即用，導出文件叫做dump,換句話說可以理解這是一個二進制文件。當然實際上這個文件還是有很多的方式去抓取一些關鍵的信息，比如dump頭部的信息可以通過strings來解析得到，我甚至在多年前碰到一個比較棘手的問題，DBA直接vim修改dump文件，這個操作風險和成本是比較高的。

導出有哪些工具呢，主要有exp，expdp這兩個工具，expdp的導出性能相對來說可以更加充分利用系統(tǒng)資源，導出的效率更高。exp相對來說對于一些小表還是比較省事的，expdp的導出是基于服務端模式的，也就是你需要做一些數(shù)據(jù)庫層的配置才可以，這無疑增加了一些技術門檻。

不知道大家注意到一個問題沒有，那就是Oracle提供了SQL*Loader的工具導入，但是卻沒有一直提供一種簡單有效的導出csv的工具，在導出的時候算是各路英雄漢使盡各種技藝，結合數(shù)據(jù)字典，結合文本過濾來完成。

MySQL的導出方法相對比較簡單，設計思路很有意思，導出的文件就是可以直接打開，可以直接修改的SQL文件。這個設計在很多應用場景中簡直絕了,對于開發(fā)同學是非常友好的。

導出工具原生的有mysqldump，新版本的是mysqlpump（總體感覺性價比不是很高），當然還有一些補充的第三方工具，比如mydumper之類的。

所以導出這件事情，對于開發(fā)同學本身是有一個門檻的，而且在隔行如隔山的情況下，很多同學使用expdp導出的時候都一頭霧水。從安全性來看，這個二進制文件是原汁原味的，從靈活性來看，MySQL基于SQL文本的方式是比較便捷。

導出的部分其實不是最主要的，產(chǎn)生隔閡最大的是導入的部分，也是提出問題最多的。

MySQL有什么數(shù)據(jù)導入工具，可以理解沒有，就是SQL文本，你想怎么執(zhí)行都可以。包括工具mysqldump,mysqlpump導出的文件都是如此，mydump有個配套的myloader算是一個小小的例外。

Oracle有什么導入工具，有，而且是配套的，exp對應imp,expdp對應impdp

常見的數(shù)據(jù)導入問題有：

1）提示用戶創(chuàng)建失敗，導入失敗

2）提示表空間不存在，導入失敗

3）導入時如果創(chuàng)建的數(shù)據(jù)文件空間不足，導入失敗

4）導入時的用戶權限不足，導入失敗

所以我要導入一個dump文件，如果是exp導出的，解析成本還算低一些。

而如果是expdp導出的，通常很多開發(fā)同學都會一臉懵逼。

1）導入要輸入一個目錄，什么是目錄，不是系統(tǒng)目錄嗎？

2）如果數(shù)據(jù)庫用戶已經(jīng)存在，已經(jīng)存在10張表，導入的時候默認會直接忽略這10章表，除非你手工刪除或者選擇額外的選項，比如replace或者truncate等。

3）表空間源端和目標端環(huán)境不一致，要想知道到底有哪些表空間不一致，解析dump文件實話說不是很方便，有一個高級選項是remap_tablespaces

4）數(shù)據(jù)導入之后，業(yè)務同學發(fā)現(xiàn)有些表還是訪問不了，不好，需要重新分配下權限。

通常來說，如果要導入一個dump，在Oracle側其實是一件很嚴肅的事情，我們需要創(chuàng)建目錄：

create directory dump_data as ’/data/dump_data’;

grant read,write on directory dump_data to xxxx;

配置表空間存儲，有哪些表空間，哪些表空間需要映射，在數(shù)據(jù)導入之前，這些信息其實是不好提取的。我通常采用的方式是做下預導入，就是找個干凈的環(huán)境，然后默認選項導入，看看哪些表空間報錯，哪些用戶報錯，把這些信息提取出來，然后重新拼接一個導入命令。

在這個基礎上我去構建相關的表空間和數(shù)據(jù)文件的細節(jié)。

對于數(shù)據(jù)文件，我不大喜歡自動擴展的方式，而是喜歡預創(chuàng)建出來，然后加上自動擴展。

最后就是文件導入

impdp system/xxxx directory=dump_data dumpfile=test.DMP logfile=impdp_test.log remap_tablespace=TEST_DATA1:DATA,TEST_DATA2:DATA,TEST_INDEX1:IDX,TEST_INDEX2:IDX

對于Oracle DBA來說，這應該是再正常不過的事情了，而且有很多地方要做到細致周到的多，但是這樣一個過程對于一個外行來說，成本就很高了。

總是有一種感覺，Oracle就像汽車里面的寶馬一樣，操控性很好，提供了很多專業(yè)有效的管理方式。

而Oracle的角色通常都是百GB起，TB上下，這樣的數(shù)據(jù)量管理，就得適配出各種工具特點和特性。我覺得這些工具一直在追求的是更加高效和安全，可能從這個角度理解，Oracle的維護管理模式是需要專人來完成的。

MySQL的管理方式很適合互聯(lián)網(wǎng)這種變化快，而且數(shù)據(jù)量相對要小一些的環(huán)境。在易用性和學習門檻方便簡直是做到了極致，比如你要到處一些有特色的insert語句（比如按照主鍵排序，顯示完全列名等），都可以通過mysqldump很容易實現(xiàn)。

以上就是Oracle和MySQL的數(shù)據(jù)導入為何差別這么大的詳細內容，更多關于Oracle和MySQL的數(shù)據(jù)導入的資料請關注好吧啦網(wǎng)其它相關文章！