sql-server - 高性能 SQL Server 数据库设计资源

Question

我想要一些关于在线资源(博客、指南等 - 而不是论坛)的建议，以帮助我擅长设计高性能 SQL Server 数据库，这些数据库需要处理大量数据，并且在数据周转方面负载很重以及每分钟的查询次数。

建议？

编辑

我所说的负载主要是数据周转方面的。主表多达100万行，约30个不同大小的数据字段，每天更新约30-40000行新数据，每天至少更新200000行新数据。这些更新全天持续发生。最重要的是，全天都需要从数据库中提取所有更改和更新，以保持大型 Lucene 索引最新。

Answer 1

听起来像是中等服务器上的相当可管理的负载 - 您还没有说在进行这些插入和更新时发生了什么样的读取操作(除了 Lucene 的提取)以及大小(按字节/数据类型)(您给出的基数似乎很好)。

此时，我建议仅使用 regular SQL Server best practices - 确定合适的模式(标准化，然后仅在必要时非标准化)，review execution plans ，使用索引调整向导，use the DMVs查找未使用的索引并将其删除，choose clustered indexes carefully要管理页面拆分，请仔细选择数据类型和大小，然后use referential integrity and constraints where possible to give the optimizer as much help尽可能。除此之外，还有性能计数器并确保您的硬件/软件安装得到调整。

在许多/大多数情况下，您永远不需要超越这一点来实际重新设计您的架构。

但是，即使在这之后，如果读取负载很重，插入和更新可能会导致读取和写入之间的锁定问题，然后您需要考虑应用程序的架构决策。

此外，每天数百万行和 20 万次更新不会让我担心 - 但你提到了 Lucene(即全文索引)，所以大概有些列相当大。更新大型列并导出它们显然需要更长的时间，并且需要更多的带宽和 IO。具有传统数据类型列的狭窄的百万行表中的 30 列将是一个完全不同的情况。您可能想查看更新配置文件，看看是否需要对表进行垂直分区以将某些列移出行(如果它们很大，它们将已经存储在行外)以改进锁定行为。

因此，当读取负载很重时，关键是:插入和更新需要尽可能快，锁定尽可能少(避免锁定升级)，更新尽可能少的索引以支持读取操作。

如果读取负载很大(以致插入/更新开始冲突)但不需要 100% 最新的信息(比如 5 分钟或 15 分钟的延迟不明显)，您可以读取维护的数据库的唯一版本(通过复制相同、为性能建立不同索引、非规范化或不同建模 - 如维度模型)。也许您的 Lucene 索引可以包含附加信息，以便昂贵的读取操作全部保留在 Lucene 中 - 即 Lucene 覆盖许多大型读取操作，从而将数据库上的读取负载减少到支持插入/更新的基本读取(这些通常是小读取)和应用程序的事务部分(即客户服务信息屏幕将使用常规数据库，而您的每小时仪表板将使用辅助数据库)。