sql-server – 优化现有数据库时要检查的首要问题是什么?

前端之家收集整理的这篇文章主要介绍了sql-server – 优化现有数据库时要检查的首要问题是什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在优化(性能调整,故障排除)现有(但未知)数据库时,最重要的问题是什么以及在哪个重要性顺序中进行研究?
您之前优化中的哪些操作/措施产生的影响最大(可能是最少的工作)?

我想将这个问题分成以下几类(按照我感兴趣的顺序):

>需要在最短的时间内显示性能提升(改进).即最具成本效益的方法/行动;
>非侵入性或最麻烦最有效的方法(不改变现有模式等)
>侵入性方法

更新:
假设我在dev机器上有一个数据库的副本,无法访问生产环境,以观察实际使用中的统计数据,最常用的查询,性能计数器等.
这与开发相关,但与DBA无关.
UPDATE2:
假设数据库是由其他人开发的,并且在交付到生产之前提供给我进行优化(审查).
通常将外包开发与最终用户分离开来.

此外,还有一种数据库设计范例,与应用程序数据存储相比,数据库本身应该是一个独立于使用它的特定应用程序或其使用环境的值.

Update3:感谢所有的回复者!你们都推动我打开子问题
How do you stress load dev database (server) locally?

解决方法

如果您对数据库的运行时行为不感兴趣,例如什么是最常执行的查询和消耗最多时间的查询,您只能对数据库结构本身进行“静态”分析.实际上,这个价值要低得多,因为你只能检查一些关键设计不好的关键指标 – 但是你无法真正讲述所用系统的“动态”.

我在一个数据库中检查的东西,我得到的.bak文件 – 没有收集实时和实际运行时性能统计数据的能力 – 将是:

> normalization – 表格结构是否归一化为第三范式? (至少大部分时间 – 可能有一些例外)
>所有表都有主键吗? (“如果它没有主键,它就不是表”,毕竟)
>对于sql Server:所有表都具有良好的聚类索引吗?一个独特的,窄的,静态的,最好是不断增加的聚类键 – 理想情况下是一个INT IDENTITY,绝对不是许多字段的大型复合索引,没有GUID和没有大的VARCHAR字段(有关详细信息,请参阅Kimberly Tripp关于主题excellent blog posts)
>数据库表上是否有任何检查和默认约束?
>是非聚集索引备份的所有外键字段,以加速JOIN查询
>数据库中还有其他任何明显的“致命罪”,例如:过于复杂的观点,或真正设计糟糕的表格等

但同样:如果没有实际的运行时统计信息,从“静态分析”的角度来看,您可以做的事情非常有限.只有当您从常规操作日获得工作负载,查看经常使用的查询并对数据库施加最大压力时,才能真正实现真正的优化 – >使用米奇的清单来检查这些点.

猜你在找的MsSQL相关文章