Access 2007中的查询性能 - 在SQL Server Express后端上绘图

时间:2012-08-07 23:00:16

标签: sql-server ms-access

我现在一直在讨论这个问题,并决定我应该寻求帮助。我有一个表格,其中包含温度/湿度图表记录器数据(目前超过775,000条记录),我正试图对其进行统计查询。问题是这通常需要两分钟,有时根本不会回来 - 导致我强行关闭程序(Control-Alt-Delete)。起初,我没有那么多的问题 - 只是在我达到神奇的500k记录标记之后,我开始出现严重的减速,随着更多数据被编译并导入到表中而逐渐变得更糟。

这是查询(传递):

SELECT dbo.tblRecorderLogs.strAreaAssigned, Min(dbo.tblRecorderLogs.datDateRecorded) AS FirstRecorderDate, Max(dbo.tblRecorderLogs.datDateRecorded) AS LastRecordedDate,
Round(Avg(dbo.tblRecorderLogs.intTempCelsius),2) AS AverageTempC,
Round(Avg(dbo.tblRecorderLogs.intRHRecorded),2) AS AverageRH,
Count(dbo.tblRecorderLogs.strAreaAssigned) AS Records
FROM dbo.tblRecorderLogs
GROUP BY dbo.tblRecorderLogs.strAreaAssigned
ORDER BY dbo.tblRecorderLogs.strAreaAssigned;

以下是存储图表数据的表格结构:

idRecorderDataID     Number     Primary Key
datDateEntered       Date/Time  (indexed, duplicates OK)
datTimeEntered       Date/Time
intTempCelcius       Number
intDewPointCelcius   Number
intWetBulbCelcius    Number
intMixingGPP         Number
intRHRecorded        Number
strAssetRecorder     Text       (indexed, duplicates OK)
strAreaAssigned      Text       (indexed, duplicates OK)

我正在尝试编写一个程序,允许人们根据区域分配以及开始和结束日期从此表中提取数据。根据我目前拥有的数据集大小,这种类型的报告对于它来说太过分了(似乎)并且机器不会返回答案。在处理此表的任何查询中,我必须将ODBC超时扩展到差不多180秒,这仅仅是因为它的大小。如果人们有一些帮助,我可以使用一些严肃的帮助。提前谢谢!

- 编辑08/13/2012 @ 1050小时 -

我无法在SQL Server上测试查询,因为IT部门已经控制了相关机器,并且有人使用远程管理控制台全职登录。我已尝试过一个临时步骤来减轻性能问题的影响,但我仍然在寻找这个问题的永久解决方案。

临时步骤:

我创建了一个镜像dbo.tblRecorderLogs SQL Server表结构的本地表,我使用前一个SELECT语句作为子查询来执行INSERT INTO。然后从这个“临时”本地表中抽取任何后续的统计分析。该过程完成后,本地表将被截断。

- 编辑08/13/2012 @ 1217小时 -

在SQL Server管理控制台上显示所显示的查询,根据控制台提供的查询计时器,需要1分38秒才能完成。

- 编辑08/15/2012 @ 1531小时 -

尝试使用以下代码将查询作为VBA DoCmd.RunSQL语句运行以填充临时表:

INSERT INTO tblTempRecorderDataStatsByArea ( strAreaAssigned, datFirstRecord, 
datLastRecord, intAveTempC, intAveRH, intRecordCount )
SELECT dbo_tblRecorderLogs.strAreaAssigned, Min(dbo_tblRecorderLogs.datDateRecorded) 
AS MinOfdatDateRecorded, Max(dbo_tblRecorderLogs.datDateRecorded) AS MaxOfdatDateRecorded, 
Round(Avg(dbo_tblRecorderLogs.intTempCelsius),2) AS AveTempC, 
Round(Avg(dbo_tblRecorderLogs.intRHRecorded),2) AS AveRHRecorded, 
Count(dbo_tblRecorderLogs.strAreaAssigned) AS CountOfstrAreaAssigned FROM 
dbo_tblRecorderLogs GROUP BY dbo_tblRecorderLogs.strAreaAssigned ORDER BY 
dbo_tblRecorderLogs.strAreaAssigned

当代码执行时出现问题,查询需要很长时间 - 它在完成之前遇到Timeout。仍然希望有一个“神奇的子弹”来解决这个问题......

- 编辑08/20/2012 @ 1241小时 -

我发现唯一的'准'解决方案是反复运行失败的查询(就像启动泵一样),这样当我的程序再次调用查询时 - 它有相对的机会实际完成ODBC SQL Server驱动程序超时之前。基本上,一个肮脏的污秽黑客 - 但我没有一个更好的人来解决这个问题。

  1. 我尝试创建一个在服务器端工作的视图 - 但不会加快速度。
  2. 正在聚合的正确字段已正确编入索引,因此我无法对其进行任何更改。
  3. 我只是从数据库中提取对用户有用的信息 - 这里没有'SELECT * madness'。
  4. 我认为我正式出于尝试的目的 - 除了在问题上投入原始计算能力之外,现在这不是一个解决方案因为项目不活,我没有预算可以更好地采购硬件。我会将此作为“回答”发布,并将其保留到9月3日 - 如果我没有更好的答案,我将接受自己的答案并接受失败。

1 个答案:

答案 0 :(得分:0)

当我不得不在同一个表中的几个字段上运行min / max函数时,我经常发现在主/外查询的from行中将每个列分别作为子查询单独执行。

所以你的查询会是这样的:

SELECT rLogs1.strAreaAssigned, rLogs1.FirstRecorderDate, rLogs2.LastRecorderDate, rLog3.AverageTempC, rLogs4.AverageRH, rLogs5.Records
FROM (((
    (SELECT strAreaAssigned, min(datDateRecorded) as FirstRecorderDate FROM dbo.tblRecorderLogs GROUP BY strAreaAssigned) rLogs1
    inner join
    (SELECT strAreaAssigned, Max(datDateRecorded) as LastRecordedDate, FROM dbo.tblRecorderLogs GROUP BY strAreaAssigned) rLogs2
    on rLogs1.strAreaAssigned = rLogs2.strAreaAssigned)
    inner join
    (SELECT strAreaAssigned, Round(Avg(intTempCelsius),2) AS AverageTempC, FROM dbo.tblRecorderLogs GROUP BY strAreaAssigned) rLogs3
    on rLogs1.strAreaAssigned = rLogs3.strAreaAssigned)
    inner join
    (SELECT strAreaAssigned, Round(Avg(intRHRecorded),2) AS AverageRH, FROM dbo.tblRecorderLogs GROUP BY strAreaAssigned) rLogs4
    on rLogs1.strAreaAssigned = rLogs4.strAreaAssigned)
    inner join
    (SELECT strAreaAssigned, Count(strAreaAssigned) AS Records, FROM dbo.tblRecorderLogs GROUP BY strAreaAssigned) rLogs5
    on rLogs1.strAreaAssigned = rLogs5.strAreaAssigned
ORDER BY rLogs1.strAreaAssigned;

如果你接受上面的查询,将它们复制到SQL Server的同一个查询窗口中,运行估计的执行计划,你应该能够比较它们,看看哪个更好。