空数据与虚拟数据的索引性能
我有一个包含 InTime 和 OutTime 列的表。
通常,当我将数据插入到该表中时,我将 InTime 设置为 DateTime,将 OutTime 设置为 null。当数据被删除时,会设置一个 OutTime 值。
当我获取特定时间的数据时,我使用以下内容:
where InTime < sometime and OutTime is > sometime or OutTime is null
我的问题是,为了获得更好的查询/索引性能,我是否应该在 OutTime 中放入一些值(例如最大日期时间)并使该字段不可为空?
然后我的查询变成
where InTime < sometime and OutTime is > sometime
I have a table with a InTime and an OutTime column.
Normally when I insert data into this table I set the InTime to a DateTime and the OutTime to null. When the data is removed a OutTime value is set.
When I’m getting data out for a particular time I use something like:
where InTime < sometime and OutTime is > sometime or OutTime is null
My question is, in terms of getting better query / index performance should I be putting some value into OutTime like the max datetime and make the field not nullable?
Then my query becomes
where InTime < sometime and OutTime is > sometime
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
将该字段保留为 NULL。不要使用 OR,使用 UNION ALL:
使用魔法值而不是 NULL 会导致灾难。至少,它使用更多的存储空间。更具体地说,它在执行数据库约束、计算聚合时以及在应用程序中打破了 NULL 的语义。
在查询中使用 OR 会带来性能问题。优化器可能会将任何索引范围搜索转变为扫描。使用 UNION 通常更好,因为优化器将创建两个计划,一个最适合 NULL,一个最适合非 NULL,然后将它们联合起来。
如果 Intime 和/或 OutTime 上没有任何索引,那么查询无论如何都将是一次扫描,并且 UNION 的性能将比 OR 差,但这不是一个值得讨论的场景。当然,问题是如何在正确设计的存储上优化查询。
Leave the field NULL. Don't use OR, use UNION ALL:
Using magic values instead of NULL is a recipe for disaster. At the least, it uses more storage. More specifically, it breaks the semantics of NULL when enforcing database constraints, when computing aggregates and in applications.
Using OR in queries is asking for performance trouble. The optmizer will likely turn any index range seeks into scans. Using UNION is usually better, as the optimizer will create two plans, one optimal for the NULLs one otpimal for the non-NULL, and union them.
If you do not have any index on Intime and/or OutTime then the query will be a scan anyway and the UNION will perform worse than an OR, but then that is not a scenario that is worth talking about. The question is, of course, how to optimize a query on properly designed storage.