网站做的好的tkd,培训机构怎么做线上推广,中国建设标准化协会网站,苏州好的做网站的公司原文 http://www.cnblogs.com/BoyceYang/archive/2013/06/15/3138142.html 阅读导航 1. 概述 2. 规范逻辑数据库设计 3. 使用高效索引设计 4. 使用高效的查询设计 5. 使用技术分析低性能 6. 总结 1. 概述 在比较大的范围内找出能够大幅提高性能的区域#xff0c;并且专注于分析…原文 http://www.cnblogs.com/BoyceYang/archive/2013/06/15/3138142.html 阅读导航 1. 概述 2. 规范逻辑数据库设计 3. 使用高效索引设计 4. 使用高效的查询设计 5. 使用技术分析低性能 6. 总结   1. 概述 在比较大的范围内找出能够大幅提高性能的区域并且专注于分析这个区域这是最有效的优化SQL Server性能的方式。否则大量的时间和精力可能被浪费在不能提高很大性能的区域。在这里并没有讨论关于多用户并发所带来的性能问题。 能获得最大性能提高的区域一般是逻辑数据库设计索引设计查询设计。然而最大的性能问题经常由于缺乏这些方面研究的原因造成。如果性能是被列为一个需要关注的问题聪明的做法是首先专注于这些方面 因为性能的大幅提高经常是用相对较小的时间精力完成。 下面开始进入正题。 2. 规范逻辑数据库设计 合理规范性的逻辑数据库设计可以产生最佳性能。大量的窄表是标准数据库的特性。少量的宽表是非标准数据的特性。高度标准数据库通常关联着复杂的表的 联合查询这个可能损害数据库的性能。不管怎么样SQL Server优化在快速查询、高效联接、可用有效索引方面是非常有效的下面是规范化的好处 如果是窄表应该加快排序和创建索引 如果是宽表最好使用聚集索引 索引往往是越窄的表越应该精确 更好的利用段去控制表的物理空间 每个表的索引越少对提高UPDATE操作的性能越有帮助 越少的NULLs列越少的冗余数据越能增加数据库的紧凑性 对于SQL Server标准化将有助于提升而不是损害性能。随着标准化的提高因此需要一定数量并且复杂的表连接来检索数据。只要标准化不会导致很多查询出现超过四个表的连接就应进行标准化进程。 如果逻辑数据库设计已经固定并且不可能进行整体重新设计而且通过研究表明一个大表存在性能瓶颈在这样的情况下可以有选择性的对这个大表进行 标准化。如果过存储过程进行访问数据那么架构的改变不会影响应用程序。如果不是这样可以通过创建视图来隐藏这种改变因为视图可以产生单个表的错觉。 3. 使用高效索引设计 不像很多非关系系统不把关系索引考虑作为逻辑数据库设计的一部分。索引能被删除、添加和更新除了影响性能以外不会影响数据库架构或者应用程序 设计。实现良好的SQL Server性能高效索引设计是非常重要的。由于这些原因不要犹豫展示不同索引带来的性能改变吧。 大多数情况下优化器将可靠地选择最高效的索引。所有的策略应该提供良好的索引优化的选择相信这是正确的决定。这可以在多种情况下减少分析时间并且能提供良好的性能。 接下来介绍索引。检查SQL查询的WHERE子句因为这个是优化的主要焦点。在WHERE子句中列出的列都有可能成为索引的备选。假如有太多的语句需要检查挑选有代表性的一组或者仅仅是速度缓慢的那组。 最好使用窄索引。窄索引比混合索引和复合索引更加高效。窄索引每页行越多索引级别应该越低这样才能提高性能。SQL Server优化只是维护统计数据在复合索引最重要的列上。因此如果复合索引的第一列可选择性很差那么就不优化这个索引。 优化器可以快速、高效的分析成百上千的索引和表连接的可能性。有更多的窄索引提供给优化器优化器就会有更多可能的选择这对性能很有帮助。有较少的宽索引、复合索引提供给优化程器优化器只有很少选择的可能性这对性能会有影响。 索引数目太多性能可能会降低因为涉及到更新这些索引的开销。然而大量的面向更新操作需要更多的读操作而不是写操作。假如尝试新索引时提高了性能那就不要犹豫使用这个所以吧。 使用聚集索引。适当的使用聚集索引可以极大的提升性能。甚至聚集索引可以使UPDATE和DELETE操作提速因为这些操作需要很多读操作。可能 每个表只有单一的聚集索引因此要灵活地利用这个索引。返回行数的查询或者涉及一个范围值的查询都是一个可能被聚集索引提高性能的候选。 例子 1: SELECT * FROM PHONEBOOK 2:   3: WHERE NAME ‘李雷’ 4:   5: SELECT * FROM MEMERTABLE 6:   7: WHERE MEMBER_NO 5000 AND MEMBER_NO 6000 通过约束上面提到的NAME和MEMBER_NO列对于非聚集索引可能不是一个适合的候选。尽量在返回很少行数据的列上使用非聚集索引。 检查列数据的唯一性。这样将帮助决定什么样的列作为聚集索引、非聚集索引、无需索引的备选。 查询语句检查数据的唯一性例子 1: SELECT COUNT (DISTINCT COLNAME) FROM TABLENAME 这个语句将返回一个列中不重复值的数量。在表中比较这个数量和总的行数。在一个一万行的表中5000个不重复值的列对于非聚集索引可能是一个很好 的备选20个不重复值的列可能最适合聚集索引3个不重复值的列根本就不需要使用索引。这些仅仅是个例子不是一成不变的规则。记住把索引建立在WHERE查询子句列出的每一个列上。 在索引选择时查询语句返回行数也是一个重要的因素。优化器会考虑非聚集索引花费在每个返回行至少一页I/O的成本。以这样的速度并不需要很长的时间就可以变得更高效的扫描整个表。理性对待结果集要么限制结果集的大小要么使用聚集索引定位巨大结果集。 4. 使用高效的查询设计 某些查询语句本身是资源密集型。这关系到基本数据和索引在大多数RDBMSs关系型数据库管理系统的常见问题而不是在特定SQL Server中。它 们并不低效优化器将会尽可能实现高效的查询语句。然而它们是资源密集型SQL面向结果集的本性可能使它们出现低效。优化器的智能程度不可能消除这些 结构的固有资源成本。和更加简单的语句相比他们内在的消耗更大。尽管SQL Server使用最优的访问计划但还是会有限制的。 例如 大型结果集 IN和OR语句 高度非唯一WHERE子句 !不等于 某些列函数比如SUM WHERE子句中的表达式或数据转换 WHERE子句的局部变量有些因素可能需要使用这些查询语句结构。如果优化器可以限制结果集然后再应用资源密集型的查询那么他们的影响将会减少。 例如: 1: 低效: SELECT SUM(SALARY) FROM TABLE 2:   3: 高效: SELECT SUM(SALARY) FROM TABLE WHERE ZIP98052 4:   5: 低效: SELECT * FROM TABLE WHERE LNAMEVAR 6:   7: 高效: SELECT * FROM TABLE WHERE LNAMEVAR AND ZIP98052 在第一个例子中SUM操作使用索引并不能使其加速。每行都需要被读和求和。设想在ZIP列有一个索引优化器将可能使用这个来初始限制结果集然后再应用SUM函数。这可能会更快。 在第二个例子中局部变量直到运行时才被赋值。然而优化器无法拖延到运行时才选择访问计划必须在编译时进行选择。然而在编译期间当生成访问计 划时VAR的值还不能确定因此不能使用输入的VAR作为索引选择。可以使用AND子句对结果集进行限制。使用存储过程是一个可选技术这样可以传 递参数将参数赋值给存储过程中VAR值。 大多数RDBMSs的大型结果集是很耗费性能。可以尝试不返回大型结果集到客户端作为最终数据选择。允许数据库后台执行预定函数并限定结果集的大小这种做法效率很高。 5. 使用技术分析低性能 首先分离查询或者分离比较慢的查询。当有少数SQL查询速度慢经常表现为整个应用程序速度慢。对能够显示生成SQL的工具使用这个工具的诊断或调试模式记录生成的SQL。使用嵌入式SQL工具会更加简单。分离速度慢的查询之前先做一下下面的步骤 单独运行疑似速度慢的语句使用工具例如ISQL、SAF验证实际上是不是很慢。 使用SET STATISTICS IO ON检查语句的I/O消耗和已选择的访问计划。优化器的目的是最小的I/O。记录逻辑I/O。以这个为基准测量改进成果 如果查询涉及视图或者存储过程从中提取这些语句并单独运行。当尝试使用不同索引时访问计划是可以改变。 有些表可以生成I/O作为触发器运行这时要注意可能和这些表有关系的触发器和视图。 检查速度慢的语句表的索引。利用之前列出的技术检查是否有更好的索引如果有必要就修改。 改变索引后重新运行查询并观察I/O和访问计划的改变。 改进工作完成运行主程序看看所有的性能是不是有所提升。检查程序的I/O或CPU限制的行为。通常这个对确定查询语句是否在I/O或CPU临界状态很有用。我们要花费精力在提高真正的性能瓶颈上例如 如果一个查询是CPU临界状态就算增加更多的内存给SQL Server也太可能有性能的提高当然更多的内存还是能提高缓存命中率。下面的步骤是检查SQL Server的I/O和CPU临界状态 使用OS/2 CPU监控程序。 当运行查询时如果CPU使用率保持很高70%这表明是CPU临界状态。 当运行查询时如果CPU使用率保持很低50%这表明也是CPU临界状态。 使用STATISTICS IO比较CPU利用率信息 6. 总结 SQL Server能够提高大型数据库的性能。要挖掘这个性能的潜力需要有高效的数据库设计、索引和查询语句。这些区域是最可能成为捕获到重大性能提升的备选区域。尝试使用索引是一个很特别建议。通常系统化的方法在分析性能问题上不仅投入时间少而且能产生巨大性能提升。   在此特别感谢守望dreamstar对本篇文章的支持。