获取表的最后一个值的时间越来越长
我的 Postgres 数据库中有一个表,每 10 分钟存储一次值。我现在在该表中有很多记录(我不想删除旧的记录)。基本上,该行包含一个值和一个时间戳。我的 SQL 请求没有优化,因为它似乎循环遍历整个表...
SELECT value, date FROM measures order by date desc limit 1
我还尝试在日期上添加过滤器,例如:(
SELECT value, date FROM measures WHERE date > date '2011-10-20' order by date desc limit 1
当然日期是动态的)。但同样的事情......
是否需要索引或者可以优化查询吗?
I have a table, in my Postgres database, that stores values every 10 minutes. I now have a lot of records in that table (I do not want to delete the old ones). Basically, the row contains a value and a timestamp. My SQL request is not optimized as it seems to loop through the whole table...
SELECT value, date FROM measures order by date desc limit 1
I also tried to add a filter on the date, for instance like:
SELECT value, date FROM measures WHERE date > date '2011-10-20' order by date desc limit 1
(with of course the date being dynamical). But same thing...
Is an index needed or can the query be optimized ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
首先,您不应将时间戳列命名为
date
。 “日期”不是“时间戳”。另外,虽然 PostgreSQL 允许这样做,但它是一个保留字 在任何 SQL 标准中。 (不过,出于本答案的目的,我将坚持使用日期
)除此之外,不需要 表达式上的索引 和像 Tommy 提议的
WHERE
子句。 (日期(创建时间)
)。 普通 B 树索引和不带WHERE
子句的查询使工作更简单、更快。然后您的查询将按原样运行,速度快如闪电。 B 树索引可用于升序和降序排序,同样有效。阅读有关索引和 ORDER BY - 涵盖了您需要了解的针对您的案例的大部分内容。
如果您的表确实很大并且您担心索引大小,您可以使用部分索引可大幅减小大小。像这样:
然后您的查询必须包含与部分索引完全相同的
WHERE
子句。像这样:First off, you shouldn't name your timestamp column
date
. A 'date' is not a 'timestamp'. Also, while it's allowed in PostgreSQL, it's a reserved word in any SQL standard. (I'll stick todate
for the purpose of this answer, though)That aside, there is no need for an index on an expression and a
WHERE
clause like Tommy proposes. (date(created_at)
). A plain B-tree index and a query with noWHERE
clause does the job simpler and faster.Then your query will work as it is, lightening fast. B-tree indexes can be used for ascending and descending sort order equally effective. Read the chapter on Indexes and ORDER BY in the manual - covers most of what you need to know for your case.
If your table is real huge and you are concerned about index size, you can use a partial index for drastically reduced size. Like this:
Then your query will have to include the exact same
WHERE
clause as is used for the partial index. Like this:首先 - 动态+1。你是对的,你的查询变得越来越慢,因为没有索引,你每次查询一个值时都会进行全表扫描。我不是一个强大的 postgres DB 用户,但看起来您确实可以在日期字段上放置索引(因为这是您主要查询的内容)。
摘自本文:
。根据您的具体情况,您可能会发现该文章中的一些其他信息也很有趣。
First off - +1 for dynamical. You're right, your query is getting slower as without indexes, you are doing a full table scan each time you query a value. I am not a strong postgres DB user, but it does look like you can place an index on your date field (since that is what you are mostly querying by).
From this article:
You may find some other information in that article interesting as well depending on your specific scenario.