Gen*_*нин 8 database sql-server performance configuration database-design
在优化(性能调整,故障排除)现有(但未知)数据库时,最重要的问题是什么以及在哪个重要性顺序中进行研究？
您之前优化中的哪些操作/措施产生的影响最大(可能是最少的工作)？
我想将这个问题分成以下几类(按照我感兴趣的顺序):
更新:
假设我在dev机器上有一个数据库的副本,无法访问生产环境,以观察实际使用中的统计数据,最常用的查询,性能计数器等.
这与开发相关,但与DBA无关.
Update2:
假设数据库是由其他人开发的,并且在交付到生产之前提供给我进行优化(审核).
通常将外包开发与最终用户分离开来.
此外,还有一种数据库设计范例,与应用程序数据存储相比,数据库本身应该是一个独立于使用它的特定应用程序或其使用环境的值.
Update3:感谢所有的回复者!你们都推动我打开子问题
你们如何在本地加载dev数据库(服务器)？
创建性能基准(非侵入式,使用性能计数器)
识别最昂贵的查询(非侵入式,使用SQL Profiler)
识别最常运行的查询(非侵入式,使用SQL事件探查器)
识别任何过于复杂的查询,或使用缓慢执行的构造或模式的查询.(非侵入式识别,使用SQL事件探查器和/或代码检查;如果更改可能会侵入,可能需要进行大量的重新测试)
评估您的硬件
确定有利于测量工作负载的索引(非侵入式,使用SQL事件探查器)
测量并与您的基线进行比较.
如果您有非常大的数据库或极端操作条件(例如24/7或超高查询负载),请查看RDBMS提供的高端功能,例如表/索引分区.
这可能是有意义的:如何记录和查找最昂贵的查询？
如果您不知道数据库,并且您处于压力之下,那么您可能没有时间使用Mitch的清单,这是监控服务器运行状况的最佳做法.
您还需要访问生产以从可以运行的各种查询中收集实际信息.没有这个,你就注定要失败.服务器负载模式很重要:您不能在开发服务器上自己重现许多问题,因为您不会像最终用户那样使用系统.
此外,专注于"最大的降压".每天凌晨3点运行一次的昂贵查询可以忽略.一个不那么昂贵的每秒运行非常值得优化.但是,如果不了解服务器负载模式,您可能不知道这一点.
所以,基本步骤..
假设你正在消防:
反应慢:
你应该拥有的东西:
编辑:更新后
静态分析仅是最佳实践:您无法优化使用.这就是你能做的一切.这是marc_s的回答.
您可以猜出最常见的查询可能是什么,但您无法猜测将会写入多少数据或查询与更多数据进行扩展的程度
在许多商店开发商提供一些支持,直接或作为*第3行"
如果你被另一个团队给了一个数据库供你审查,那么你就交给另一个团队进行部署:这很奇怪.
如果您对数据库的运行时行为不感兴趣,例如最常执行的查询和消耗时间最多的查询,则只能对数据库结构本身进行"静态"分析.实际上,这个价值要低很多,因为你只能检查一些关键设计不好的关键指标 - 但是你无法真正讲述所用系统的"动态".
我将在数据库中检查的内容.bak- 我无法收集实时和实际的运行时性能统计信息 - 将是:
规范化 - 表格结构是否归一化为第三范式？(至少大部分时间 - 可能有一些例外)
所有表都有主键吗？("如果它没有主键,它就不是表格",毕竟)
对于SQL Server:所有表都具有良好的聚类索引吗？一个独特的,窄的,静态的,最好是不断增加的聚类键 - 理想情况下是一个INT IDENTITY,绝对不是许多字段的大型复合索引,没有GUID和没有大的VARCHAR字段(参见Kimberly Tripp 关于主题的优秀博客文章)细节)
数据库表上有任何检查和默认约束吗？
是非聚集索引备份的所有外键字段,以加速JOIN查询？
在数据库中是否存在任何其他明显的"致命罪",例如过于复杂的视图,或者设计非常糟糕的表等.
但同样:如果没有实际的运行时统计信息,从"静态分析"的角度来看,您可以做的事情非常有限.只有当您从常规操作日获得工作负载,查看经常使用的查询并对数据库施加最大压力时,才能真正实现真正的优化 - >使用Mitch的核对表检查这些点.