MISSING FIELD VALUES ARE NULL
这个子句说明如果一个记录中某个字段的值没有，则按“空”来处理
qq date "YYYY-MM-DD HH24:MI:SS"
这个子句也比较有用，它用于指定日期型字段的格式码，这个格式码将直接与文件中的格式相对应，这样才能实现数据的正确读取和导入。
LOCATION('data.txt')
这个子句用于指明外部文件的文件名，与目录名拼接在一起，就可以在操作系统中对其进行精确的定位了。
此外，还有很多的参数，我这里都没有写，全部采用了默认值，我也没有太关心过其它参数，能用就行了，呵。
还需要注意一点，这个SQL只检查语法错误，而对于物理文件是否存在，它并不做任何检查，因为此需要大家自己把握好这一点。
好了，到此文件，我们伟大的外部表已经创建完成了，来试一下吧：
select * from test_ext;
如果不出意外，您会看到，平面文件已经用表的形式展现在您的面前了，哈，真是很开心吧。但是到目前为止，虽然我们能以表的形式来展现数据，但是数据实际上还是存储于外部的，还需要把它实际的导入进来才可以。这个导入就更简单了，比如：
insert into test select * from test_ext；
就这么简单，外部表在使用起来和内部表没什么区别。
当然还可以再加上hint功能，让这个插入更加快速。
三．选择适合自己的方式
上面只介绍了两种方式，除此之外，还可以用sql loader等其它方式，也可以在存储过程中对文件进行拆解插入，这两种方式我都试验过了，与外部表的性能类似，但是使用更加麻烦，也不便于程序调用，所以我推荐外部表的方式。
在数据量较小的时候，比如100条记录，几种方式真的没有太大区别，1秒和0.01秒对于客户来说，没有什么实质的差异，但是如果是50万或更多的记录数，就要考虑这个问题了。下面是我的几个测试数据可以供大家参考：
如果您关心性能，从上表可以很明显找到适合您的导入方案了。
四．结论
虽然外部表的方式效率非常高，但是操作复杂也是它的一个弊端，它会给您的应用程序带来很多不必要的麻烦，而且如果应用程序与数据库服务器不在一起，甚至操作系统都不一样，还要增加上传文件的操作，几个步骤之间的协调关系也需 做很多的考虑。
总之，上述方式是一个不错的方式，仅供大家选择。