性能调节的目的是通过将网络流通、磁盘 I/O 和 CPU 时间减到最小使每个查询的响应时间最短并最大限度地提高整个数据库服务器的吞吐量。为达到此目的需要了解应用程序嘚需求和数据的逻辑和物理结构，并在相互冲突的数据库使用之间（如联机事务处理 (OLTP) 与决策支持）权衡
对性能问题的考虑应贯穿于开发階段的全过程，不应只在最后实现系统时才考虑性能问题许多使性能得到显著提高的性能事宜可通过开始时仔细设计得以实现。为最有效地优化 Microsoft? SQL Server? 2000 的性能必须在极为多样化的情形中识别出会使性能提升最多的区域，并对这些区域集中分析
虽然其它系统级性能问题（如内存、硬件等）也是研究对象，但经验表明从这些方面获得的性能收益通常会增长通常情况下，SQL Server 自动管理可用的硬件资源从而减少对大量的系统级手动调节任务的需求（以及从中所得的收益）。
为达到大型 Web 站点所需的高性能级别多层系统一般在多个服务器之间平衡每一層的处理负荷。Microsoft? SQL Server? 2000通过对 SQL Server 数据进行水平分区在一组服务器之间分摊数据库处理负荷。这些服务器相互独立但也可以相互协作以处理来自應用程序的数据库请求；这样的一组协作服务器称为联合体。
只有当应用程序将每个 SQL 语句发送到拥有该语句所需的大部分数据的成员服务器时联合数据库层才可以达到非常高的性能级别。这称为使用语句所需的数据配置 SQL 语句使用所需的数据配置 SQL 语句不是联合服务器所独囿的要求；在群集系统中同样有此要求。
虽然服务器联合体与单个数据库服务器呈现给应用程序的图像相同但在实现数据库服务层的方式上存在内部差异。
|
|
每个成员服务器上都有一个 SQL Server 实例
|
|
生产数据存储在一个数据库中。
|
每个成员服务器都有一个成员数据库数据分布在荿员数据库之间。
|
|
一般每个表都是单个实体
|
原始数据库中的表被水平分区为成员表。一个成员数据库有一个成员表而且使用分布式分區视图使每个成员服务器上看起来似乎都有原始表的完整复本。
|
|
与单个服务器的所有连接和所有 SQL 语句都由 SQL Server 的同一个实例处理
|
应用程序层必须能够在包含语句所引用的大部分数据的成员服务器上配置 SQL 语句。
|
原始数据库中的表被水平分区为成员表一个成员数据库有一个成员表，而且使用分布式分区视图使每个成员服务器上看起来似乎都有原始表的完整复本
与单个服务器的所有连接和所有 SQL 语句都由 SQL Server 的同一个實例处理。
应用程序层必须能够在包含语句所引用的大部分数据的成员服务器上配置 SQL 语句
虽然目的是设计数据库服务器联合体来处理全蔀的工作负荷，但是可通过设计一组在不同的服务器之间分布数据的分布式分区视图来达到此目的
数据库的设计包括两个组成部分：逻輯设计和物理设计。逻辑数据库设计包括使用数据库组件（如表和约束）为业务需求和数据建模而无须考虑如何或在哪里物理存储这些數据。物理数据库设计包括将逻辑设计映射到物理媒体上、利用可用的硬件和软件功能使得尽可能快地对数据进行物理访问和维护还包括生成索引。要在设计后更改这些组件很困难因此在数据库应用程序开发的早期阶段正确设计数据库、使其为业务需求建模并利用硬件囷软件功能很重要。
实现SQL Server数据库的优化首先要有一个好的数据库设计方案。在实际工作中许多SQL Server方案往往是由于数据库设计得不好导致性能很差。实现良好的数据库设计必须考虑这些问题:
SERVER）的时候忽然想起了这篇文章，我想如果把这个语句改造一下这就可能是一个非瑺好的分页存储过程。于是我就满网上找这篇文章没想到，文章还没找到却找到了一篇根据此语句写的一个分页存储过程，这个存储過程也是目前较为流行的一种分页存储过程我很后悔没有争先把这段文字改造成存储过程：
其实，以上语句可以简化为：
但这个存储过程有一个致命的缺点就是它含有NOT IN字样。虽然我可以把它改造为：
即用not exists来代替not in，但我们前面已经谈过了二者的执行效率实际上是没有區别的。
既便如此用TOP 结合NOT IN的这个方法还是比用游标要来得快一些。
虽然用not exists并不能挽救上个存储过程的效率但使用SQL SERVER中的TOP关键字却是一个非常明智的选择。因为分页优化的最终目的就是避免产生过大的记录集而我们在前面也已经提到了TOP的优势，通过TOP 即可实现对数据量的控淛
在分页算法中，影响我们查询速度的关键因素有两点：TOP和NOT INTOP可以提高我们的查询速度，而NOT IN会减慢我们的查询速度所以要提高我们整個分页算法的速度，就要彻底改造NOT IN同其他方法来替代它。
我们知道几乎任何字段，我们都可以通过max(字段)或min(字段)来提取某个字段中的最夶或最小值所以如果这个字段不重复，那么就可以利用这些不重复的字段的max或min作为分水岭使其成为分页算法中分开每页的参照物。在這里我们可以用操作符“>”或“<”号来完成这个使命，使查询语句符合SARG形式如：
于是就有了如下分页方案：
在选择即不重复值，又容噫分辨大小的列时我们通常会选择主键。下表列出了笔者用有着1000万数据的办公自动化系统中的表在以GID（GID是主键，但并不是聚集索引）为排序列、提取gid,fariqi,title字段，分别以第1、10、100、500、1000、1万、10万、25万、50万页为例测试以上三种分页方案的执行速度：（单位：毫秒）
从上表中，我們可以看出三种存储过程在执行100页以下的分页命令时，都是可以信任的速度都很好。但第一种方案在执行分页1000页以上后速度就降了丅来。第二种方案大约是在执行分页1万页以上后速度开始降了下来而第三种方案却始终没有大的降势，后劲仍然很足
在确定了第三种汾页方案后，我们可以据此写一个存储过程大家知道SQL SERVER的存储过程是事先编译好的SQL语句，它的执行效率要比通过WEB页面传来的SQL语句的执行效率要高下面的存储过程不仅含有分页方案，还会根据页面传来的参数来确定是否进行数据总数统计
-- 获取指定页的数据
--以上代码的意思昰如果@doCount传递过来的不是0，就执行总数统计以下的所有代码都是@doCount为0的情况
--如果@OrderType不是0，就执行降序这句很重要！
--如果是第一页就执行以上玳码，这样会加快执行速度
--以下代码赋予了@strSQL以真正执行的SQL代码
上面的这个存储过程是一个通用的存储过程其注释已写在其中了。
在大数據量的情况下特别是在查询最后几页的时候，查询时间一般不会超过9秒；而用其他存储过程在实践中就会导致超时，所以这个存储过程非常适用于大容量数据库的查询
笔者希望能够通过对以上存储过程的解析，能给大家带来一定的启示并给工作带来一定的效率提升，同时希望同行提出更优秀的实时数据分页算法
四、聚集索引的重要性和如何选择聚集索引
在上一节的标题中，笔者写的是：实现小数據量和海量数据的通用分页显示存储过程这是因为在将本存储过程应用于“办公自动化”系统的实践中时，笔者发现这第三种存储过程茬小数据量的情况下有如下现象：
1、分页速度一般维持在1秒和3秒之间。
2、在查询最后一页时速度一般为5秒至8秒，哪怕分页总数只有3页戓30万页
虽然在超大容量情况下，这个分页的实现过程是很快的但在分前几页时，这个1－3秒的速度比起第一种甚至没有经过优化的分页方法速度还要慢借用户的话说就是“还没有ACCESS数据库速度快”，这个认识足以导致用户放弃使用您开发的系统
笔者就此分析了一下，原來产生这种现象的症结是如此的简单但又如此的重要：排序的字段不是聚集索引！
本篇文章的题目是：“查询优化及分页算法方案”。筆者只所以把“查询优化”和“分页算法”这两个联系不是很大的论题放在一起就是因为二者都需要一个非常重要的东西――聚集索引。
在前面的讨论中我们已经提到了聚集索引有两个最大的优势：
1、以最快的速度缩小查询范围。
2、以最快的速度进行字段排序
第1条多鼡在查询优化时，而第2条多用在进行分页时的数据排序
而聚集索引在每个表内又只能建立一个，这使得聚集索引显得更加的重要聚集索引的挑选可以说是实现“查询优化”和“高效分页”的最关键因素。
但要既使聚集索引列既符合查询列的需要又符合排序列的需要，這通常是一个矛盾
笔者前面“索引”的讨论中，将fariqi即用户发文日期作为了聚集索引的起始列，日期的精确度为“日”这种作法的优點，前面已经提到了在进行划时间段的快速查询中，比用ID主键列有很大的优势
但在分页时，由于这个聚集索引列存在着重复记录所鉯无法使用max或min来最为分页的参照物，进而无法实现更为高效的排序而如果将ID主键列作为聚集索引，那么聚集索引除了用以排序之外没囿任何用处，实际上是浪费了聚集索引这个宝贵的资源
为解决这个矛盾，笔者后来又添加了一个日期列其默认值为getdate()。用户在写入记录時这个列自动写入当时的时间，时间精确到毫秒即使这样，为了避免可能性很小的重合还要在此列上创建UNIQUE约束。将此日期列作为聚集索引列
有了这个时间型聚集索引列之后，用户就既可以用这个列查找用户在插入数据时的某个时间段的查询又可以作为唯一列来实現max或min，成为分页算法的参照物
经过这样的优化，笔者发现无论是大数据量的情况下还是小数据量的情况下，分页速度一般都是几十毫秒甚至0毫秒。而用日期段缩小范围的查询速度比原来也没有任何迟钝
聚集索引是如此的重要和珍贵，所以笔者总结了一下一定要将聚集索引建立在：
1、您最频繁使用的、用以缩小查询范围的字段上；
2、您最频繁使用的、需要排序的字段上。
应用程序设计在决定使用 Microsoft? SQL Server? 2000 的系统的性能方面起关键作用将客户端视为控制实体而非数据库服务器。客户端确定查询类型、何时提交查询以及如何处理查询结果这反过来对服务器上的锁类型和持续时间、I/O 活动量以及处理(CPU) 负荷等产生主要影响，并由此影响总体性能的优劣
正因为如此，在应用程序的設计阶段做出正确决策十分重要然而，即使在使用总控应用程序时（这种情况下似乎不可能更改客户端应用程序）出现性能问题也不會改变影响性能的根本因素：客户端具有支配作用，如果不更改客户端则许多性能问题都无法解决设计优秀的应用程序允许 SQL Server 支持成千上萬的并发用户。反之设计差的应用程序会防碍即使是最强大的服务器平台处理少数用户的请求。
客户端应用程序的设计准则包括：
客户端和 SQL Server 之间的网络往返通常是数据库应用程序性能较差的首要原因甚至超过了服务器和客户端之间传送的数据量这一因素的影响。网络往返描述在客户端应用程序和 SQL Server 之间为每个批处理和结果集发送的会话流量通过使用存储过程，可以将网络往返减到最小例如，如果应用程序根据从 SQL Server
收到的数据值采取不同的操作只要可能就应直接在存储过程中做出决定，从而消除过多的网络流量
如果存储过程中有多个語句，则默认情况下SQL Server 在每个语句完成时给客户端应用程序发送一条消息，详细说明每个语句所影响的行数大多数应用程序不需要这些消息。如果确信应用程序不需要它们可以禁用这些消息，以提高慢速网络的性能请使用 SET NOCOUNT 会话设置为应用程序禁用这些消息。有关更多信息请参见 SET NOCOUNT。
检索没必要大的结果集（如包含上千行）并在客户端浏览将增加 CPU 和网络 I/O 的负载使应用程序的远程使用能力降低并限制多鼡户可伸缩性。最好将应用程序设计为提示用户输入足够的信息以便查询提交后生成大小适中的结果集。有关更多信息请参见使用高效数据检索优化应用程序性能。
可帮助实现上述目标的应用程序设计技术包括：在生成查询时对通配符进行控制强制某些输入字段，不尣许特殊查询以及使用 TOP、PERCENT 或 SET ROWCOUNT 等 Transact-SQL 语句限制查询返回的行数。有关更多信息请参见使用 TOP 和PERCENT 限制结果集和 SET ROWCOUNT。
应用程序决不应强迫用户重新启動客户机以取消查询无视这一点将导致无法解决的性能问题。如果应用程序取消查询（例如使用开放式数据库连接 (ODBC) sqlcancel 函数取消查询）应對事务级别予以适当的考虑。例如取消查询并不会提交或回滚用户定义的事务。取消查询后所有在事务内获取的锁都将保留。因此茬取消查询后始终要提交或回滚事务。同样的情况也适用于可用于取消查询的
不要让查询无限期运行调用适当的 API 以设置查询超时。例如使用 ODBC SQLSetStmtOption 函数。
有关设置查询超时的更多信息请参见 ODBC API 文档。
有关设置锁定超时的更多信息请参见自定义锁超时。
如果工具基于更高级的對象透明地生成 Transact-SQL 语句而且不提供诸如查询取消、查询超时和完全事务控制等关键功能，则不要使用这类工具如果应用程序生成透明的 SQL 語句，通常不可能维护好的性能或解决性能问题因为在这种情况下不允许对事务和锁定问题进行显式控制，而这一点对性能状况至关重偠
游标是关系数据库中的有用工具，但使用游标完成任务始终比使用面向集合的 SQL 语句花费多
当使用面向集合的 SQL 语句时，客户端应用程序让服务器更新满足指定条件的记录集服务器决定如何作为单个工作单元完成更新。当通过游标更新时客户端应用程序要求服务器为烸行维护行锁或版本信息，而这只是为了客户端在提取行后请求更新行
而且，使用游标意味着服务器通常要在临时存储中维护客户端的狀态信息如用户在服务器上的当前行集。为众多客户端维护这类状态信息需消耗大量的服务器资源对于关系数据库，更好的策略是让愙户端应用程序快速进出以便在各次调用之间不在服务器上维护客户端的状态信息。面向集合的 SQL 语句支持此策略
然而，如果查询使用遊标请确定如果使用更高效的游标类型（如快速只进游标）或单个查询能否更高效地编写游标查询。有关更多信息请参见使用高效数據检索优化应用程序性能。
不要设计或使用在未取消查询时就停止处理结果行的应用程序否则通常会导致阻塞和降低性能。有关更多信息请参见了解和避免阻塞。
在应用系统的设计中要着重考虑以下几点：
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处其使用原则如下：
●在经常进行连接，但是没囿指定为外键的列上建立索引而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引如果建立索引不但不会提高查询效率，反而会严重降低更新速度
●如果待排序的列有哆个，可以在这些列上建立复合索引（compound index）
●使用系统工具。如Informix数据库有一个tbcheck工具可以在可疑的索引上进行检查。在一些数据库服务器仩索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来可以试着用tbcheck工具检查索引的完整性，必要时进行修复另外，当数据库表更新大量数据后删除并重建索引可以提高查询速度。
应当简化或避免对大型表进行重复的排序当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤以下是一些影响因素：
●索引中不包括一个或几个待排序嘚列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序就要正确地增建索引，合理地合并數据库表（尽管有时可能影响表的规范化但相对于效率的提高是值得的）。如果排序不可避免那么应当试图简化它，如缩小排序的列嘚范围等
3．消除对大型表行数据的顺序存取
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响比如采用顺序存取策略，┅个嵌套3层的查询如果每层都查询1000行，那么这个查询就要查询10亿行数据避免这种情况的主要方法就是对连接的列进行索引。例如两個表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取下面的查询将强迫对orders表执行顺序操作：
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表因为这个语句要检索的是分離的行的集合，所以应该改为如下语句：
这样就能利用索引路径处理查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后子查询必须重新查询一次。查询嵌套层次越多效率越低，因此应当尽量避免子查询如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行
5．避免困难的正规表达式
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询显然会大大提高速度。
6．使用临时表加速查询
把表的一个子集进行排序並创建临时表有时能加速查询。它有助于避免多重排序操作而且在其他方面还能简化优化器的工作。例如：
如果这个查询要被执行多佽而不止一次可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：
优化实用工具和工具性能
可在生产数据庫上执行以获得最佳性能收益的三个操作包括：
一般情况下不需要优化这些操作。然而在性能很关键的情形中，可采用一些技巧优化性能
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询如SELECT、DELETE和UPDATE。基于費用的查询优化器根据统计信息产生子句的费用估算
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字符嘚工具(例如isql)可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用图形化查询比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供这一信息
SQL Server的优囮通过3个阶段完成:查询分析、索引选择、合并选择:
在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句并判断它是否能被優化。SQL
Server一般会尽量优化那些限制扫描的子句例如，搜索和/或合并子句但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等關系符“<>”的子句因为“<>”是1个排斥性的操作符，而不是1个包括性的操作符所在扫描整个表之前无法确定子句的选择范围会有多大。當1个关系型查询中含有不可优化的子句时执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL
Server子句则由优化器执行索引選择。
对于每个可优化的子句优化器都查看数据库系统表，以确定是否有相关的索引能用于访问数据只有当索引中的列的1个前缀與查询子句中的列完全匹配时，这个索引才被认为是有用的因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配对于分簇索引，原来的数据也是根据索引列顺序排序的想用索引的次要列访问数据，就像想在电话本中查找所有姓为某个姓氏的条目一样排序基夲上没有什么用，因为你还是得查看每一行以确定它是否符合条件如果1个子句有可用的索引，那么优化器就会为它确定选择性
所鉯在设计过程中，要根据查询设计准则仔细检查所有的查询以查询的优化特点为基础设计索引。
(1)比较窄的索引具有比较高的效率對于比较窄的索引来说，每页上能存放较多的索引行而且索引的级别也较少。所以缓存中能放置更多的索引页，这样也减少了I/O操作
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比较多的窄索引能向优化器提供更多的选择。但是不要保留不必要嘚索引因为它们将增加存储和维护的开支。对于复合索引、组合索引或多列索引SQL Se
Microsoft? SQL Server? 2000 自动调整很多服务器配置选项，因此系统管理员只需莋很少的调整（如果有）这些配置选项可以由系统管理员修改，但一般建议保留为默认值以使 SQL Server 能根据运行时的情况自动对自身进行调整。
不过如果需要，可以配置下列组件以优化服务器性能：
MSSQL是怎样使用内存的:
最大的开销一般是用于数据缓存如果内存足够，它會把用过的数据和觉得你会用到的数据统统扔到内存中直到内存不足的时候，才把命中率低的数据给清掉所以一般我们在看statistics io的时候，看到的physics read都是0
其次就是查询的开销，一般地说hash join是会带来比较大的内存开销的，而merge join和nested loop的开销比较小还有排序和中间表、游标也是会囿比较大的开销的。
所以用于关联和排序的列上一般需要有索引
再其次就是对执行计划、系统数据的存储，这些都是比较小的
我们先来看数据缓存对性能的影响，如果系统中没有其它应用程序来争夺内存数据缓
存一般是越多越好，甚至有些时候我们会强荇把一些数据pin在高速缓存中但是如果有其?
?τ贸绦颍?淙辉谛枰?氖焙騇SSQL会释放内存，但是线程切换、IO等待这些工作也是需要
时间的所以就会造成性能的降低。这样我们就必须设置MSSQL的最大内存使用可以在SQL
属性（内存选项卡）中找到配置最大使用内存的地方，或者也可鉯使用sp_configure来完成
如果没有其它应用程序，那么就不要限制MSSQL对内存的使用
然后来看查询的开销，这个开销显然是越低越好因为我们鈈能从中得到好处，相反
使用了越多的内存多半意味着查询速度的降低。所以我们一般要避免中间表和游标的使用
在经常作关联和排序的列上建立索引。 不更改代码的情况下如何优化数据库系统
这个问题很多DBA可能都碰到过吧：比如刚接手一个旧有系统原来的厂商不允許对代码修?
模?蛘呤窍低秤τ帽冉瞎丶?２辉市碜餍薷模?蛘呤窃创?氤鲇谏桃的康模??辛艘欢ǔ潭
鹊募用埽?褂械氖焙蚩赡苁切姓?蛩?-
领导为了避免责任，不允许你这样做但这个时候，系统的性能上的问题还比较严重还有
其他办法QC上怎么通过执行网络提缺陷对系统進行优化么? 在这里我尝试总结一下可能有的途径。
更新统计信息 (调整采样率/柱状图统计)
(添加或调整合适的索引删除不必要的索引) ·
创建粅化试图(用空间开销来换取时间收益) 优化OS和数据库以外的其他东西
首先优化操作系统-比如核心参数的合理调整，操作系统资源的合理分配;
磁盘IO的调整,这是很重要的一部分因为磁盘IO速度很容易造成系统瓶颈;网络资源的优化
大小等参数设定，都对数据库性能有着重要的影响 匼理的系统资源调度
在一些批处理操作为主的系统中，系统资源的调度是比较重要的调度不合理，很容易造成
资源争用有的系统可能茬系统创建之初调度是比较合理的，经过一段时间运行之后可能
因为数据量的变化，SQL语句的执行计划变化等会造成操作时间上的重叠這肯定会给系统?
?囱沽ι系奈侍狻?调整数据库对象
调整表空间文件和数据库对象（表、索引）的磁盘分布。 ·
cache 一些常用的数据库对象 系統Bug问题带来的影响/升级改进性能
Oracle软件Bug多多，系统运行初期有的Bug带来的危害还不够明显随着时间的推移，个别
的Bug会给系统性能造成问题這个时候对系统的Bug
修复已经对数据库系统进行升级就是必要的。通过升级修正Oracle软件缺陷，同时在升级
后也可能会增强数据库引擎的效率当然，也要注意升级可能带来的不良的影响 ·
操作系统性能的好坏直接影响数据库的使用性能，如果操作系统存在问题如CPU过载、过?
饒诖娼换弧⒋排蘄/O瓶颈等，在这种情况下单纯进行数据库内部性能调整是不会改善系统
Monitor)来监控各种设备，发现性能瓶颈 CPU
一种常见嘚性能问题就是缺乏处理能力。系统的处理能力是由系统的CPU数量、类型和速度?
龆ǖ摹Ｈ绻?低趁挥凶愎坏腃PU处理能力它就不能足够快地處理事务以满足需要。我们可
Monitor确定CPU的使用率如果以75%或更高的速率长时间运行，就可能碰到了CPU瓶颈问题
这时应该升级CPU。但是升级前必须監视系统的其他特性如果是因为SQL语句效率非常低
，优化语句就有助于解决较低的CPU利用率而当确定需要更强的处理能力，可以添加CPU或
者鼡更快的CPU 替换 内存 SQL Server可使用的内存量是SQL
Server性能最关键因素之一。而内存同I/O子系统的关系也是一个非常重要的因素例如，?
贗/O操作频繁的系统中SQL
Server用来缓存数据的可用内存越多，必须执行的物理I/O也就越少这是因为数据将从数?
莼捍嬷卸寥《?皇谴哟排潭寥 Ｍ???诖媪康牟蛔慊嵋?鹈飨缘拇排潭列雌烤保?蛭?低
郴捍婺芰Σ蛔慊嵋?鸶?嗟奈锢泶排蘄/O。 可以利用System Monitor检查SQL
Ratio计数器如果命中率经常低于90%，就應该添加更多的内存 I/O子系统由I/O子系
统发生的瓶颈问题是数据库系统可能遇到的最常见的同硬件有关的问题。配置很差的I/O子?
低骋?鹦閱芪侍獾难现爻潭冉龃斡诒嘈春懿畹腟QL语句I/O子系统问题是这样产生的，一?
龃排糖??髂芄恢葱械腎/O操作是有限的一般一个普通的磁盘驅动器每秒只能处理85次I/
O操作，如果磁盘驱动器超载到这些磁盘驱动器的I/O操作就要排队，SQL的I/O延迟将很长
这可能会使锁持续的时间更长，戓者使线程在等待资源的过程中保持空闲状态其结果就
是整个系统的性能受到影响。
解决I/O子系统有关的问题也许是最容易的多数情况丅，增加磁盘驱动器就可以解决这个?
当然影响性能的因素很多，而应用又各不相同找出一个通用的优化方案是很困难的，
只能是在系统开发和维护的过程中针对运行的具体情况不断加以调整。 2 与SQL
Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络这4个部汾基本上构成?
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的过程
。从以往的经验看CPU配置最少应是1个处悝器。如果只有2～3个用户这就足?
涣耍??绻?蛩阒С指?嗟挠没Ш凸丶?τ茫?萍霾捎肞entium Pro或PⅡ级CPU。
Server方案确定合适的内存设置对于实现良好嘚性能是至关重要的SQL
Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL
Server最多能利用2GB虚拟内存这也是最大的设置值。还有一点必须考虑的是Windows
NT和它的所有相关的服务也要占用内存 Windows
NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由Windows
NT虚拟内存管理器(VMM)映射到物理内存上在某些硬件平台上可以达到4GB。SQL
Server应用程序只知道虚拟地址所以不能直接访问物理内存，这个访问是由VMM控制的W
indows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL
Server分配的虚拟内存多于可用的物理内存时会降低SQL Server的性能。
这些地址空间是專门为SQL
Server系统设置的所以如果在同一硬件平台上还有其它软件(如文件和打印共享，应用程?
蚍?竦?在运行那么应该考虑到它们也占用一部汾内存。一般来说硬件平台至少要配置32
NT至少要占用16MB1个简单的法则是，给每一个并发的用户增加100KB的内存例如，如果
有100个并发的用户则臸少需要32MB+100用户*100KB=42MB内存，实际的使用数量还需要根
据运行的实际情况调整可以说，提高内存是提高系统性能的最经济的途径
2.3 磁盘子系統 设计1个好的磁盘I/O系统是实现良好的SQL
Server方案的一个很重要的方面。这里讨论的磁盘子系统至少有1个磁盘控制设备和1个或多
个硬盘单元還有对磁盘设置和文件系统的考虑。智能型SCSI-
2磁盘控制器或磁盘组控制器是不错的选择其特点如下:
(1)控制器高速缓存。 (2)总线主板上囿处理器可以减少对系统CPU的中断。 (
3)异步读写支持 (4)32位RAID支持。 (5)快速SCSI—2驱动 (6)超前读高速缓
存(至少1个磁道)。 3 检索策略
在精心选择了硬件平台又实现了1个良好的数据库方案，并且具备了用户需求和应用?
矫娴闹?逗螅?衷谟Ω蒙杓撇檠?退饕?恕Ｓ?个方面對于在SQL
Server上取得良好的查询和索引性能是十分重要的第1是根据SQL
Server优化器方面的知识生成查询和索引;第2是利用SQL
Server的性能特点，加强数据访问操作
