ORACLE在处理大表时会出现MYSQL这样的问题吗？极慢，且占用大量的暂时磁盘空间。

Question

MYSQL在进行大表查询时报错ERROR CODE 28 即写入文件失败， C:盘空间不足了！[经分析是由于我的表中的数据量太大了,有200万条记录。当执行完如下SQL后，系统报错ERROR CODE=28,说是在c:\WINDOWS目录下的某个临时文件无法写入了。我看了一下C盘已经没有任何剩余空间了。原因是表太大，所以查询时生成的临时表过大，因此出错。我的C盘有约1G的FREE SPACE.我执行了SQL如下:
SELECT *
FROM TABLE_NAME
ORDER BYE FIELD1, FIELD2.我发现只要带ORDER BY参数肯定会出这个问题，哪怕ORDER BY子句中只带一个字段也是这样的，查询相当相当的慢！最终报错——临时文件无法写入，不带ORDER BY 子句就不会出现这个问题。补充一句：order by 中的字段均是有索引的，同样都是慢！表的storage engine 也试过不同的类型均是这样的慢。难道大表就不能用ORDER BY语句吗？ ORACLE是不是不会出现这种问题，只有MYSQL存在此问题？

Answer 1

Oracle有临时表空间，这个零时表空间的位置不是放置在C盘的话，只要你所在盘的空间足够，应该问题不大。不光光是MySQL有类似的问题，MSSQL也有类似的问题。咱已经是深受其害了，却么办法的说。告诉你两个解决的办法，你看看你使用那个感觉好就用哪个吧。第一种：把导入数据分区了。这个办法是没有办法的办法，你一次写入一部分，就不会出现这种问题了。当然到底写多少，得你自己看了。第二种办法是使用程序导入。这种方法实际上效率最底下，因为首先得让程序分析文件然后构造相应的insert语句进行插入。恩，很好很强大。对于你所说的带有order by的语句执行很慢的话，你看看你的索引是升序吗？如果不是升序，想当然尔会慢死你拉。当然，这个是你查询的库的大小的问题了。比如说咱最近折腾的一个表，一天的数据量是5w，但是当我查询2年的数据的时候，并且使用了orer by，慢啊，慢死我了！而且就是不用order by而是用聚合函数的话，也慢的要命。不慢是不可能的，你的数据量放在哪了啊。还有一个问题就是你的内存严重不足的时候，你的数据库在某些时候访问都会满如蜗牛的。因为你所查询的数据并没有读入到缓存中，想当然后你的缓存命中率低下的可以，当然就会慢。最后一个可能就是CPU的占用问题了。不过这个一般情况下是不会出现的。

Answer 2

说的在理。
Oracle里面有临时表空间的，但是如果你排序过多，临时表空间也会被弄慢的，然后你的速度估计依然很慢。