我在公司里多次设计过数据库。为了提高数据库的性能,我只查找规范化和索引。
如果要求您提高数据库的性能,该数据库有大约250个表和一些包含数百万条记录的表,那么您需要查找哪些不同的内容?
提前致谢。
答案 0 :(得分:10)
优化逻辑设计
逻辑级别是关于查询和表本身的结构。首先尝试最大化这个。目标是在逻辑级别访问尽可能少的数据。
优化物理设计
物理层面处理非逻辑考虑因素,例如索引类型,表格参数等。目标是优化IO,这始终是瓶颈。调整每个表以满足其需要。可以在DBMS缓存中永久加载小表,具有低写入速率的表可以具有与具有高更新速率的表不同的设置以占用更少的磁盘空间等。根据查询,可以使用不同的索引等。您可以使用物化视图等透明地使用非规范化数据
首先尝试改进逻辑设计,然后是物理设计。 (两者之间的界限是模糊的,所以我们可以争论我的分类)。
优化维护
必须正确操作数据库才能保持尽可能高效。这包括一些可能对性能产生影响的主要措施,例如
答案 1 :(得分:4)
这是一个非常模糊的问题。
你说你在寻找索引,但你不能孤立地看索引。您必须查看正在运行的查询,执行计划,正在使用的索引以及它们的使用方式。 Profiler工具可以帮助确定哪些查询效率低下。
除此之外 - 确保设置维护计划。您应该在繁重的事务数据库中每周至少更新一次统计信息和碎片整理/重建索引。
如果您有基础结构,请查看文件和文件组设置。如果可能,您应该尝试将大型且经常使用的表和/或索引放在不同的物理驱动器上。如果你有任何非常大的表,你可能会考虑对它们进行分区。
如果您仍然遇到性能问题,非规范化有时会有所帮助 - 但这一切都取决于具体情况。
我要停在那里 - 不希望这个答案成为世界上最随机的SQL性能提示列表。我建议您更具体地了解您认为性能问题的位置,并告诉我们更多关于数据库的信息(大小,当前索引策略,事务频率,您需要生成的任何大型报告等)。
答案 2 :(得分:4)
<强>压缩即可。对于我尝试的绝大多数负载,使用压缩是一个巨大的免费搭车。减小数据大小意味着减少I / O意味着更好的吞吐量。在SQL Server 2005中,压缩选项是有限的(vardecimal
)。但我会认真考虑单独升级到2008以进行页面压缩。或者2008 R2如果经常使用nvarchar
来获得Unicode压缩。
数据保留。建立保留策略并积极删除旧数据。数据越少意味着I / O越少,意味着吞吐量越高。通常这被认为是可操作的,而不是设计,但我喜欢将此问题视为应用程序设计问题。
当然,我假设你已经监控了每一个查询,以确保没有一个是愚蠢的端到端表扫描。
更多的性能提升器主要是操作或部署,而不是设计:维护(碎片整理,索引重建等),I / O和存储设计等。
最后但并非最不重要的是了解各种交钥匙解决方案的隐性成本。比如说,复制或数据库镜像。
答案 3 :(得分:2)
对于规范化和索引的工具包,对于非常大的表,您可能还需要考虑分区表的优缺点。但是你已经有了关键的那些。
答案 4 :(得分:2)
你可以做很多事情,上面已经提到了很多。我会看一些(按此顺序):
这些都是非常高级别的,我还会看看你的数据库引擎的供应商建议什么是性能改进。
另外,我会根据我的老板愿意支付的费用以及我有多少时间来衡量这样的清单。 ;)
希望这有帮助。
答案 5 :(得分:2)
我在MySpace的评论是“Performance Enhancement DBA / Developer”。我会说规范化和索引是高性能数据库中的一项要求,但您必须真正分析表结构和索引才能真正释放数据库设计的功能。
以下是我给你的一些建议;
了解数据库引擎。通过了解下划线I / O结构,可以在设计合适的索引或表时花费很长的路。使用PerfMon和Profiler,以及您对读/写I / O的了解,您可以在理论上提供一些非常具体的数字,这些数据是一个结构良好的表/索引解决方案。
了解群集索引和非群集索引之间的区别以及何时使用哪些索引。
使用sys.dm_os_waiting_tasks和sys.dm_os_wait_stats DMV。他们会告诉你应该把你的努力放在哪里以减少等待时间。
使用DBCC SET STATISTICS IO / TIME ON,并评估您的执行计划,以查看是否有一个查询减少或增加了页面读取次数或持续时间。
DBCC SHOWCONTIG将告诉您表格是否严重碎片化。从性能的角度来看,开发人员和Jr. DBA经常会忽略这一点 - 但是,这会对您拥有的页面读取数量产生非常大的影响。如果一个表具有20%的扩展区页面密度,那么这意味着如果对表和它的索引进行碎片整理,那么您读取的数据大约是5倍。
评估脏读(nolock,读取uncommited)。如果你可以在读取时取消毫秒精度,那么保存锁!
考虑取出不必要的外键。它们在Dev环境中很有用,而不适用于高性能事务系统。
大表中的分区会产生很大的不同 - 只有设计得当。
应用程序更改 - 如果您可以为异步事务安排批量更新,请将它们放入无索引堆中并按计划处理它,这样您就不会不经常更新您查询的表。
永远永远!使用相同的数据类型变量来查询目标列;例如,以下语句对smallint列使用bigint变量:
宣布@i bigint 设置@i = 0
从MyTable中选择*,其中Col01SmallInt&gt; = @i
在评估索引/表页面的过程中,查询引擎可以选择将smallint列数据转换为bigint数据类型。相反,请考虑更改您的varialbe类型,或至少在搜索条件中将其转换为smallint。
这就是我能想到的全部。如果您遇到更具体的问题,我会为您提供更具体的答案..
答案 6 :(得分:1)
如果查询对任务至关重要,您可能需要考虑 de -normalizing,以减少每个查询的表查找次数。 除此之外,如果您需要超出索引和非规范化可以执行的性能,您可能需要查看程序端:缓存,优化查询/存储过程等。
答案 7 :(得分:1)
为了提高性能,您需要先监控数据库。您可以在sql server profiler中跟踪并加载它,以找出哪些是最慢的查询。之后你可以专注于他们。
您还可以使用动态视图和管理功能找出缺少的索引。您还可以检索有关现有索引的统计信息,例如索引使用和遗漏索引。
答案 8 :(得分:0)
优化用于访问该数据库的查询是最重要的。只需添加索引,您就不能保证查询将使用它们。
答案 9 :(得分:0)
我们还没有写过一个性能位:
硬件
数据库受到强烈的I / O驱动。迁移到更快的硬盘驱动器应该可以提高数据库查询的速度。在许多快速硬盘驱动器中拆分数据库可能会进一步改善它。