【发布时间】：2017-01-11 23:56:31
【问题描述】：
有 1500 万行的表格保存用户的收件箱数据
user_id | integer | not null
subject | character varying(255) | not null
...
last_message_id | integer |
last_message_at | timestamp with time zone |
deleted_at | timestamp with time zone |
简而言之，这里是慢查询：
SELECT *
FROM dialogs
WHERE user_id = 1234
AND deleted_at IS NULL
LIMIT 21
完整查询： （删除无关字段）
SELECT "dialogs"."id", "dialogs"."subject", "dialogs"."product_id", "dialogs"."user_id", "dialogs"."participant_id", "dialogs"."thread_id", "dialogs"."last_message_id", "dialogs"."last_message_at", "dialogs"."read_at", "dialogs"."deleted_at", "products"."id", ... , T4."id", ... , "messages"."id", ...,
FROM "dialogs"
LEFT OUTER JOIN "products" ON ("dialogs"."product_id" = "products"."id")
INNER JOIN "auth_user" T4 ON ("dialogs"."participant_id" = T4."id")
LEFT OUTER JOIN "messages" ON ("dialogs"."last_message_id" = "messages"."id")
WHERE ("dialogs"."deleted_at" IS NULL AND "dialogs"."user_id" = 9069)
ORDER BY "dialogs"."last_message_id" DESC
LIMIT 21;
解释：
Limit (cost=1.85..28061.24 rows=21 width=1693) (actual time=4.700..93087.871 rows=17 loops=1)
-> Nested Loop Left Join (cost=1.85..9707215.30 rows=7265 width=1693) (actual time=4.699..93087.861 rows=17 loops=1)
-> Nested Loop (cost=1.41..9647421.07 rows=7265 width=1457) (actual time=4.689..93062.481 rows=17 loops=1)
-> Nested Loop Left Join (cost=0.99..9611285.66 rows=7265 width=1115) (actual time=4.676..93062.292 rows=17 loops=1)
-> Index Scan Backward using dialogs_last_message_id on dialogs (cost=0.56..9554417.92 rows=7265 width=102) (actual time=4.629..93062.050 rows=17 loops=1)
Filter: ((deleted_at IS NULL) AND (user_id = 9069))
Rows Removed by Filter: 6852907
-> Index Scan using products_pkey on products (cost=0.43..7.82 rows=1 width=1013) (actual time=0.012..0.012 rows=1 loops=17)
Index Cond: (dialogs.product_id = id)
-> Index Scan using auth_user_pkey on auth_user t4 (cost=0.42..4.96 rows=1 width=342) (actual time=0.009..0.010 rows=1 loops=17)
Index Cond: (id = dialogs.participant_id)
-> Index Scan using messages_pkey on messages (cost=0.44..8.22 rows=1 width=236) (actual time=1.491..1.492 rows=1 loops=17)
Index Cond: (dialogs.last_message_id = id)
Total runtime: 93091.494 ms
(14 rows)
-
OFFSET未使用 -
user_id字段上有索引。 -
deleted_at上的索引未使用，因为选择性很高（90% 的值实际上为 NULL）。部分索引 (... WHERE deleted_at IS NULL) 也无济于事。 - 如果查询命中了很久以前创建的结果的某些部分，它会变得特别慢。然后查询必须过滤并丢弃其间的数百万行。
索引列表：
Indexes:
"dialogs_pkey" PRIMARY KEY, btree (id)
"dialogs_deleted_at_d57b320e_uniq" btree (deleted_at) WHERE deleted_at IS NULL
"dialogs_last_message_id" btree (last_message_id)
"dialogs_participant_id" btree (participant_id)
"dialogs_product_id" btree (product_id)
"dialogs_thread_id" btree (thread_id)
"dialogs_user_id" btree (user_id)
目前我正在考虑仅查询最近的数据（即具有适当索引的... WHERE last_message_at > <date 3-6 month ago> (BRIN?)。
加快此类查询的最佳做法是什么？
【问题讨论】：
-
如果您只使用
WHERE deleted_at IS NULL运行解释查询，您会看到预期的速度吗？如果是这样，我建议在同一索引中的user_id和deleted_at列上放置一个索引。通常这是必需的，因为您无法按照您想象的方式合并两个单独的索引，但是将索引存储在多个列上会产生您期望的更快的查询时间。 -
你说deleted_at上的索引没有被使用。但是您的解释表明，没有 seq 扫描。这是对
dialogs_last_message_id的反向索引扫描。怎么了？粘贴完整的查询计划。 -
请也发布您的索引定义。 部分索引也无济于事是什么意思？
user_id上的索引，deleted_at IS NULL应该会有所帮助。 -
@EvanCarroll - 我猜它正在使用
user_id索引。过滤 deleted_at 只是循环结果集和哑比较 deleted_at 与 NULL 直到结果中有 11 个项目。 -
首先在 (user_id, last_message_id) 上创建部分索引，条件为
WHERE deleted_at IS NULL。
标签： postgresql