我有一个表，我在 LIMIT 和 OFFSET 之前执行 ORDER BY 以便分页。
在 ORDER BY 列上添加索引会对性能产生巨大影响（当与较小的 LIMIT 结合使用时）。在一个 500,000 行的表上，我看到添加索引的性能提高了 10,000 倍，只要有一个小的 LIMIT。
但是，索引对高偏移量（即我分页中的后面页面）没有影响。这是可以理解的：b-tree 索引可以很容易地从头开始按顺序迭代而不是找到第 n 项。
计数 b 树索引 似乎有帮助，但我不知道 PostgreSQL 支持这些。还有其他解决方案吗？似乎针对大型 OFFSET 进行优化（尤其是在分页用例中）并不罕见。
不幸的是，PostgreSQL 手册只是说“被 OFFSET 子句跳过的行仍然必须在服务器内部计算；因此大的 OFFSET 可能效率低下。”
【问题讨论】：
标签： database postgresql query-optimization
我对“计数 b 树索引”一无所知，但我们在应用程序中为帮助解决此问题所做的一件事是将查询分成两部分，可能使用子查询。如果您已经这样做了，我很抱歉浪费您的时间。
SELECT *
FROM massive_table
WHERE id IN (
SELECT id
FROM massive_table
WHERE ...
LIMIT 50
OFFSET 500000
);
这里的优点是，虽然它仍然需要计算所有内容的正确顺序，但它不会对整行进行排序——仅对 id 列进行排序。
【讨论】：
LIMIT 和 OFFSET 分页，因为 UI 或复杂查询无法覆盖键集分页。我在一个包含三列的1e7 行的表上对一个有点复杂的查询进行了快速测试，该查询的偏移量为9e6。这种方法的速度提高了大约 270%。
似乎优化了大 偏移量（尤其是在分页中 用例）并不是那么不寻常。
这对我来说似乎有点不寻常。大多数人，大多数时候，似乎不会浏览很多页面。这是我支持的东西，但不会努力优化。
但无论如何。 . .
由于您的应用程序代码知道它已经看到了哪些有序值，它应该能够通过在 WHERE 子句中排除这些值来减少结果集并减少偏移量。假设您订购了单个列，并且按升序排序，您的应用代码可以存储页面上的最后一个值，然后以某种适当的方式将 AND your-ordered-column-name > last-value-seen 添加到 WHERE 子句中。
【讨论】：
您可能需要一个计算索引。
让我们创建一个表：
create table sales(day date, amount real);
并用一些随机的东西填充它：
insert into sales
select current_date + s.a as day, random()*100 as amount
from generate_series(1,20);
按天索引，这里没什么特别的：
create index sales_by_day on sales(day);
创建行位置函数。还有其他方法，这个是最简单的：
create or replace function sales_pos (date) returns bigint
as 'select count(day) from sales where day <= $1;'
language sql immutable;
检查它是否有效（但不要在大型数据集上这样称呼它）：
select sales_pos(day), day, amount from sales;
sales_pos | day | amount
-----------+------------+----------
1 | 2011-07-08 | 41.6135
2 | 2011-07-09 | 19.0663
3 | 2011-07-10 | 12.3715
..................
现在棘手的部分：添加另一个根据 sales_pos 函数值计算的索引：
create index sales_by_pos on sales using btree(sales_pos(day));
这里是你如何使用它。 5 是您的“偏移量”，10 是“限制”：
select * from sales where sales_pos(day) >= 5 and sales_pos(day) < 5+10;
day | amount
------------+---------
2011-07-12 | 94.3042
2011-07-13 | 12.9532
2011-07-14 | 74.7261
...............
它很快，因为当你这样调用它时，Postgres 使用索引中预先计算的值：
explain select * from sales
where sales_pos(day) >= 5 and sales_pos(day) < 5+10;
QUERY PLAN
--------------------------------------------------------------------------
Index Scan using sales_by_pos on sales (cost=0.50..8.77 rows=1 width=8)
Index Cond: ((sales_pos(day) >= 5) AND (sales_pos(day) < 15))
希望对你有帮助。
【讨论】：
最近我解决了一个这样的问题，我写了一篇关于如何面对这个问题的博客。非常喜欢，希望对大家有帮助。 我使用惰性列表方法进行部分获取。我将查询的限制和偏移量或分页替换为手动分页。 在我的示例中，选择返回 1000 万条记录，我获取它们并将它们插入到“时态表”中：
create or replace function load_records ()
returns VOID as $$
BEGIN
drop sequence if exists temp_seq;
create temp sequence temp_seq;
insert into tmp_table
SELECT linea.*
FROM
(
select nextval('temp_seq') as ROWNUM,* from table1 t1
join table2 t2 on (t2.fieldpk = t1.fieldpk)
join table3 t3 on (t3.fieldpk = t2.fieldpk)
) linea;
END;
$$ language plpgsql;
之后，我可以不计算每一行而是使用分配的序列进行分页：
select * from tmp_table where counterrow >= 9000000 and counterrow <= 9025000
从 java 的角度来看，我通过使用惰性列表的部分获取来实现此分页。这是一个从抽象列表扩展并实现 get() 方法的列表。 get方法可以使用数据访问接口继续获取下一组数据并释放内存堆：
@Override
public E get(int index) {
if (bufferParcial.size() <= (index - lastIndexRoulette))
{
lastIndexRoulette = index;
bufferParcial.removeAll(bufferParcial);
bufferParcial = new ArrayList<E>();
bufferParcial.addAll(daoInterface.getBufferParcial());
if (bufferParcial.isEmpty())
{
return null;
}
}
return bufferParcial.get(index - lastIndexRoulette);<br>
}
另一方面，数据访问接口使用查询进行分页，并实现一种方法进行逐步迭代，每25000条记录完成。
可以在此处查看此方法的结果 http://www.arquitecturaysoftware.co/2013/10/laboratorio-1-iterar-millones-de.html
【讨论】：
不使用OFFSET，一个非常有效的技巧是使用临时表：
CREATE TEMPORARY TABLE just_index AS
SELECT ROW_NUMBER() OVER (ORDER BY myID), myID
FROM mytable;
对于 10 000 000 行，它需要大约 10 秒来创建。 然后您想使用 SELECT 或 UPDATE 您的表，您只需：
SELECT * FROM mytable INNER JOIN (SELECT just_index.myId FROM just_index WHERE row_number >= *your offset* LIMIT 1000000) indexes ON mytable.myID = indexes.myID
仅使用 just_index 过滤 mytable 比使用 WHERE myID IN (SELECT ...) 更有效（在我的情况下）使用 INNER JOIN
这样您就不必存储最后一个 myId 值，只需将偏移量替换为使用索引的 WHERE 子句
【讨论】：