sql - Postgres：按日期时间优化查询

Question

我有一个包含日期时间字段“updated_at”的表。我的很多查询将使用范围查询来查询该字段，例如 update_at > 某个日期的行。

我已经为 updated_at 添加了一个索引，但我的大多数查询仍然很慢，即使我对返回的行数有限制。

我还能做些什么来优化查询日期时间字段的查询？

Answer 1

通常数据库优化器不会选择为开放范围使用索引，例如updated_at > somedate.

但是，在许多情况下，数据时间列不会超过“现在”，因此您可以通过使用以下方法> somedate将条件转换为范围between来保留语义：

where updated_at between somedate and current_timestamp

between谓词更有可能导致优化器选择使用索引。

---

如果这种方法提高了您的查询性能，请发布。

Answer 2

对于任何给定的查询，索引的使用取决于使用该索引与顺序扫描相比的成本

开发人员经常认为，因为有索引，所以查询应该运行得更快，如果查询运行缓慢，索引就是解决方案。这通常是查询将返回几个元组的情况。但是随着结果中元组数量的增加，使用索引的成本可能会增加。

您正在使用 postgres。Postgres 不支持围绕给定属性进行聚类。这意味着 postgres 在遇到范围查询（类型为 att > a 和 att < b）时需要计算结果中元组数量的估计值（确保经常清理数据库）和使用成本与执行顺序扫描相比的索引。然后它将决定使用什么方法。

您可以通过运行检查此决定

EXPLAIN ANALYZE <query>; 

在 psql 中。它会告诉你它是否使用索引。

如果您真的非常想使用索引而不是顺序扫描（有时需要）并且您真的知道自己在做什么，您可以在计划器常量中更改顺序扫描的成本或禁用顺序扫描以支持的任何其他方法。有关详细信息，请参阅此页面：

http://www.postgresql.org/docs/9.1/static/runtime-config-query.html

确保浏览正确版本的文档。

--dmg

Answer 3

我在一个有近 1M 行的表中有一个类似的案例。

所以我在visited_at（日期时间字段）上创建了一个索引b-tree，并尝试查询所有行：

explain analyze select mes,count(usuario) as usuarios
from (
   SELECT distinct coalesce(usuario, ip) as usuario, (extract(year from visited_at), extract(month from visited_at))   AS mes
     FROM pageview 
     ) as usuarios
group by 1
order by 1

我有：

GroupAggregate (cost=445468.78..451913.54 rows=200 width=64) (actual time=31027.876..31609.754 rows=8 loops=1)
-> Sort (cost=445468.78..447616.37 rows=859035 width=64) (actual time=31013.501..31439.350 rows=358514 loops=1)
Sort Key: usuarios.mes
Sort Method: external merge Disk: 24000kB
-> Subquery Scan on usuarios (cost=247740.16..263906.75 rows=859035 width=64) (actual time=23121.403..28200.175 rows=358514 loops=1)
-> Unique (cost=247740.16..255316.40 rows=859035 width=48) (actual time=23121.400..28129.538 rows=358514 loops=1)
-> Sort (cost=247740.16..250265.57 rows=1010166 width=48) (actual time=23121.399..27559.241 rows=1010702 loops=1)
Sort Key: (COALESCE(pageview.usuario, (pageview.ip)::text)), (ROW(date_part('year'::text, pageview.visited_at), date_part('month'::text, pageview.visited_at)))
Sort Method: external merge Disk: 66944kB
-> Seq Scan on pageview (cost=0.00..84842.49 rows=1010166 width=48) (actual time=0.012..1909.324 rows=1010702 loops=1)
Total runtime: 31632.012 ms

这意味着对索引之前的查询没有任何改进。

但是所以我将行减少到 current_date-31

explain analyze select mes,count(usuario) as usuarios
from (
   SELECT distinct coalesce(usuario, ip) as usuario, (extract(year from visited_at), extract(month from visited_at))   AS mes
     FROM pageview 
     where visited_at > current_date - 31
     ) as usuarios
group by 1
order by 1

并得到

 -> Sort (cost=164735.62..165310.93 rows=230125 width=64) (actual time=9532.343..9602.743 rows=90871 loops=1)
Sort Key: usuarios.mes
Sort Method: external merge Disk: 5872kB
-> Subquery Scan on usuarios (cost=122598.79..126929.62 rows=230125 width=64) (actual time=7251.344..9178.901 rows=90871 loops=1)
-> Unique (cost=122598.79..124628.37 rows=230125 width=48) (actual time=7251.343..9157.837 rows=90871 loops=1)
-> Sort (cost=122598.79..123275.32 rows=270610 width=48) (actual time=7251.341..8932.541 rows=294915 loops=1)
Sort Key: (COALESCE(pageview.usuario, (pageview.ip)::text)), (ROW(date_part('year'::text, pageview.visited_at), date_part('month'::text, pageview.visited_at)))
Sort Method: external merge Disk: 18864kB
-> Bitmap Heap Scan on pageview (cost=5073.60..81528.85 rows=270610 width=48) (actual time=111.950..1877.603 rows=294915 loops=1)
Recheck Cond: (visited_at > (('now'::cstring)::date - 31))
Rows Removed by Index Recheck: 338268
-> Bitmap Index Scan on visited_at_index (cost=0.00..5005.94 rows=270610 width=0) (actual time=109.874..109.874 rows=294915 loops=1)
Index Cond: (visited_at > (('now'::cstring)::date - 31))
Total runtime: 9687.460 ms

迄今为止，我在转换日期时间方面有一个小的改进（visited_at::date）

explain analyze select mes,count(usuario) as usuarios
from (
   SELECT distinct coalesce(usuario, ip) as usuario, (extract(year from visited_at::date), extract(month from visited_at::date))   AS mes
     FROM pageview 
     where visited_at::date > current_date - 31
     ) as usuarios
group by 1
order by 1

并得到

GroupAggregate (cost=201976.97..204126.56 rows=200 width=64) (actual time=9040.196..9102.098 rows=2 loops=1)
-> Sort (cost=201976.97..202692.83 rows=286345 width=64) (actual time=9035.624..9058.457 rows=88356 loops=1)
Sort Key: usuarios.mes
Sort Method: external merge Disk: 5704kB
-> Subquery Scan on usuarios (cost=149102.66..154491.53 rows=286345 width=64) (actual time=7511.231..8840.270 rows=88356 loops=1)
-> Unique (cost=149102.66..151628.08 rows=286345 width=48) (actual time=7511.229..8823.647 rows=88356 loops=1)
-> Sort (cost=149102.66..149944.47 rows=336722 width=48) (actual time=7511.227..8666.667 rows=287614 loops=1)
Sort Key: (COALESCE(pageview.usuario, (pageview.ip)::text)), (ROW(date_part('year'::text, ((pageview.visited_at)::date)::timestamp without time zone), date_part('month'::text, ((pageview.visited_at)::date)::timestamp without time zone)))
Sort Method: external merge Disk: 18408kB
-> Seq Scan on pageview (cost=0.00..97469.57 rows=336722 width=48) (actual time=0.018..1946.139 rows=287614 loops=1)
Filter: ((visited_at)::date > (('now'::cstring)::date - 31))
Rows Removed by Filter: 722937
Total runtime: 9108.644 ms

这是对我有用的调整：

1) 索引 b-tree (主要) 2) 转换到日期 (小差异)

10 秒仍然是响应用户的重要时间。

所以我的解决方案是创建表month_users并使用一次

insert from month_users select mes,count(usuario) as usuarios
from (
   SELECT distinct coalesce(usuario, ip) as usuario, (extract(year from visited_at), extract(month from visited_at))   AS mes
     FROM pageview 
     ) as usuarios
group by 1
order by 1

并使用

select * from month_users

结果：

Seq Scan on usuarios_mes (cost=0.00..21.30 rows=1130 width=42) (actual time=0.302..0.304 rows=8 loops=1)
Total runtime: 0.336 ms

现在是可以接受的结果！

最终的解决方案还是要考虑如何定期更新表格结果。

Answer 4

假设正在使用索引但性能仍然很差，我能想到的唯一补救措施是按该索引对表进行聚类：http ://www.postgresql.org/docs/9.1/static/sql-cluster.html

这会将具有相同 update_at 值的行移动到物理上位于同一位置，从而提高通过索引访问该表的查询的性能，特别是对于大范围扫描。

不过请注意文档中的警告，并注意随着行的更新，不会保留集群。

还：

当一个表被集群时，会在它上面获取一个 ACCESS EXCLUSIVE 锁。这可以防止任何其他数据库操作（读取和写入）在 CLUSTER 完成之前对表进行操作。

基于这些限制，它可能不是您的案例的可行解决方案，但可能对其他人有用。