如何在并发插入数据上使用 UUID v4 和创建时间进行分页？

Question

语境：

出于好奇，我正在为我的应用程序进行负载测试。然后结果发生了很多并发插入。

在创建端点上进行负载测试后，我尝试在 Fetch 端点上进行负载测试，包括测试分页。对于分页，我组合了两列：id（带有 UUID v4 的 PK）和created_time。另外，我还添加了索引以加快排序速度。我从这里遵循这些解决方案。

• /sf/answers/4126074221/
• https://dba.stackexchange.com/a/205385/117466

问题：

由于数据是同时插入的，因此有几行具有相同的created_time，在我的例子中，同一时间戳最多有100（行）。

这是我的表架构，一个示例

BEGIN;

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

DROP TABLE IF EXISTS "payment_with_uuid";

CREATE TABLE "payment_with_uuid" (
 id VARCHAR(255) PRIMARY KEY NOT NULL DEFAULT (uuid_generate_v4()),
 amount integer NULL,
 name varchar(255) default NULL,
 created_time TIMESTAMPTZ NOT NULL DEFAULT (now() AT TIME ZONE 'utc')
);

CREATE INDEX idx_payment_pagination ON payment_with_uuid (created_time, id);

COMMIT;

这是我的查询，

SELECT  * from payment_with_uuid ORDER BY  created_time DESC, id DESC LIMIT 10;

它将返回 10 行付款，假设数据如下所示，并假设时间戳在第 100 行之前都是相同的

+-------------------------------------+--------+------------+---------------------+
| id                                  | amount | name       | created_time        |
+-------------------------------------+--------+------------+---------------------+
| ffffa567-e95a-4c8b-826c-e2be6acaeb6d| 32003  | Allistair  | 2020-05-24 21:27:10 | 
| ffff2dd6-3872-4acc-afec-7a568935f729| 32003  | James      | 2020-05-24 21:27:10 | 
| fffe3477-1710-45c4-b554-b539a9ee8fa7| 32003  | Kane       | 2020-05-24 21:27:10 | 

为了获取下一页，这是我的查询，

+-------------------------------------+--------+------------+---------------------+
| id                                  | amount | name       | created_time        |
+-------------------------------------+--------+------------+---------------------+
| ffffa567-e95a-4c8b-826c-e2be6acaeb6d| 32003  | Allistair  | 2020-05-24 21:27:10 | 
| ffff2dd6-3872-4acc-afec-7a568935f729| 32003  | James      | 2020-05-24 21:27:10 | 
| fffe3477-1710-45c4-b554-b539a9ee8fa7| 32003  | Kane       | 2020-05-24 21:27:10 | 

因此，分页混乱，就像第一页上存在的一些记录可能存在于第二页、第三页或任何页面上。有时记录会丢失。

问题和注意事项：

• 有没有办法以更优雅的方式做到这一点？

• 我知道使用自动增量可以解决这个问题，但是选择自动增量 id 对我们来说不是一个选择，因为我们试图使所有内容在微服务中保持一致，许多服务已经使用 UUID 作为 PK。

• 使用 offset 和 limit 也可以解决这个问题，但据我所知，这不是一个好的做法，正如本文所解释的https://use-the-index-luke.com/no-offset

• 我正在使用 Postgres 11.4

Answer 1

SELECT * FROM payment_with_uuid 
WHERE 
created_time <= '2020-05-24 21:27:10' :: timestamp
AND 
id <'fffe3477-1710-45c4-b554-b539a9ee8fa7' 
ORDER BY created_time DESC, id DESC LIMIT 10;

这是错误的，但它不应该导致您指出的同一行显示在第 1 页、第 2 页等上的问题。相反，它会导致大多数行根本无法显示，因为这两个过滤器是独立实现的。您只需要在created_time 过滤器的范围内实现id 过滤器。我想优雅是一个意见问题，但在我看来，最优雅的解决方案是元组比较器，类似于您尝试在原始问题中包含的内容。

SELECT * FROM payment_with_uuid 
WHERE 
(created_time,id) < ('2020-05-24 21:27:10' :: timestamp, 'fffe3477-1710-45c4-b554-b539a9ee8fa7') 
ORDER BY created_time DESC, id DESC LIMIT 10;

现在时间戳应该非常准确，但它看起来不像你的那样。它如何四舍五入到最接近的秒？在我手中它看起来更像2020-05-25 09:16:29.380925-04

如果由于某种原因您不想使用元组比较器，那么您需要包含时间戳两次，一次表示小于，一次表示等于：

WHERE 
created_time < '2020-05-24 21:27:10' :: timestamp
OR  
(
    created_time = '2020-05-24 21:27:10' :: timestamp 
    AND 
    id <'fffe3477-1710-45c4-b554-b539a9ee8fa7' 
)

除了不太优雅之外，这可能不会非常有效地使用索引。您可以使用布尔推理来重写它以避免顶级 OR，以便它可以使用索引，但这样它会变得更难以阅读和理解。