这是很常见的情况，开发人员和管理员之间存在争执。有人指责数据库设计和查询很糟糕，而其他人则说这是硬件和数据量不足造成的。
所以我想问您，我的 IBM x3400 配备 2 台 2GHz xenon 和 SCSI raid 5 以及 4GB RAM，是否足以容纳 53GB 的 MSSQL 数据库，其中表格主要详细信息约为 650 万条记录（详细信息）和 200 万条文件标题，而其他记录（例如项目）约为 10 万条。
我们在从 SQL 获取数据时不断遭受性能不足的困扰，该服务器仅专用于作为 SQL 服务器，并充当来自其他 SQL 服务器的复制数据的订阅者。
另一个问题是数据库管理员如何规划数据库服务器的硬件大小？是否有一些标准方法，还是只是经验和感觉？
答案1
- 如今 4 GB 内存简直就是个笑话。所以，不，抱歉。我想你在这方面已经完成了。它可以工作，但这需要特定的使用模式。原则上我不会在 4 GB 硬件上运行数据库服务器 - 16 GB 内存几乎不需要花费任何成本。
- SCSI RAID 5 并非最佳选择。根据使用模式，您至少应该有两组 - 一组用于写入（日志），一组用于读取（数据）。我曾使用 4+ 个磁盘的 RAID 10 来存储 OS 和 LOG，另一组用于存储数据，效果很好。不过请注意，数据库要大得多。在您的情况下，抛弃 RAID 5 并只放入两个镜像 SSD 是合理的，因为您的数据只有 53 GB。两个 SSD 的镜像可能会将您的 IO 性能提高 100 倍。您的 RAM 可能会限制 IO，而按照今天的标准，RAM 非常少。如果听起来很粗鲁，请原谅，但数据库服务器应该比开发人员工作站拥有更多的 RAM，并且取决于您所在的公司，您的 RAM 可能与开发人员工作站相同或远远低于开发人员工作站。
是否存在某种标准方法，还是仅仅是经验和感觉？
经验和意识。你还可以提前思考，并在几年内检查什么是有意义的。例如，SuperMicro 拥有 NICE 服务器，在 SAS 配置中可容纳 24-72 个磁盘。因此，你可能会得到一个服务器来避免使用 SAN（更昂贵），并根据需要填充磁盘。其他人会得到一个小型服务器，然后就没有选择。你还可以从普通工作站上的测试中获得一些想法。
这是标准的故事，开发人员和管理员之间存在争斗。
不它不是。
有人谴责数据库设计和查询不佳，而另一些人则说这是由于缺乏硬件和数据量。
又不是。数据库设计可以相当客观地衡量。例如：有一些已记录和已知的方法（很多开发人员基本上完全不知道）。听说过第五范式吗？
查询也一样。我实际上可以看到查询是否有效执行。这里没有真正的灰色区域。话虽如此，可能会有权衡，但如果这变成了一场指责游戏，那么我可以肯定肯定有什么问题。
很多时候，开发人员除了“这是一个简单的选择”之外什么都不知道，也不知道如何处理数据库，然后试图用硬件来解决问题。我经历过这种情况，也见过这种情况。虽然并非总是如此，但这可能是一种猜测。
答案2
对于 RAM 大小，了解可能的“工作集”非常重要，并确保至少拥有足够的 RAM 来处理该工作集的几倍。您的正常工作集是所有常用的索引和数据页，如果能够将它们全部保存在 RAM 中，并有足够的空间用于“更特殊但仍然不罕见”的查询，这将大大减少读取操作所需的磁盘 I/O。
例如，我们客户的一个应用程序的 10Gb 数据库（比您的数据库小很多，但理论上无论您的数据大小如何）包含大约 1Gb 的活动数据页：索引和表行，用户在正常业务过程中可能会定期访问这些页。另外~4Gb 是旧数据，在大多数正常会话中都不会读取（因为大多数视图默认仅显示最多一个月或三个月的数据，并且数据、索引和查询都经过了很好的规划，除非用户要求查看更早的数据（这在日常使用中相对罕见），否则不会读取旧数据页。最后~5Gb 是 blob - 用户附加到记录的文档，除了在审核期间外，添加后很少被访问。即使有这种大小的数据，我怀疑 2Gb RAM 是否足以维持快速访问（我所说的数据库位于专用于运行 MSSQL 的 4Gb 服务器上，另一台机器充当 Web 服务器和与应用程序相关的其他服务）所以您可能需要重新考虑您的数据大小的 RAM 大小 - RAM 现在相对便宜所以假设您的服务器可以管理额外的增加到 8、12 甚至 16Gb，可能会为您的投资带来良好的回报。
当磁盘 I/O 无法避免时，如果您的数据有大量写入活动，我会放弃 RAID5 和 RAID6。标准 RAID10（或标准稍差的 RAID10 安排，如 Linux RAID10 驱动程序和一些硬件解决方案提供的安排）对于大多数读取负载的表现同样出色，对于大多数写入负载的表现明显更好，并且提供类似的冗余（任何一个驱动器都可能发生故障）。如果您不想跳到四个驱动器，您可以尝试三驱动器 RAID10（大多数 IBM 控制器称为 RAID1E），如果您的环境支持的话。此外，非常值得考虑将您的阵列分成两个，正如 TomTom 建议的那样。对于写入操作，您可能会发现，在两个驱动器的 RAID1 阵列上打开事务日志，在另一个驱动器上打开数据文件，其性能将明显优于使用 RAID10 - RAID10 的接近 RAID0 的批量读取性能可能会很快被数据库写入的随机访问特性所扼杀（更新可能分布在文件空间上的数据和索引页，在将数据提交到数据文件之前更新事务日志，并在完成后在日志中将其标记为已提交，等等）。将日志和数据文件活动分离到不同的主轴上可以显著地在许多情况下，它可以提高数据库性能。如果您有足够的空间容纳所需的驱动器，将 tempdb（或任何与 MS 的 tempdb 相当的 RDBMS）等放在第三个阵列上也会产生很大的不同，如果您的查询和存储过程大量使用临时表（查询规划器会在很多情况下背着您考虑使用 tempdb，这有时会令人惊讶！）。当然，使用 SSD 也可以解决随机访问性能问题 - 无论您使用这些或其他阵列安排（或那些和其他阵列排列）很大程度上取决于您的数据库和典型的访问模式。
还有一件事：在投入时间+精力+金钱重新安排 I/O 子系统之前，请确保在繁忙时间运行一些性能指标，以确保您没有任何严重依赖 CPU 的不良程序。有时，复杂的程序（特别是那些以不太理想的方式使用游标的程序）可能会长时间占用 CPU+内存子系统（添加更多 RAM 和更好的 I/O 功能在这里不会有什么不同），并且通常可以通过重新考虑游标/循环或设法将它们完全删除来显着优化。自定义 SQL 跟踪日志记录和 Windows 性能监视器日志记录（或使用不同 OS+DB 组合的人的等效监视工具）的组合可以极大地帮助您找到关键瓶颈的真正所在（内存不足、I/O 性能、不太理想的代码，...），您应该尝试解决问题，直到您相对确定您正在解决正确的问题。
答案3
我认为硬件和代码至少在某种程度上都有问题。
首先，您可以使用 SQL Profiler 和动态管理视图来证明哪些查询很慢，以及它们为什么很慢。从高层次上讲，使用这些工具相当容易，您可以轻松查看您是否受 CPU 限制、磁盘限制、内存限制等。但是，如果不花一些时间，您就无法理解复杂的查询计划和优化。在SQL 性能仪表板这可以帮助您找到一些唾手可得的成果。
另一方面，按照现代标准，该服务器硬件确实很弱。我办公室的个人工作站在各方面都更强大（包括使用 SSD 而不是机械磁盘）。我们部署了 64 位数据库服务器，RAM 超过 16 GB五年前。硬件是任何 IT 运营中最便宜的部分 - 肯定比您在这个问题上花费的几十到几百个工时便宜。
建议：
- 使用性能监视器找出瓶颈的真正所在。确切的数字，而不是猜测。有很多不错的 MSDN 和其他文章介绍要监视哪些计数器。通常是磁盘或 CPU 瓶颈。如果看到磁盘队列长度很高，通常需要更多内存，而不是更快的磁盘！尽可能多地购买 RAM。这意味着您需要 64 位操作系统和 64 位版本的 SQL 服务器。您基本上可以将整个数据库保存在 64 GB 服务器上的 RAM 中。在高峰负载期间，缓冲区缓存命中率性能计数器应保持在 99% 以上。
- 仅当您确定已为最频繁的查询正确索引了数据库时才添加 CPU。与编写不当的查询相比，设计正确且未执行的查询可以节省 1000 倍的执行时间（不是拼写错误）。避免嵌套视图，开发人员喜欢嵌套视图，因为可以重复使用代码，但由于索引经常变得无用，因此性能很差。任何使用游标声称它们更快或“唯一方法”的开发人员都必须立即被解雇。
- 如果您的工作集大于 2 插槽服务器中可用的最大内存，请考虑使用 SSD 而不是机械磁盘。我认为目前是 192 GB，因此您的数据大小还远未达到这个水平。
- 本质上，做这个。