糟糕的内部数据库 - 更换它或使用硬件？

我将不同意这里的每个人。夹点一些硬件。它便宜、快速、简单，可以为您争取实施适当的 CRM 解决方案所需的时间。我之所以提倡让几乎每个人都厌恶的东西，不仅是这个董事会，还有 stackoverflow，是因为我一直是项目经理/经理，并且在“业务”方面已经有一段时间了（业务由于我对这个词的仇恨而被引用）。根据您对软件的描述，重建其他软件需要将近一年的时间。仅仅发现/记录业务规则/怪癖，可能需要 2 个月。它的开发成本也将令人难以置信。特别是与欺骗服务器的成本相比。

出于这个原因，我实际上正要为一家公司托管一组网络应用程序。内部 IT 部门不会将其转移到更好的硬件上，因为他们想在新平台上重新开发它们。该成本大约是将其转移到新硬件所需成本的三倍。更不用说公司一年内可能不会续约。

您可能也不需要这样做。我的建议是简单地向表中添加一些索引/键。

具有数万行且没有主键或索引的表，在多表连接中也大量使用

在花费大量金钱或时间之前，请花几个小时将索引（或主键，如果可以的话）添加到参与这些连接的任何表中……尤其是对于 where 子句中使用的列。您可以在短短几个小时内轻松将性能提高 10 倍。

缺少磁盘 I/O 意味着查询大部分来自 RAM。如果您“突然”让您的热表不再适合 RAM 并且服务器开始处理磁盘，那么您可能会遇到麻烦。如今，2GB 或 RAM 并不是很多，但在 SQL2000 时代，它已经相当可观了。我猜测应用程序通常操作的数据量小于您拥有的 RAM。您可能想查看数据文件中“已用”空间的数量。这将使您了解数据库在最坏情况下可能消耗多少 RAM。SQL Server 不会将不需要的数据保存在 RAM 中，但很难知道使用了哪些表以及何时使用。

超线程并不总是对 SQL Server 有帮助。关闭它可能会获得更好的性能。很难测试，因为关闭和打开它需要重新启动，这在生产服务器上是一个很大的麻烦。

“每分钟数十万个查询”转化为每秒数千个查询。这听起来很忙，但大部分流量可能只是 Access 的游标提取。Access 在有效地从 SQL 检索结果集方面尤其糟糕。通过关闭 SQL Server 并行化设置，您可以获得更好的性能。

您还想寻找阻塞。在阻塞问题上投入硬件并不总能产生所希望的显着改进。如果没有太多的阻塞并且通过 RAM 而不是磁盘来满足查询，那么您基本上依赖于处理器的咕噜声，以及它们通过内存通道提取数据的能力。在这种情况下，更快的硬件应该会提供很好的改进。如果你很着急（解决这个问题）并且增长缓慢，那可能就足够了。

作为一种解决方案，添加硬件不会像数据库改进那样扩展。如果您的增长激增，您可能会发现您的新硬件正在苦苦挣扎。另一个想法是成功的应用程序会吸引用户。如果应用程序变得更具响应性，用户可能更有可能在其上运行更多报告等，而不是在等待报告完成时需要去喝咖啡。

如果数据库模式真的很糟糕，您可能只需查看表上的索引就可以获得一些性能优势。专注于您知道经常被查询的表。您可以使用 Profiler 观察针对服务器运行的查询，只需告诉它查找读取大量数据（如 100,000 页）的查询，然后处理读取不多的查询。你提到有些表没有键。数据中是否有自然键，而不是由约束或唯一索引强制执行？

这些表是否有聚集索引？缺乏聚集索引会导致各种次要影响。

是否有很多包含很多列的非聚集索引？这通常是尝试构建许多覆盖索引，而不是实施更有效的索引策略。如果这样做有意义并且支持非聚集索引和聚集索引，SQL Server 可以在查询期间有效地动态构建覆盖索引。

最后，值得一问：是否正在对表进行维护（重新索引和/或更新统计信息）？

这是一个商业问题，而不是技术问题。

作为企业主： 系统对企业的战略意义如何？战略性越低，我就越不关心和修复它以及花费的任何钱，都是我可以在其他地方用来发展我的业务的钱。

电脑专家吓到我，因为他们都挤在一个大房间里，为设计争论不休，花了我一大笔钱。让系统继续运行！这是否意味着性能调整（无需重新架构）或投入更多硬件，如果它停止工作，这只是一个优先事项。

作为一名 IT 顾问： 您的系统是遗留系统并且具有隐藏的运营成本。我们可以设计一个适合您的系统，该系统将扩展并为未来的增长和战略优势提供平台。在这里签名，你所有的梦想都会成真。

作为一名 IT 员工： 我可以成为这里的超级英雄，通过优化这件事来避免迫在眉睫的灾难，从而拯救公司！我的经理会用礼物和表扬我，因为我已经为公司节省了数千美元。

嗯……这是不久前的事了，但我想我会在这里记录结果。

最后，我一行一行地通过VBA来处理另一个问题。就在那时，我意识到某些获取行集的调用阻塞了 20-30 多秒。

当我深入研究它们时，我发现行集是基于 MS Access 查询的。

那是从另一个 Access 查询中选择数据。

那是从另一个 Access 查询中选择数据。

所有这些看起来像是使用查询设计器一起拖放的。

我浏览了前六名的用户痛点，发现它们都和这个完全一样。

所以我完全删除了链式查询堆栈，并用一个可以用 T-SQL 编写并直接在服务器上执行的单个传递查询替换它们中的每一个。

在任何情况下，改进都是绝对巨大的，没有失败，任何人都不再需要等待查询。

然后我离开了公司。不知道它是否还在那里……但我不会想念它。

我说两者都做。

现在你说的 CPU 是 40% 左右？您的用户抱怨（很多）了吗？如果没有，你还有喘息的空间。更多的内存可能只够做一段时间。

关于未来的问题，您有内部软件开发人员吗？如果答案是否定的，那么甚至不要尝试重做。你最终会回到现在的位置。

假设您有内部开发人员，您的内部开发人员是否有能力正确完成项目？我说的是完全、正确（相对）的时间表，基本上就像是客户的项目一样。如果没有，那就不要打扰，否则它最终会回到你现在的位置。

除非公司意识到他们也是自己的客户，并且需要为内部项目提供相同的资源，否则您最终将完全处于现在的位置。去过那里，完成了，得到了一整柜的T恤。

因此，如果您不能正确地做到这一点，那么您有两个选择是开箱即用的交钥匙，您的员工会讨厌它，因为他们现在必须适应您购买的系统的模具。或者它将是可定制的，您仍然需要花费 PROJECT 时间来定制它。

或者重构你所拥有的。请记住，当新功能出现时，人们会期望所有相同的完整功能，这就是为什么您必须以任何其他方式一次完成所有事情的原因。如果你重新考虑它，你就有机会弄清楚它是如何工作的，然后你将它计划成许多小的子项目而不是临时更改。

在没有看到系统的情况下，我可能会在后端尽可能多地进行规范化，将尽可能多的 SQL 移动到存储过程中。然后用 C# Forms 或 webapp 构建一个新的前端。如果你能把你的业务逻辑和 SQL 从前端弄出来，以后再做会更容易。通过保留您对小型项目所做的事情，如果它随时被推到一边或停止，您将取得将被使用的进展。

这里已经有一些很好的回复 - 但我是否可以指出（假设有内部开发人员）相对少量的工作会产生很大的影响 - 添加主键（您甚至不必将所有查询更改为使用它们），为您确实使用的字段添加索引，并稍微调整您的查询，您会看到绝对巨大的增长。现在为自己购买一些 RAM，以购买修复它所需的时间和空间，然后开始工作。

在“修复它或抛弃它”的主题上，如果系统的功能基本上适合您并做您需要的，请不要重写轮子。如果你的用户因为它不符合你的需求而不得不做体操来使用它，那么付出努力是没有意义的。

技术答案：

您有许多建议，说明应该彻底审查主键和索引。Access 还非常喜欢在每个表上使用 SQL Server TimeStamp 又名 RowVersion 列，因为这减少了 Access 在更新记录时确定记录是否已更改所花费的大量时间。

商家回复：

新的 CRM 解决方案在培训人员方面需要做大量工作，而且您永远不会得到一个完全适合您的业务需求的系统。

我会找到一个对 SQL Server 也非常了解的优秀 Access 人员，让他们花 3 或 6 个月的时间来规范化表并解决用户痛点。确保该人作为您的用户在 saem 楼层工作，尽管在安静的空间中，并且可以访问。虽然不太方便。开发人员不喜欢中断。小号

我发布了一个单独的答案，而不是仅仅附加到代顿的答案，因为发布答案的前几个人没有考虑到成本：再培训用户的成本和更改业务程序以适应的成本一个新的软件程序。否则，他说的。

公司开发自己的软件的主要原因之一是他们的业务程序与市场上的产品不匹配。这很好——公司的个人业务程序是公司带来的价值的重要组成部分，也是公司相对于其他市场的竞争优势。用通用软件替换软件需要您重新培训员工并牺牲竞争优势，或者您必须定制解决方案以匹配您的业务流程。两者都昂贵且耗时。作为一名商业顾问和系统管理员，我已经看到这些成本自己杀死了小公司。

从您的陈述来看，您似乎受处理器/软件限制。我会做两件事——添加索引（在限制范围内），尤其是对当前不使用它们的列。而且我会选择最快的处理器集，因为如果您没有那么多驱动器读取（除了在峰值时），它看起来就是您要绑定的地方。

（另外，我会尽可能地升级服务器版本——当你把它安装到位时，Access 2000 和 SQL Server 2000 将有 10 年的历史。这在计算机时代已经过时了！）

这需要彻底重构（re-architecture）。从头开始重建系统。从长远来看，这将为您节省很多（维护的间接费用）。与此同时，把硬件夹在上面。我认为这个问题更像是一个“商业案例”，而不是技术调查。从技术上讲，答案是彻底的“加大力度”。商业明智，建立一个新的系统！