所以 - 我们有一个内部公司数据库，其中包含常见的内容：管理客户、电话、销售交易和客户协议/计划。
前端是 Access 2000，后端是 SQL Server 2000 Standard。单台服务器，双 Xeon 3.2GHz，2GB RAM，Windows Server 2003，全天 CPU 负载约为 40%，分布在操作系统 (HT) 可见的 4 个核心上。
后端数据库设计不佳，并且由缺乏技能的人员在 10 多年的时间里自然增长。它规范化得很糟糕，一些明显的问题包括包含数万行且没有主键或索引的表，这些表在系统中一些使用最频繁的部分（例如，一个呼叫管理器应用程序每天 8 小时都放在每个人的第二台显示器上，每隔几秒钟运行一次低效的大型查询）的多表连接中也大量使用。
前端也好不到哪里去，它就是典型的混乱局面，包含数百个表单、嵌套的已保存查询、VBA 代码中编写不当的嵌入式 SQL、数十个“怪癖”等等，而且每当做出更改时，似乎就会出现一些不相关的问题。我们已经确定了一个运行“足够好”的 MDB，现在对此采取了不更改政策，因为我们内部没有 Access 重量级人物（也不打算聘请一个）。
该公司现在正在缓慢发展，客户数量、电话数量等都在增加，同时并发用户数量也在适度增加，但最近性能明显变差（等待在表单之间移动、等待列表填充等）
Perfmon 说：
- 每秒磁盘传输次数：0 到 30 之间，平均 4。
- 当前磁盘队列长度：徘徊在 1 左右
SQL Server 的分析器每分钟都会看到数十万个查询。客户端的 CPU 使用率几乎为零，表明它正在等待服务器端查询执行。我已将此工作负载放入 DB Engine Tuning Advisor 中，并将其建议应用于测试备份，但这并没有带来太大的变化。
顺便说一下，我们混合使用了 100MB 和千兆以太网，全部位于一个子网上，两层楼共有 40 个用户。
对于这个问题。
我认为我们有两种选择来解决/改善这种情况。
- 我们可以将其废弃，并用全新的 CRM 系统（定制或部分定制）取而代之
- 我们可以通过向该系统添加硬件来延长其寿命。
我们可以构建一个性能出色的 Intel i7 系统，而且成本比更换软件要低一个数量级。
当最终开发出新系统时，它可以托管在这个盒子上，因此不会浪费硬件。新的 CRM 系统不断被推迟、搁置、搁置——我认为至少一年内不会发生这种情况。
如果您对这种情况有任何想法，尤其是如果您亲自经历过这种情况，我们将非常感激。
谢谢
答案1
我要与这里的所有人意见相左。用一些硬件来做这件事。它便宜、快速、简单，而且会为你赢得实施适当 CRM 解决方案所需的时间。我之所以提倡一些不仅对这个论坛上几乎所有人而言都是令人厌恶的东西，而且对 stackoverflow 也是如此，是因为我曾经是一名项目经理/经理，并且已经从事“业务”工作一段时间了（业务这个词之所以用引号引起来，是因为我讨厌这个词）。根据你对软件的描述，重建其他东西需要将近一年的时间。仅仅发现/记录业务规则/怪癖，可能就需要 2 个月的时间。开发它的成本也高得令人难以置信。尤其是与一台经过改装的服务器的成本相比。
事实上，我正准备为一家公司托管一组 Web 应用程序，原因就在于此。内部 IT 部门不会将其迁移到更好的硬件上，因为他们想在新平台上重新开发它们。这笔费用大约是将其迁移到新硬件所需费用的三倍。更不用说该公司可能在一年内无法续签合同。
答案2
您可能不需要执行任何操作。我的建议是简单地向表中添加一些索引/键。
具有数万行且没有主键或索引的表，这些表在多表连接中也大量使用
在花费大量金钱或时间之前，请花几个小时为这些连接中涉及的任何表添加索引（或主键，如果可以的话）……特别是对于 where 子句中使用的列。您只需几个小时即可轻松将性能提高 10 倍。
答案3
缺少磁盘 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 可以在查询期间有效地动态构建覆盖索引。
最后，值得问的是：是否对表进行了维护（重新索引和/或更新统计信息）？
答案4
我说两样都做。
你说现在你的 CPU 使用率在 40% 左右？你的用户抱怨了吗（很多）？如果没有，你还有喘息的空间。增加内存可能足以维持一段时间。
问题是，您有内部软件开发人员吗？如果答案是否定的，那么就不要尝试重做。您最终会回到现在的处境。
假设您有内部开发人员，您的内部开发人员是否有能力正确完成项目？我说的是完全、正确（现实）的时间表，基本上与客户的项目相同。如果没有，那就不要费心了，否则最终会回到现在的境地。
除非公司意识到他们也是自己的客户，并且需要将同样的资源提供给内部项目，否则你最终会陷入现在的境地。经历过那种情况，做过那种事，得到一整柜的 T 恤。
因此，如果您不能正确完成这项工作，您有两个选择：一是开箱即用，您的员工会讨厌这种方式，因为他们现在必须按照您购买的系统进行调整。或者，它是可定制的，您仍然需要花费项目时间来定制它。
或者重构您已有的。请记住，当新项目推出时，人们会期望所有功能都一样完整，所以这就是为什么您必须一次性完成所有事情的原因。如果您重构它，您就有机会弄清楚它是如何工作的，然后将其规划成许多小的子项目，而不是临时更改。
在没有看到系统的情况下，我可能会考虑在后端尽可能地规范化，将尽可能多的 SQL 移到存储过程中。然后使用 C# Forms 或 Web 应用程序构建一个新的前端。如果您可以将业务逻辑和 SQL 从前端移出，那么以后重新执行会更容易。通过将您所做的工作保留在小项目中，如果它在任何时候被搁置或停止，您将取得进展并将得到利用。