如何提高数据库的性能？

Question

我在公司里多次设计过数据库。为了提高数据库的性能，我只查找规范化和索引。

如果您被要求提高一个数据库的性能，这个数据库有大约250个表格和一些包含数百万条记录的表格，您会寻找什么不同的东西？

在此先感谢。

Answer 1

优化逻辑设计

的逻辑电平是有关查询和表本身的结构。尝试首先将其最大化。目标是在逻辑层次*问尽可能少的数据。

• 拥有最高效的SQL查询
• 设计，支持应用程序的需要（如类型列等）
• 设计权衡，以支持一些使用情况下比其他
更好的逻辑架构
• 关系约束
• 正常化

优化物理设计

物理层面处理非逻辑考虑，如索引类型，表格参数等。目标是优化始终是瓶颈的IO。调整每张桌子以适应它的需要。小表可以在DBMS缓存中永久加载，低写入率的表可以具有与高更新率的表不同的设置，以占用更少的磁盘空间等。根据查询，可以使用不同的索引等。您可以透明地与物化视图非规范化数据等

• 表paremeters（分配大小等）
• 指标（结合，类型等）
• 全系统的参数（高速缓存大小等）
• 分区
• 非规范化

先尝试改进逻辑设计，然后进行物理设计。 （但两者之间的界限是模糊的，所以我们可以争论我的分类）。

优化维护

必须将数据库操作正确停留尽可能高效。这包括一些可能影响性能的维护措施，例如，

• 保持统计最新
• 重新排序的关键定期表
• 磁盘维护
• 系统所有的东西有一个岩石

Answer 2

对于标准化和索引编制工具包，如果使用非常大的表格，您可能还需要考虑分配表格的优缺点。但你已经有关键的那个。

Answer 3

如果某个查询非常关键，您可能需要考虑-normalizing，以减少每个查询的表查找次数。 除此之外，如果您需要的性能超出了索引和反规范化的范围，您可能需要查看程序端：缓存，优化查询/存储过程等。

Answer 4

这是一个非常含糊的问题。

你说你在寻找索引，但你不能单独看索引。您必须查看正在运行的查询，执行计划，正在使用的索引以及如何使用它们。 Profiler工具可以帮助您确定哪些查询效率低下。

除此之外 - 确保设置维护计划。您应该至少每周在繁忙的事务数据库中更新统计信息和碎片整理/重建索引。

如果您有基础架构，请查看您的文件和文件组设置。如果可能的话，您应该尝试将大型且经常用于不同物理驱动器的表和/或索引。如果你有任何非常大的表，你可能会考虑对它们进行分区。

如果你仍然有性能问题，非规范化有时可以帮助 - 但这一切都取决于情况。

我将停在那里 - 不希望这个答案成为世界上最随机的SQL性能提示列表。我建议你更具体地考虑你认为性能问题的位置，并告诉我们更多关于数据库的信息（规模，当前索引策略，交易频率，任何需要生成的大型报告等）。

Answer 5

In为了提高性能，您需要首先监控数据库。您可以跟踪并在sql server profiler中加载它，以找出哪些是最慢的查询。之后，你可以专注于他们。

您还可以使用动态视图和管理功能来找出哪些索引丢失。您还将能够检索有关现有索引的统计信息，如索引使用情况和错过的索引。

Answer 6

优化用于访问该数据库的查询是最重要的。只需添加索引，您不保证查询将使用它们。

Answer 7

压缩。对于我尝试过的绝大多数负载来说，使用压缩技术是一次巨大的免费搭乘。数据量减小意味着I/O的减少意味着更好的吞吐量。在SQL Server 2005中，压缩选项是有限的（vardecimal）。但是我会认真考虑单独升级到2008年的页面压缩。或者2008 R2，如果经常使用nvarchar来获得Unicode压缩。

数据保留。建立保留策略并积极删除旧数据。数据量少意味着更少的I/O，意味着更好的吞吐量。通常这被看作是可操作的，而不是设计，但我喜欢把这个问题看作应用程序设计问题。

当然，我假设您已经监视每个查询，以确保没有愚蠢的端到端表扫描。

还有更多的性能助推器大多运营或部署，而不是设计：维护（碎片整理，索引重建等），I/O和存储设计等

最后但并非最不重要的了解各种又将隐藏成本键解决方案。比如说，复制或数据库镜像。

Answer 8

我们还没有写过一个性能位：

硬件。

数据库是强烈的I/O驱动。转向更快的硬盘应该会提高数据库查询的速度。将数据库拆分成许多快速硬盘驱动器可能会进一步改善它。

Answer 9

有很多事情你可以做，其中很多已经建议上面。一些我会看（按此顺序）：

• 错误/日志 - 许多数据库引擎都有报告工具，指出数据库中的问题区域。从这里开始，看看是否有任何事情可以马上关注。
• 数据保留 - 检查业务规范应该保留多长时间的数据，确保将任何较旧的数据移出到数据仓库以保持表的大小。 （为什么要保留5年的数据，如果只需要最后3个月？）
• 寻找表扫描，索引数据，如果它会帮助（你必须衡量这与表写入）。您的服务器日志可能可以帮助您查找表扫描。
• 工作的原子元素，是否有一些写入在达到提交点之前在不同的表上保留锁定？这些工作要素可以简化还是提交点以加快绩效？这是您需要开发人员查看代码的地方。
• 查找长时间运行的SQL语句，可以使它更高效吗？有时结构不佳的查询可能会导致应用程序停滞。您可能需要建议编码更改以提高性能。
• dba realm：看看如何分配表格：页面大小，多个细分等。这就是供应商的诊断工具派上用场的地方，因为他们通常可以建议如何根据使用历史记录来构建表格。有经验的dba在这里很有用。
• 寻找硬件/网络瓶颈。这是你需要硬件人员的地方。 :)

这些都是非常高的水平，我还会看看你的数据库引擎的供应商建议作为性能改进。

另外，我会根据我的老板愿意支付的费用以及我有多少时间来计算一份这样的清单。 ;）

希望这会有所帮助。

Answer 10

我在MySpace上卷是“服务器性能增强DBA /开发人员“。我想说规范化和索引是高性能数据库的一个要求，但是你必须真正分析你的表结构和索引，才能真正解开数据库设计的威力。

这里有一些建议，我会为你;

1. 了解数据库引擎。通过对下划线I/O结构的了解，在设计适当的索引或表格方面有很长的路要走。通过使用PerfMon和Profiler，以及您对读/写I/O的了解，您可以在理论上形成完善的表格/索引解决方案。

2. 了解群集和非聚集索引以及何时使用它们之间的差异。

3. 使用sys.dm_os_waiting_tasks和sys.dm_os_wait_stats动态管理视图。他们会告诉你应该在哪些方面减少等待时间。

4. 使用DBCC SET STATISTICS IO/TIME ON，并评估执行计划，看看是否一个查询减少或增加页面的读取次数或持续时间。

5. DBCC SHOWCONTIG会告诉你，如果你的表是大量碎片。从性能的角度来看，开发人员和小型数据库管理员通常忽略这一点 - 但是，这会对读取的页面数量产生非常大的影响。如果一个表的页面密度达到20％，那么这意味着您读取的数据大约是数据的5倍，否则，如果该表及其索引经过了碎片整理，那么数据将是该数据的5倍。

6. 评估脏读（nolock，未读未读）。如果您可以在读取时取消毫秒精度，请保存锁！

7. 考虑取出不必要的外键。它们在Dev环境中非常有用，而不是在高性能事务处理系统中。

8. 分区的大表有很大的不同 - 只是如果设计得当。

9. 应用程序更改 - 如果您可以为异步事务计划批量更新，请将它们放入无索引堆并按计划进行处理，这样您就不会持续更新大量查询的表。

10. 永远始终永远!!!使用相同的数据类型变量来查询目标列;例如，以下语句用BIGINT变量用于SMALLINT柱：

DECLARE @i BIGINT 组@i = 0

SELECT * FROM MyTable的其中Col01SmallInt> = @i

在评估索引/表页面的过程中，查询引擎可能会选择将smallint列数据转换为bigint数据类型。相反，改变你的varialbe类型，或者至少在你的搜索条件下将它转换为smallint。

1. SQL 2005/08为您提供管理应用程序中的“报告”，查看关于您的索引如何执行的报告。他们正在被扫描，寻找？你最后一次表扫描是什么时候？如果它是最近的，你的索引没有完成所有必要的查询。如果你有一个很难被使用（查找或者扫描）但是不断更新的索引，考虑放弃它。它可以为你节省大量不必要的行锁和键锁。 ..

这是所有我能想到的把我的头顶部。如果遇到更具体的问题，我会给你一个更具体的答案。