查询在datetime字段上以INNER JOIN挂起

时间:2009-01-27 14:15:57

标签: sql-server ms-access

我们在加入SQL Server 2005和MS Access 2003中的表时遇到了一个奇怪的问题。

服务器上有一个大表,Access中有一个相当小的表。这些表通过3个字段连接起来,其中一个是日期时间字段(包含一天;想法是从大服务器表中获取其他数据(每日)以将数据添加到本地表)。

直到周末,每天都很好。从昨天开始,我们在Access中遇到了奇怪的非超时问题。非超时意味着查询将以相当高的网络传输永久运行,但不会发生超时。 Access甚至不显示进度条。服务器跟踪告诉我们在SQL服务器上反复执行相同的查询而没有错误但也没有结果。我们已经把它缩小到看似正在使用大表访问服务器表的问题以及包含日期的JOIN或WHERE,但我们实际上无法缩小范围。我们已经重建了索引,目前正在恢复备份数据,但也许这里有人可以尝试我们的任何指示。

谢谢,迈克。

6 个答案:

答案 0 :(得分:1)

感谢您的快速回答!

实际查询真的很大;你会对它不满意:)

然而,我们已将其缩小为简单:

SELECT * FROM server_table INNER JOIN access_table ON server_table.date = local_table.date;

如果server_table是一个大表(很难说,我们已经有150万行;有10行左右的测试表已经工作),local_table是一个包含日期的单个单元格的表。这永远运行。这不仅是缓慢的,它似乎什么也没做 - 似乎 - 导致网络流量而且没有时间(这是我发现的那么奇怪;通常你会超时,但这只是继续运行)。

我们刚刚找到知识库文章828169;似乎是我们的问题,我们会调查一下。谢谢你的帮助!

答案 1 :(得分:1)

如果你在Access中加入一个本地表到SQL Server中的链接表,并且根据连接到链接数据的特定限制,查询并不是真的很简单,那么Access很可能会从SQL Server中拉出整个表并针对整个集合在本地执行连接。这是一个众所周知的问题。

这不能直接解决您提出的问题,但是您将所有数据放在一个地方(SQL Server)有多远?恕我直言,只要你在每个系统中都有一些数据,你就会发现同样类型的性能问题困扰着你。

如果它全部在SQL Server中,则传递查询将优化并使用可用索引等

答案 2 :(得分:0)

请发布执行此操作的查询,因为您拥有索引并不意味着它们将被使用。如果您的WHEREJOIN子句不可搜索,则不会使用该索引

以此为例

WHERE CONVERT(varchar(49),Column,113) =  CONVERT(varchar(49),OtherColumn,113)

不会使用索引

或者

WHERE YEAR(Column) = 2008

运算符左侧的函数(意思是列本身)将使优化器执行索引扫描而不是搜索,因为它不知道该函数的结果

  

我们已经重建了索引,目前正在恢复备份数据,但也许有人在这里有任何我们可以尝试的事情。

访问可以杀死许多好东西....你有没有看过阻塞

运行

exec sp_who2

查看BlkBy列,看看谁阻止了什么

答案 3 :(得分:0)

使用DATEDIFF函数比较两个日期,如下所示:

如果日期基于datepart参数相同,则DATEDIFF返回0,在本例中为d

WHERE DATEDIFF(d,Column,OtherColumn) = 0

DATEDIFF针对日期进行了优化。如果其中一个日期为NULL,则比较等于(=)符号两侧的CONVERT函数的结果可能会导致表扫描。

希望这有帮助,

比尔

答案 4 :(得分:0)

尝试其他语法?就像是:     
SELECT * FROM BigServerTable b WHERE b.DateFld in (SELECT DISTINCT s.DateFld FROM SmallLocalTable s)

你的问题描述中的奇怪之处在于“直到周末这种情况每天都很好” 这意味着问题确实存在于其他地方 您是否尝试创建新的空白Access数据库并从旧数据库导入所有内容? 或者只是刷新所有链接?

答案 5 :(得分:-1)

只是一个想法,但在SQL Server中,您可以附加Access数据库并在那里使用表。然后,您可以在服务器上创建一个视图,以在SQL Server中进行全部连接。知识库文章中提出的解决方案对我来说似乎有问题,因为它是一个kludge(如果LIKE工作,那么=也应该)。

如果我的建议有效,我会说它在可维护性方面是一个更强大的解决方案。