如何提高SQL Server中日期时间过滤的性能?

我有一个按datetime列过滤的问题。

我试过这两种方法:

datefield < '2013-03-15 17:17:55.179'
datefield < CAST('2013-03-15 17:17:55.179' AS datetime)

我有一个大型数据库,拥有超过3000万个主要对象。

所以我需要提高我的datetime过滤的性能。 我正在阅读有关UNIX时间戳(将所有datetime时间转换为UNIX时间戳,然后按此UNIX域进行筛选)。

我认为这比按datetime时间过滤更好。 但如果有人知道其他方式,我将不胜感激。

我的查询是:

SELECT TOP (100)  ev.Title as Event_name, po.Name as POI_name, 
po.Address, po.City, po.Region, po.Country, po.Latitude, po.Longitude, ev.Start_time, 
(Select ID_Category FROM SubCategory s where ev.ID_SubCategory = s.ID_SubCategory) as ID_Category, 
ev.ID_SubCategory, ev.ID_Event, ev.ID_Channel, IDChanelEvent, 
ev.FavoriteCount, po.gmtOffset, v.IsFavorite, v1.IsFavorite  
FROM Events ev 
JOIN POI po ON ev.ID_POI = po.ID_POI 
JOIN (SELECT et.id_event as joinIdEv FROM EventTagLink et, tags t 
 WHERE t.id_tag = et.id_tag 
 AND ( t.Title = N'music' ) 
 ) as joinEvents 
 ON joinEvents.joinIdEv = ev.ID_Event 
LEFT JOIN Viewed v ON v.ID_Event = ev.ID_Event AND v.ID_User = 1 AND v.IsFavorite = 1 LEFT join Viewed v1 ON v1.ID_Event = ev.ID_Event AND v1.ID_User = 1 AND v1.IsFavorite = 0
WHERE 
--ev.GmtStop_time > '2013-03-15 14:17:55.188' AND 
po.Latitude > 41.31423 AND po.Latitude < 61.60511 
AND  po.Longitude > -6.676602 AND po.Longitude < 17.04498  
AND ev.ID_SubCategory in (3, 12, 21, 4, 30, 13, 22, 6, 14, 40, 23, 7, 32, 15, 41, 8, 50, 33, 16, 42, 25, 9, 34, 17, 35, 18, 44, 27, 36, 19, 45, 28, 37, 46, 29, 38, 47, 39, 48, 49, 10, 1, 11, 2, 20) 
--AND ev.GmtStart_time< '2013-03-15 17:17:55.179'
AND v1.IsFavorite is null

过滤我评论的时间。

如果我关闭这些过滤器,请求持续时间是几秒钟。 如果我打开它们,则请求持续时间超过25秒。

  • 带过滤日期时间的执行计划
  • 没有日期时间过滤器的执行计划
  • 所以有很多关于执行计划,索引等的讨论。 但是UNIX时间戳呢 ,这是我把问题放在那里的主要原因。 它会提高datetime过滤的性能吗?

    提前致谢。


    只是一个建议,当涉及到在msql datetime索引是索引足迹影响搜索时间(是的,这似乎很明显......但请阅读前面)。

    在日期时间索引时,对此的重要性例如说'2015-06-05 22:47:20.102'索引必须考虑日期时间内的每个地方。 这在空间和体积上变得非常大。 我利用的一个成功方法是创建一个新的日期时间列,并通过将时间四舍五入到小时,然后在此新列上构建索引来填充数据。 示例'2015-06-05 22:47:20.102'转换为'2015-06-05 22:00:00.000'。 通过采用这种方法,我们只保留详细数据,并且可以通过搜索这个新列来显示或使用它,这使得我们返回的结果返回速度大约为10倍(至少)。 这是因为索引不必考虑分钟,秒和毫秒字段。


    您需要首先查看您的执行计划,以查看SQL Server正在执行的操作。 更可能的是,你只需要添加一个索引。 像这样的小转换几乎不会成为您查询速度慢的原因。 索引是修复查询的第一站。

    您不需要将其作为聚集索引。 使它成为聚集索引意味着你不需要查询,但只有100行,查找速度非常快。 我会把datetime和子类别按顺序放到一个非聚集索引中。

    如果你正在订购,你还应该确保它在索引中。 由于每个表只使用一个索引是有意义的,因此您需要确保所有相关列都按照正确的顺序位于同一索引中。

    但首先,得到您的实际执行计划!


    为了更好的性能,我建议你创建新的索引:

    CREATE INDEX x1 ON LiveCity.dbo.Tags(Title) INCLUDE(ID_Tag)
    CREATE INDEX x2 ON LiveCity.dbo.Tags(ID_Event, GmtStart_time, GmtStop_time) 
      INCLUDE(
              FavoriteCount, 
              ID_Channel, 
              ID_POI, 
              ID_SubCategory, 
              IDChanelEvent, 
              Start_time, 
              Title
              )
    CREATE INDEX x ON LiveCity.dbo.POI(ID_POI, Latitude, Longitude) 
      INCLUDE(
              Address, 
              City, 
              Country, 
              gmtOffset, 
              Name, 
              Region
              )
    

    这将帮助您避免RID查找操作并提高查询的整体性能。

    链接地址: http://www.djcxy.com/p/94401.html

    上一篇: How to improve performance for datetime filtering in SQL Server?

    下一篇: SQL Server 2008 and milliseconds