2

一段时间以来，我一直在努力解决这个问题，并决定我应该寻求帮助。我有一个表格，其中包含温度/湿度图表记录器数据（目前超过 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 秒，这仅仅是因为它的大小。如果人们有一些帮助，我可以使用一些认真的帮助。先感谢您！

-- 编辑于 2012 年 8 月 13 日 @ 1050 小时 --

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

临时步骤：

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

-- 编辑于 2012 年 8 月 13 日 @ 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

执行代码时会出现问题，查询需要很长时间 - 它在完成之前遇到超时。仍然希望有一个“灵丹妙药”来解决这个问题......

-- 编辑于 2012 年 8 月 20 日 @ 1241 小时 --

我发现的唯一“准”解决方案是重复运行失败的查询（有点像启动泵），这样当我的程序再次调用查询时 - 它有相对的机会在 ODBC 之前实际完成SQL Server 驱动程序超时。基本上，一个肮脏肮脏的黑客 - 但我没有更好的来解决这个问题。

  1. 我试过创建一个视图，它可以在服务器端工作——但不会加快速度。
  2. 正在聚合的正确字段已正确编入索引，因此我无法在此处进行任何更改。
  3. 我只是从数据库中提取对用户立即有用的信息——这里没有“SELECT * madness”。

我认为，正式地，我没有东西可以尝试——除了将原始计算能力投入到问题上，这不是目前的解决方案，因为该项目还没有上线，而且我没有预算来采购更好的硬件。我会将其发布为“答案”并将其保留到 9 月 3 日 - 如果我没有更好的答案，我将接受我自己的答案并接受失败。

4

1 回答 1

0

当我不得不对同一个表中的多个字段运行最小/最大函数时，我经常发现在主/外部查询的 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 中的同一查询窗口中并运行估计的执行计划，您应该能够比较它们并查看哪一个效果更好。

于 2013-12-31T02:35:54.723 回答