Oracle和MySQL的数据导入，差别为什么这么大

这是学习笔记的第 2182篇文章

读完需要

分钟

速读仅需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很容易实现。