我想从表格中的第 N 行到第 M 行中选择行。我不想使用任何 orderby，因为表数据很大，有 3800 万。我找到了一个解决方案，它说使用以下查询
SELECT *
FROM (select suppliers2.*, rownum rnum from
(select * from suppliers ORDER BY supplier_name) suppliers2
where rownum <= 5 )
WHERE rnum >= 3;
但由于它有两个 select 语句，而且我的表非常大，有 3800 万行，我想知道是否有任何其他方式对数据库不征税。我也可以看到我可以使用减号，但我再次看到性能问题。我基本上想选择前一百万行并将其放入文件中，然后选择第二百万行并将其放入文件中，依此类推。请帮忙。
【问题讨论】：
我不清楚为什么首先需要对结果进行分页。您显然想要抓取任意 100 万行，将该数据放入一个文件中，再抓取任意 100 万行（确保您不会两次抓取同一行），将其放入第二个文件，然后重复该过程直到您已经生成了 38 个单独的文件。发出 38 个单独的 SELECT 语句而不是发出单个 SELECT 语句并让调用者简单地将它提取的前一百万行写入一个文件，然后将它提取的第二百万行写入一个文件，你有什么好处？第二个文件？
您是否尝试从 38 个独立的工作进程并行生成文件？如果是这样，您似乎不太可能从并行写入中获得很多好处，但会大大增加数据库必须完成的工作量。我想我可以设想一个系统，其中客户端的写入速度很慢，但易于并行化，而服务器上的读取速度非常快，并且有大量内存可用于在数据库服务器上进行排序，因此写入文件可能会更快平行线。但是具有这些特征的系统并不多。如果您确实想使用并行性，通常最好让客户端向数据库发出单个 SELECT 并允许数据库并行运行该 SELECT 语句。
如果您确定在页面中选择结果，那么您发布的查询应该是最有效的。存在嵌套的 select 语句这一事实与性能分析并不特别相关。查询只会命中表一次。如果它需要获取和排序所有 3800 万行以确定哪些是第 3 行，哪些是第 5 行，它仍然可能非常昂贵。当您查找后续数据页时，它可能会逐渐变慢。获取第 37,000,001 - 38,000,000 行至少需要读取整个表。这就是并行编写文件不太可能有帮助的一个原因——拉取数据的前几页可能比拉取最后一页数据效率高得多，因为您将受到该查询的限制以及通过网络提取 3800 万行所需的时间。
【讨论】：
SELECT * FROM your_table。打开文件#1。获取 100 万行，将它们写入文件 #1。关闭文件 #1。打开文件#2。从同一个游标中获取 100 万行，将它们写入文件 #2。重复 38 次。
SELECT 将远低于 38 个单独的 SELECT 语句，特别是因为单个语句不需要 ORDER BY。如果您想将 3800 万行数据写入文件，您将无法从数据库中读取 3800 万行数据。读取 3800 万行并非易事，但在现代硬件上也不是很多。