【问题标题】:SQL: Optimize insensive SELECTs on DateTime fieldsSQL:优化 DateTime 字段上的不敏感 SELECT
【发布时间】:2010-04-24 08:53:14
【问题描述】:

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

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

  • 项目(ID、名称)
  • scheduled_items(id, item_id, execute_at - datetime) - item_id 列有一个索引选项。
  • reviewed_items(id, item_id, created_at - datetime) - item_id 列有一个索引选项。

所以应用程序的核心功能是“给我任何项目(尚未审查)的实际时刻”。

我怎样才能优化这个解决方案速度(因为它是非常核心的业务功能,而不是微优化)?

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

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

--

mysql -V
5.075

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

更新了。

【问题讨论】:

  • 您使用哪种缓存,memcached 还是反向代理?
  • 高基数意味着数据非常有选择性,索引肯定会有所帮助。它是不会使用的低基数列。

标签: sql mysql query-optimization nosql


【解决方案1】:

我想您确实想要已安排但在安排后未审核的项目?

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

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

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 创建索引,这当然具有最高的基数。

【讨论】:

  • 感谢 Göran 的有趣回答!
猜你喜欢
  • 1970-01-01
  • 2019-01-12
  • 1970-01-01
  • 2014-02-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-31
  • 2013-01-21
相关资源
最近更新 更多