SQL:优化 DateTime 字段上的密集 SELECT

发布于 2024-08-30 14:45:22 字数 714 浏览 1 评论 0原文

我有一个用于安排某些事件的应用程序。所有这些事件都必须在每个预定时间之后进行审查。

所以基本上我们有3个表:

  • items(id, name)
  • scheduled_items(id, item_id, execute_at - 日期时间) - item_id 列有一个索引选项。
  • reviewed_items(id, item_id, created_at - datetime) - item_id 列有一个索引选项。

因此该应用程序的核心功能是“给我当前的任何项目(尚未审核)”。

我如何优化该解决方案以提高速度(因为它是非常核心的业务功能,而不是微观优化)?

我认为向日期时间字段添加索引没有任何意义,因为该字段的基数或唯一性非常高,并且索引不会提供任何(?)加速。正确吗?

你会推荐什么?我应该尝试 no-SQL 吗?

--

mysql -V
5.075

我在有意义的地方使用缓存(memcached)。

已更新。

I have an application for scheduling certain events. And all these events must be reviewed after each scheduled time.

So basically we have 3 tables:

  • items(id, name)
  • scheduled_items(id, item_id, execute_at - datetime) - item_id column has an index option.
  • reviewed_items(id, item_id, created_at - datetime) - item_id column has an index option.

So core function of the application is "give me any items(which are not yet reviewed) for the actual moment".

How can I optimize this solution for speed(because it is very core business feature and not micro optimization)?

I suppose that adding index to the datetime fields doesn't make any sense because the cardinality or uniqueness on that fields are very high and index won't give any(?) speed-up. Is it correct?

What would you recommend? Should I try no-SQL?

--

mysql -V
5.075

I use caching(memcached) where it makes sence.

updated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

戈亓 2024-09-06 14:45:22

我想您实际上想要已安排的项目,但在安排后未进行审核?

难道评论不应该与预定的项目相关联,而不是直接与项目相关联吗?现在,您必须比较日期,看看哪些评论出现在一个预定项目之后但在下一个项目之前。此外,如果某个项目被安排两次,且间隔时间很短,则您最终可能会得到属于第二次安排的两条评论。

通过此更改,您可以轻松挑选出未经审核的日程安排:

select i.id, i.name, s.execute_at
from items i
inner join scheduled_items s on s.item_id = i.id
left join reviewed_items r on r.scheduled_items_id = s.id
where r.id is null

至于您的问题:

我想将索引添加到
日期时间字段没有任何意义
因为基数或唯一性
那个字段非常高并且索引
不会提供任何(?)加速。是吗
正确吗?

不,那是不正确的。如果基数很高,索引可能会很有用。默认情况下,索引是为表的唯一 ID 创建的,当然它具有尽可能高的基数。

I suppose that you actually want the items that are scheduled, but not reviewed after that scheduling?

Shouldn't the reviews be connected to the scheduled items instead of difrectly to the items? Now you have to compare the dates to see which reviews comes after one scheduled item but before the next. Also, if an item is scheduled twice with a short time between, you may end up with both reviews belonging to the second scheduling.

With this change you could easily pick out the unreviewed schedulings:

select i.id, i.name, s.execute_at
from items i
inner join scheduled_items s on s.item_id = i.id
left join reviewed_items r on r.scheduled_items_id = s.id
where r.id is null

As to your question:

I suppose that adding index to the
datetime fields doesn't make any sense
because the cardinality or uniqueness
on that fields are very high and index
won't give any(?) speed-up. Is it
correct?

No, that is not correct. An index can be useful if the cardinality is high. An index is created by default for the unique id of a table, which of course has the highest cardinality possible.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文