【发布时间】：2010-12-24 23:56:36
【问题描述】：
我有一个中型 SQL Server 2008 数据库，其中包含精算数据。它的所有用例都是只读查询。考虑到这种情况，我应该考虑任何特殊的优化吗？还是我应该坚持优化数据库的常规规则？
【问题讨论】：
【发布时间】：2010-12-24 23:56:36
【问题描述】：
一种策略是向您的数据库添加一个只读文件组，并将您的只读表放在那里。只读文件组允许 SQL Server 进行许多优化，包括消除所有锁等。
除了标准的数据库优化：
- 确保所有表和索引的碎片为零
- 考虑添加因更新成本过高而原本可以避免的索引
【讨论】：
-
在 SQL Server 2012+ 中不再需要消除所有锁
在数据库中：
- 对其进行非规范化。
- 在需要时使用更多索引。
- 如果您需要在报告中汇总一些数据。
在程序中：
- 使用 READ UNCOMMITTED 隔离级别。
- 使用自动提交来逃避长期事务。
【讨论】：
如果它是只读的，您可以做的一件事是将索引放在几乎任何可能有帮助的东西上（空间允许）。通常，添加索引是在写入性能下降和读取性能提升之间进行权衡。如果您摆脱写入，则不再是一种权衡。
当您加载数据库时，您可能希望删除所有/大部分索引，执行加载，然后将索引放回表中。
【讨论】：
-
为什么要在加载时删除所有/大部分索引？加载数据时您可能会获得稍好的性能，但您可能会冒着不放回索引的风险。不仅如此，如果您关闭索引并加载错误数据，您将不会看到问题，直到您尝试将索引放在那里（如果您记得的话）。加载数据是一次性的，并不是一直发生的事情。如果插入需要更长的时间，那没什么大不了的。拥有有意义的数据，无价之宝。
-
Wlater，删除索引并重新创建它们是一种常见的加载方式，它可以极大地加快速度。您不必记住将它们放回原处，它是 SSIS 包的一部分，负责加载。我认为您正在考虑放弃通常不想做的 pks 和 FKs。
-
正如 HLGEM 所说，我并不是说您应该删除 PK/FK（尽管在某些情况下甚至可能更喜欢这样做）。在可能涉及许多索引的情况下加载大量数据时的差异可能远不止“更长一点”。
-
删除非唯一索引很好。应保留任何（非冗余）唯一索引或其他约束。
-
他们是否应该留下是一个判断。如果我有一个准确的数据源并且删除 FK 将显着提高导入性能，那么我将权衡这种优势与必须进行恢复的风险，因为由于数据错误而将它们添加回去失败。将不良数据导入数据库并不意味着您必须将其保留在那里。显然，任何 ETL 过程都应该在最后包含一个回滚计划的检查，以防出现问题。
我不确定你认为什么是“正常规则”，但这里有一些建议。
如果您 100% 确定它是只读的，您可以set the transaction isolation level to READ_UNCOMMITTED。这是可能的最快读取设置，但如果您正在写入表，则会导致幻读和脏读。
如果您有视图，请使用索引视图（为它们创建聚集索引）。由于它们永远不必更新，因此可以消除性能损失。
【讨论】：
- 对数据进行非规范化。
- 应用适当的索引。
- 预先计算聚合。
- 在条带磁盘上实现数据库。
- 我从未见过这样做过，但如果您能以某种方式将整个内容加载到内存（RAM 磁盘？？？）中，那将是超快的，对吧？
【讨论】：
对于只读表，请考虑更改索引以使用 100% 的填充因子。
这将增加每个数据页上的数据量。每页数据更多，要读取的页面更少，I/O 更少，因此性能更好。
我喜欢这个选项，因为它无需更改代码或更改表即可提高性能。
【讨论】：
对于性能调整，您可以做几件事。 Denormailzation 有效。适当的聚集索引取决于如何查询数据。我不建议使用 nolock 提示。我会使用快照隔离级别。
您的数据库在磁盘上的布局方式也很重要。对于只读性能，我建议使用 Raid 10，将 mdf 和 ldf 分别用于隔离的主轴。通常，对于生产数据库，数据为 Raid 5，日志为 Raid 1。确保每个 cpu 都有一个 tempdb 文件，用于排序，一个好的起始大小是 5gb 数据和每个 cpu 1 gb 日志。还要确保通过 showplan 运行查询或过程，以帮助尽可能优化它们。确保在服务器设置中启用了并行性。
此外，如果您有时间和空间来获得最佳性能，我会准确地绘制出数据在磁盘上的位置，创建文件组并将它们放在完全独立的卷上，这些卷是每个卷中的独立磁盘。
【讨论】：