Oracle和MySQL的数据导入，差别为什么这么大
这是学习笔记的第 2182 篇文章
读完需要
7
分钟速读仅需4分钟
经常会有一些朋友咨询我一些数据库的问题，我注意到一个很有意思的现象，凡是数据导入的问题，基本上都是Oracle类的，MySQL类的问题脑子里想了下竟然一次都没有。
我禁不住开始思考这个未曾注意的问题：
为什么Oracle导入数据会碰到很多的问题？
我们来梳理一下这个问题，分别从导出导入的方式来聊聊。
首先Oracle导出的文件格式就没打算让你拿来即用，导出文件叫做dump,换句话说可以理解这是一个二进制文件。当然实际上这个文件还是有很多的方式去抓取一些关键的信息，比如dump头部的信息可以通过strings来解析得到，我甚至在多年前碰到一个比较棘手的问题，DBA直接vim修改dump文件，这个操作风险和成本是比较高的。
导出有哪些工具呢，主要有exp，expdp这两个工具，expdp的导出性能相对来说可以更加充分利用系统资源，导出的效率更高。exp相对来说对于一些小表还是比较省事的，expdp的导出是基于服务端模式的，也就是你需要做一些数据库层的配置才可以，这无疑增加了一些技术门槛。
不知道大家注意到一个问题没有，那就是Oracle提供了SQL*Loader的工具导入，但是却没有一直提供一种简单有效的导出csv的工具，在导出的时候算是各路英雄汉使尽各种技艺，结合数据字典，结合文本过滤来完成。
MySQL的导出方法相对比较简单，设计思路很有意思，导出的文件就是可以直接打开，可以直接修改的SQL文件。这个设计在很多应用场景中简直绝了,对于开发同学是非常友好的。
导出工具原生的有mysqldump，新版本的是mysqlpump（总体感觉性价比不是很高），当然还有一些补充的第三方工具，比如mydumper之类的。
所以导出这件事情，对于开发同学本身是有一个门槛的，而且在隔行如隔山的情况下，很多同学使用expdp导出的时候都一头雾水。从安全性来看，这个二进制文件是原汁原味的，从灵活性来看，MySQL基于SQL文本的方式是比较便捷。
导出的部分其实不是最主要的，产生隔阂最大的是导入的部分，也是提出问题最多的。
MySQL有什么数据导入工具，可以理解没有，就是SQL文本，你想怎么执行都可以。包括工具mysqldump,mysqlpump导出的文件都是如此，mydump有个配套的myloader算是一个小小的例外。
Oracle有什么导入工具，有，而且是配套的，exp对应imp,expdp对应impdp
常见的数据导入问题有：
1）提示用户创建失败，导入失败
2）提示表空间不存在，导入失败
3）导入时如果创建的数据文件空间不足，导入失败
4）导入时的用户权限不足，导入失败
所以我要导入一个dump文件，如果是exp导出的，解析成本还算低一些。
而如果是expdp导出的，通常很多开发同学都会一脸懵逼。
1）导入要输入一个目录，什么是目录，不是系统目录吗？
2）如果数据库用户已经存在，已经存在10张表，导入的时候默认会直接忽略这10章表，除非你手工删除或者选择额外的选项，比如replace或者truncate等。
3）表空间源端和目标端环境不一致，要想知道到底有哪些表空间不一致，解析dump文件实话说不是很方便，有一个高级选项是remap_tablespaces
4）数据导入之后，业务同学发现有些表还是访问不了，不好，需要重新分配下权限。
通常来说，如果要导入一个dump，在Oracle侧其实是一件很严肃的事情，我们需要创建目录：
create directory dump_data as '/data/dump_data';
grant read,write on directory dump_data to xxxx;
配置表空间存储，有哪些表空间，哪些表空间需要映射，在数据导入之前，这些信息其实是不好提取的。我通常采用的方式是做下预导入，就是找个干净的环境，然后默认选项导入，看看哪些表空间报错，哪些用户报错，把这些信息提取出来，然后重新拼接一个导入命令。
在这个基础上我去构建相关的表空间和数据文件的细节。
对于数据文件，我不大喜欢自动扩展的方式，而是喜欢预创建出来，然后加上自动扩展。
最后就是文件导入
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就像汽车里面的宝马一样，操控性很好，提供了很多专业有效的管理方式。
而Oracle的角色通常都是百GB起，TB上下，这样的数据量管理，就得适配出各种工具特点和特性。我觉得这些工具一直在追求的是更加高效和安全，可能从这个角度理解，Oracle的维护管理模式是需要专人来完成的。
MySQL的管理方式很适合互联网这种变化快，而且数据量相对要小一些的环境。在易用性和学习门槛方便简直是做到了极致，比如你要到处一些有特色的insert语句（比如按照主键排序，显示完全列名等），都可以通过mysqldump很容易实现。
QQ群号：763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
订阅我的微信公众号“杨建荣的学习笔记”，第一时间免费收到文章更新。别忘了加星标，以免错过新推送提示。
7
近期热文
你可能也会对以下话题感兴趣。点击链接就可以查看。
MySQL的主键命名挺任性，就这么定了
华裔教授发现二次方程极简解法,我默默的做了下验算
回答:我不小心把公司的数据库给删了，该不该离职？
迁移到MySQL的业务架构演进实战
数据库修改密码风险高，如何保证业务持续，这几种密码双活方案可以参考
MySQL业务双活的初步设计方案
如何优化MySQL千万级大表，我写了6000字的解读
一道经典的MySQL面试题，答案出现三次反转
业务双活的数据切换思路设计（下）
业务双活的数据切换思路设计（一）
MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意
小白学MySQL要多久?我整理了10多个问题的答案
8
转载热文
你可能也会对以下话题感兴趣，文章来源于转载，点击链接就可以查看。
去IOE or Not?
拉里·佩奇（Larry Page）的伟大归来
《吊打面试官》系列-Redis基础
唯一ID生成算法剖析，看看这篇就够了
关于大数据运维能力的一些思考
DBA菜鸟的进化简史：不忘初心，记工作中踩过的三个坑
美女主持直播,被突发意外打断!湾区网友却高喊: 我懂!超甜