何时尝试调整 SQL 或仅汇总表中的数据？答案

【问题标题】：When to try and tune the SQL or just summarize data in a table?何时尝试调整 SQL 或仅汇总表中的数据？
【发布时间】：2009-12-15 16:50:51
【问题描述】：

我在 SQL Server 2008 数据库中有一个 EMPLOYEE 表，该表每年都会多次存储员工 (~80,000+) 的信息。例如，不同年份的每个员工数据可能有 10 个不同的实例。

我正在通过网络应用报告这些数据，并且希望主要通过直接针对 EMPLOYEE 表的查询来报告，使用函数来获取需要计算或派生以用于报告目的的信息。

这些函数有时必须引用一个 EMPLOYEE_DETAIL 表，该表每年有 100,000 多行 - 所以现在我开始编写一些报告类型的查询，有些需要大约 5-10 秒才能运行，这有点太慢了。

我的问题是，在这种情况下，我是否应该尝试调整功能等等，所以我
始终可以直接查询数据以进行报告（实时），或者是通过过程或保存的查询在静态表中汇总我需要的数据的更好方法，并使用它任何报告？

我想报告需求的任何变化都可能反映在我使用的“总结机制”中......但我不知道该怎么做......

【问题讨论】：

感谢大家的回复。目前的缓慢似乎来自我拥有的一项功能，该功能总结了每位员工的价值。我将尝试在源表（我提到的 DETAIL）上为我在该函数中使用的列建立索引。

标签： sql sql-server

【解决方案1】：

在重构你的函数之前，我建议你看看你的索引。您会惊讶于构建良好的索引可以产生多大的差异。此外，索引维护可能比“汇总机制”需要更少的工作

【讨论】：

我在我的特定 sum 函数使用的所有列上添加了索引，但在查询中实时执行时仍然非常慢。我想我会在插入这个报告数据的时候使用函数，然后我至少可以保留我的标准函数，然后指向这个预先计算的值以避免任何性能问题。谢谢大家！

【解决方案2】：

就个人而言，我会使用以下方法：

如果可以调整函数，例如，通过添加特别适合查询需要的索引或在表上使用不同的聚集索引，然后调整它。如果您不必处理冗余，生活会轻松得多。
如果您觉得您已经到了无法再优化的地步（无论您做什么，从磁盘中获取几千个碎片页面将花费一些时间），那可能会更好冗余地存储一些数据，而不是完全重构存储数据的方式。如果您选择这条路线，请非常小心，以免出现不一致。

例如，SQL Server 允许您使用indexed views，它冗余地存储摘要数据（即某些视图的结果）以便快速访问，但也会自动更新该数据。当然，修改基础表时会降低性能，因此您必须检查这是否符合您的需求。

否则，如果数据不必是最新的，则定期重新计算摘要（在晚上，无人工作时）可能是可行的方法。

【讨论】：

【解决方案3】：

我是否应该尝试调整功能和这样我就可以随时查询数据直接用于报告（实时），或是一个更好的方法来总结我需要通过一个静态表中的数据过程或保存的查询，并使用它任何报告？

根据您的数据和查询（长达 10 年的历史数据，计算值的聚合查询）的描述，这看起来像一个 OLAP 业务智能类型的数据存储，其中查看历史趋势和旧读更重要- 仅数据，而不是查看当前的流失并持续到发生的第二次更新。因此，最好的解决方案是设置 SQL Analysis Services 服务器并查询它而不是关系数据库。

这是一个笼统的回应，不知道您的具体细节。您的数据大小（约 80k-800k 员工记录，约 100k -1 百万详细记录）完全在 SQL Server 关系引擎的能力范围内，可以对聚合和业务智能类型查询提供亚秒级响应，特别是如果您添加类似索引的内容一些问题聚合的视图。但是与分析引擎（SQL Server Analysis Services）相比，关系引擎（SQL Server）能做的就相形见绌了。

【讨论】：

我完全同意这一点，并且我的组织中有 OLAP (Cognos 7)...但该版本中没有 API，因此我无法查询这些多维数据集或数据。只是想为网络实现一个简单的“reporting-lite”。
您提出的问题可以改写为“我应该使用现成的 OLAP 引擎还是应该使用自己的引擎？”。你知道，从长远来看，答案永远是“使用现成的”。我知道在大型组织中总是有更多的风险（哦，政治......）。如果您的报告精简版成功，它会触发更多报告吗？该解决方案会在两年后成为成功的焦点吗？也许充分利用 SQL Server 许可证并安装 SSAS 是有意义的。我说请求宽恕比请求许可更好......
设置 OLAP 系统是一项艰巨的任务，所涉及的内容远远超过向网站添加几份报告。在这种情况下推荐“只安装 SSAS”有点像向询问如何创建简单 Web 服务的人推荐安装和学习 BizTalk 和 MSMQ。让我们不要在这里操之过急。
+1。这也将是我的答案。使用 Analysis Services 构建用于报告的多维数据集首先需要一些工作，但从长远来看，它也将为更丰富的报告和更轻松的查询打开大门。它还具有卸载关系系统的潜力。
谢天谢地，报告非常基础，用于公共消费，而更多“高级”的东西在 Cognos 中完成。因此，我认为我将让这个“精简报告”继续下去，也许当我们听到一些现代 Cognos 谈论使用 Web 服务或其他东西将这些数据公之于众时......

【解决方案4】：

我的问题是，在这种情况下，我是否应该尝试调整功能等等，所以我总是可以直接查询数据以进行报告（实时），还是一种更好的方法来通过过程或保存的查询在静态表中汇总我需要的数据，并将其用于任何报告？

您可以按天、月等数据块汇总数据，在报告中汇总这些数据块，如果过去的某些数据发生变化（以纠正错误等），则使它们无效

【讨论】：

【解决方案5】：

就实时报告和绩效而言，您的客户对哪些方面感到满意？

话虽如此，调整查询/索引可能是值得的。
如果您无法通过修改索引来提高性能，我会感到惊讶。

【讨论】：

【解决方案6】：

在尝试静态表路由之前检查索引、返工功能、购买更多硬件、做任何事情。

【讨论】：

【解决方案7】：

每年 100,000 行（大概总共大约 100 万行）不算什么。如果这些查询需要 5-10 秒才能运行，那么要么是您的查询有问题，要么是您的索引有问题（或两者都有）。我会把钱花在你的性能问题上，因为这是一次或多次表扫描或索引扫描的结果。

当您开始接近十亿行标记时，您通常需要开始非规范化，并且仅在您无法更积极地索引的繁重事务环境中。

当然，总是有例外，但是当您使用数据库时，最好先进行重大优化，然后再开始使用分区和触发器等使架构和架构复杂化。

【讨论】：