TechEd2012 SQL Server 性能调优 -如何定位和解决系统瓶颈
SQL Server 性能调优——如何定位和解决系统瓶颈
课程安排
?SQL Server性能优化概念?CPU性能瓶颈分析
?内存性能瓶颈分析
?磁盘性能瓶颈分析
性能优化介绍?什么是性能问题？
?性能的定义
–基线（Baseline）
–开销
–优化
影响性能的因素?应用程序
?查询语句
?事务管理
?数据库设计
?数据分布
?SQL Server本身
?网络
?操作系统
?硬件
CPU性能瓶颈分析
?CPU性能瓶颈的特征
?常见问题及解决方法
问题特征
?何时查看
–计数器Processor:%Processor 一直高于80%
?查看内容：
–SQL Server的计数器Process:%Processor Time值是否很高?解决方法
–找到谁在消耗CPU，并对其进行优化
–增加更多的CPU
常见的原因
?过度的编译/重编译
?低效的查询执行计划
?语句内的并行执行
?游标的不合理使用
过度编译/重编译?编译和重编译
–重编译：在SQL Server执行一个查询之前，它会查看当前执行计划的准确性和有效性，如果
检查失败，就需要编译或者重编译
–消耗较多的CPU
检测
?性能监视器
–SQL Recompilations/sec对Batch Requests/Sec的比率较高?Trace
–SP: Recompile
–RPC: Completed
–Auto Stats
原因和解决方案?SET语句
–在连接建立时运行SET语句
?统计信息变化
–指定KEEPFIXED PLAN查询提示
?不明确的对象名称
–使用明确的对象名称
?HINT提示
–去掉 WITH RECOMPILE
低效的执行计划
?背景知识
–SQL Server 优化器试图找到响应时间最快的执行计划
–由于某些原因，例如索引缺失、统计数据过期，这个执行计划实际上并不一定是最快的
–这个次优执行计划的某些因素(表扫描/索引扫描等)可能会使CPU使用率变高
?检测
–Trace, DMVs, T-SQL 语句
原因和解决方案?过时的统计信息
–UPDATE STATISTICS
?索引缺失
–使用数据库引擎优化顾问(DTA)
?代码质量
–修改查询语句
?错误索引
–查询提示(hint), 执行计划向导(plan guide )
并行查询
?背景知识
–查询优化器会选择最快的计划.
–如果查询的开销 > 并行的开销阈值 (默认为5 秒), 查询将会并行执行
–在大多数情况下，并行能够加强查询的性能
–然而，一个给定查询的响应时间必须从整个系统的吞吐量和系统上的其他查询出发来综合考虑
检测
?sys.sysprocesses (Blocker script) –一个SPID对应多条记录
–Wait type: CXPACKET
解决方案
?MAXDOP
–服务器级别及语句级别
?分析缺失的索引
?修改查询
游标的不合理使用?背景知识
–早期版本每个连接只允许一个命令
–当一条命令需要在刚刚读到的行的基础上运行，用户就需要服务器端的游标
–sp_cursorfetch 控制服务器端返回给客户端的行数，这使得ODBC或OLEDB驱动能高速缓存行.
检测
?PerfMon
–SQL Server: Cursor Manager by Type: Cursor Requests/Sec
?Trace
–RPC: Completed, 查找sp_cursorfetch
解决方案
?避免服务器端游标
?使用MARS
?使用更大的fetch缓冲区大小
内存性能瓶颈分析
?SQL Server如何使用内存
?如何识别内存性能瓶颈
SQL Server如何使用内存
?虚拟地址空间和物理内存
?动态内存管理
?AWE 和 Locked Pages
大数据库优化(SQLServer)
SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三
浅谈优化SQLServer数据库服务器内存配置的策略
浅谈优化SQLServer数据库服务器内存配置的策略 浅谈优化SQLServer数据库服务器内存配置的策略 作者：季广胜 言 农业银行总行1998年以来正式推广了新版网络版综合业务统计信息系统，该系统是基于WindowsNT4.0平台，采用客户／服务器模式，以Microsoft SQL Server为基础建立起来的大型数据库应用程序，系统界面友好、操作简便，计算、分析、检索功能非常强大，为保证农业银行系统及时进行纵向和横向业务数据采集、按照不同要求生成统计报表，进行全面业务活动分析提供了强有力的保障。但在这套程序的推广、维护中笔者发现系统有时运行速度较慢，特别是在Win95客户端操作时尤为严重，经过排除网线连接等硬件可能带来的影响后上述问题仍然存在。笔者经过仔细摸索，发现系统对硬、软件的要求较高，为充分发挥设计效能，达到最佳运作效果，需要对计算机硬、软件系统进行较为完备的性能测试与最佳配置，特别是内存配置的好坏对系统的运行速度具有决定性的作用。下面，笔者就如何优化SQLServer数据库服务器的内存配置提出一些认识和看法。 一、有关内存的基本概念 1 物理内存与虚拟内存 WindowsNT使用两类内存：物理内存与虚拟内存。
物理内存：作为RAM芯片安装在计算机内部的存储器。 虚拟内存：用于模拟RAM芯片功能的磁盘(硬盘)空间，其实质是通过将内存中当前没有使用的部分内容临时存储到磁盘上，使系统可以使用到比机器物理内存更多的内存。 2 分页和分页文件 WindowsNT系统通过使用磁盘空间使得对内存的需求得到部分缓解，从而使用到比物理内存更多内存的技术就称为“交换”或分页，也就是通常所说的虚拟内存技术。通常Windows NT 4.0系统安装时将在引导驱动器上设置一个大小为16MB的交换(分页)文件(pagefile.sys)。 二、优化Windows NT 4.0系统内存配置 在大多数情况下，为了充分发挥Windows NT 4.0系统效能，内存的作用比起处理器的处理能力更具有影响力，特别是在客户／服务器模式环境下更是如此，因为通常在这种环境下并不十分强调处理器的能力，相反却十分注重是否采用足够的内存来满足各个客户的应用需要。此外，为了获得容错功能和保护应用程序，保证应用程序高速运行、充分发挥设计功能都需要有足够多的内存，特别是工业绘图设计和各种工程应用程序更需要占用大量的内存来进行复杂的计算。 物理内存(RAM)方便快速的优点显而易见，但由于其价格昂贵，也就不可能做到多多益善了，因此通过合理优化内存配置、扩充虚拟
SQLServer语句优化
SQLServer语句优化 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 下面的表总结了何时使用聚集索引或非聚集索引（很重要）： 动作描述使用聚集索引使用非聚集索引 列经常被分组排序应应 返回某范围内的数据应不应 一个或极少不同值不应不应 小数目的不同值应不应 大数目的不同值不应应 频繁更新的列不应应 外键列应应 主键列应应 频繁修改索引列不应应 事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。 结合实际，谈索引使用的误区 理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。 1、主键就是聚集索引 这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。 通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。 显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。 从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会
SQLserver数据库优化
SQLserver数据库优化 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建 查询速度慢的原因很多，常见如下几种： 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 可以通过如下方法来优化查询: 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb 应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟
内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5 倍。如果另外安装了全文检索功能，并打算运行Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将SQL Server max server memory 服务器配置选项配置为物理内存的1.5 倍（虚拟内存大小设置的一半）。 7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert，Delete还不能并行处理。 8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。like 'a%' 使用索引like '%a' 不使用索引用like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是V ARCHAR。对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离；OLTP和OLAP分离 10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件'分区视图'） a、在实现分区视图之前，必须先水平分区表 b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。 11、重建索引DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的： 1、查询语句的词法、语法检查 2、将语句提交给DBMS的查询优化器 3、优化器做代数优化和存取路径的优化 4、由预编译模块生成查询规划 5、然后在合适的时间提交给系统处理执行
MS_SQL_Server_数据库性能优化方法总结
1.列出数据库服务器、Web服务器的基本的硬件配置，如CPU、内存等。 2.检查数据库服务器是否真正启用了AWE内存。 (1) 启用AWE：数据库服务器检查C:\boot.ini文件,需要配置"/PAE"(*重启电脑才能生效),如下： [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /PAE (2) 开启sql server 服务用户的，内存中锁定页面权限 (*重启电脑才能生效)在“服务管理”中查看 SQL SERVER 服务登录账户，默认是本地系统帐户（System）。然后在运行 gpedit.msc ，选择计算机配置->windows 设置->安全设置->本地策略->用户权限分配->内存中锁定页面。添加SQL SERVER服务的登录用户到里面去。 (3)启用数据库AWE内存，以服务器8G内存为例，一般设置如下，最小2G，最大6G(重启SQL SERVER服务即可)： (4)跟踪数据库性能“Total Server Memory ”的使用情况，看看数据库真正使 用的内存，越接近为数据库分配的最大内存越好。 或使用如下语句，查询数据库的内存使用情况： use master go select * from sysperfinfo where counter_name like '%Total Server Memory(KB)%' go 3.Web服务器监控项：
SqlserverSQL性能优化经验
Sqlserver SQL性能优化经验 1.选择最有效率的表名顺序(只在基于规则的优化器中有效) SQLSERVER的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表（基础表driving table）将被最先处理，在FROM子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，当SQLSERVER处理多个表时，会运用排序及合并的方式连接它们， 首先，扫描第一个表（FROM子句中最后的那个表)并对记录进行排序；然后扫描第二个表（FROM子句中最后第二个表)；最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并 例如: 表TAB1 16,384 条记录表TAB2 5 条记录，选择TAB2作为基础表(最好的方法) select count(*) from tab1,tab2 执行时间0.96秒，选择TAB2作为基础表(不佳的方法) select count(*) from tab2,tab1 执行时间26.09秒； 如果有3个以上的表连接查询，那就需要选择交叉表（intersection table）作为基础表，交叉表是指那个被其他表所引用的表 例如: EMP表描述了LOCATION表和CATEGORY表的交集 SELECT * FROM LOCATION L, CATEGORY C, EMP E WHERE E.EMP_NO BETWEEN 1000 AND 2000 AND E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN 将比下列SQL更有效率 SELECT * FROM EMP E , LOCATION L , CATEGORY C WHERE E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN AND E.EMP_NO BETWEEN 1000 AND 2000
Sqlserver查询性能分析
Sqlserver查询性能分析（执行结果分析） 1、方法 在查询窗口中输入以下命令 dbcc dropcleanbuffers --注释：清除数据 dbcc freeproccache --注释：清除缓存 这是为了每次查询时，不会因为重复查询对结果有干扰，接着在窗口中输入以下命令。 Set statistics io on --注释：开启系统资源使用统计 Set statistics time on --注释：开启执行时间统计 然后在窗口中输入查询命令 如：SELECT TOP 1000000 * FROM [SearchInfo] 在消息框中就会出现如下结果 SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. (999999 row(s) affected) Table 'SearchInfo'. Scan count 1, logical reads 17890, physical reads 29, read-ahead reads 17309, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. SQL Server Execution Times: CPU time = 2153 ms, elapsed time = 22354 ms. 2、参数 SQL Server parse and compile time 这是指sql server解析语句的时间。(999999 row(s) affected)查询到的数据量，这个你知道咯，只要你的目的是明确的，那么查询到的数据量应该是不变的，如果改变，那么你的逻辑是不一致的对不对！ Table 'SearchInfo'. Scan count 1, logical reads 17890, physical reads 29, read-ahead reads 17309, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 这一串表示什么呢， 表示数据表'SearchInfo'，扫描1次（Scan count）在逻辑区读取了17890次（logical reads）在物理区读取了29次（physical reads）提前读取17309次（read-ahead reads）lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 100万条数据全都是0，你懂的，忽略它吧 那这串数据中没被忽略的哪些有用呢，表的扫描次数Scan count有用的，查询次数的多少表示这个资源你用了多少次，逻辑区读取次数非常有用，我们知道，SQL Server在可以对任何数据进行操作前，必须首先把数据读取到其数据缓冲区中。此外，我们也知道SQL Server 何时会从数据缓冲区中读取数据，并把数据读取到大小为8K字节的页中。Logical Reads是指SQL Server为得到查询中的结果而必须从数据缓冲区读取的页数。在执行查询时，SQL Server不会读取比实际需求多或少的数据，因此，当在相同的数据集上执行同一个查询，得到的Logical Reads的数字总是相同的。 物理区读取咱忽略它吧，为什么呀？ SQL Server在执行查询时所需要的物理区读取次数不可能通过性能调节而减少的。减少物理读的次数是DBA的一项重要工作，但它涉及到整个服务器性能的调节，而不仅仅是查询性能的调节。在进行查询性能调节时，我们不能控制数据缓冲区的大小或服务器的忙碌程
SqlServer性能优化基础
一、优化基础 本文主要向大家介绍的是正确优化SQL Server数据库的经验总结，其中包括在对其进行优化的实际操作中值得大家注意的地方描述，以及对SQL语句进行优化的最基本原则，以下就是文章的主要内容描述。 优化数据库的注意事项： 1、关键字段建立索引。 2、使用存储过程，它使SQL变得更加灵活和高效。 3、备份数据库和清除垃圾数据。 4、SQL语句语法的优化。(可以用Sybase的SQL Expert，可惜我没找到unexpired的序列号) 5、清理删除日志。 SQL语句优化的基本原则： 1、使用索引来更快地遍历表。 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。 一般来说： ①.有大量重复值、且经常有范围查询(between, >,< ，>=,< =)和order by、group by发生的列，可考虑建立群集索引 ②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引; ③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。 2、IS NULL 与IS NOT NULL 不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null 的语句优化器是不允许使用索引的。 3、IN和EXISTS EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎将所有的IN 操作符子查询改写为使用EXISTS的子查询。 4、在海量查询时尽量少用格式转换。 5、当在SQL SERVER 2000中 如果存储过程只有一个参数，并且是OUTPUT类型的，必须在调用这个存储过程的时候给这个参数一个初始的值，否则会出现调用错误。 6、ORDER BY和GROPU BY 使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。注意如果索引列里面有NULL值，Optimizer将无法优化。 7、任何对列的操作都将导致表扫描，它包括SQL Server数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
SQLServer数据查询的优化方法
ＳＱＬＳｅｒｖｅｒ数据查询的优化方法聂文燕 摘要：SQLServer是一种功能强大的数据库管理系统，许多数据库应用系统都是以它作为后台数据库。本文在分析影响SQLSERVER数据查询效率的因素的基础上，提出了几种优化数据查询的方法。 关键词：SQLServer，数据，查询，优化 一、引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统，它是一个全面的、集成的、端到端的数据解决方案，为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前，许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难，但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践，由于初期的数据库中表的记录数比较少，性能不会有太大问题，但数据积累到一定程度，达到数百万甚至上千万条，全面扫描一次往往需要数十分钟，甚至数小时。20％的代码用去了80％的时间，这是程序设计中的一个著名定律，在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟。而且我们知道，目前数据库系统应用中，查询操作占了绝大多数，查询优化成为数据库性能优化最为重要的手段之一。 二、影响查询效率的因素 SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种：1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。 2．没有创建计算列导致查询不优化。 3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。 4．返回了不必要的行和列。 5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 三、SQLServer数据查询优化方法 3.1建立合适的索引索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。当根据索引码的值搜索数据时，索引提供了对数据的快速访问。事实上，没有索引,数据库也能根据SELECT语句成功地检索到结果，但随着表变得越来越大，使用“适当”的索引的效果就越来越明显。索引的使用要恰到好处，其使用原则有： (1)对于基本表，不宜建立过多的索引； (2)对于那些查询频度高，实时性要求高的数据一定要建立索引，而对于其他的数据不考虑建立索引； (3)在经常进行连接，但是没有指定为外键的列上建立索引； (4)在频繁进行排序或分组（即进行groupby或orderby操作）的列上建立索引；
改善SQLServer数据库查询速度慢的技巧.
改善SQL Server数据库查询速度慢的技巧 SQL Server数据库是一个关系数据库管理系统,功能强大,但有时候会出现数据库查询速度慢的问题,那么如何解决SQL Server数据库查询速度慢?下文将给出答案。 SQL Server数据库查询速度慢的原因有很多,常见的有以下几种: 1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷 2、I/O吞吐量小,形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量 7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好,没有优化 可以通过以下方法来优化查询 : 1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb 应放在RAID0上,SQL2000不在支持。数据量(尺寸越大,提高I/O越重要。 2、纵向、横向分割表,减少表的尺寸(sp_spaceuse 3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0。索引应该尽量小,使用字节数小的列建索引好(参照索引的创建,不要对有限的几个值的字段建单一索引如性别字段。 5、提高网速。 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。 配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配置。运行Microsoft SQL Server? 2000时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5倍。如果另外安装了全文检索功能,并打算运行Microsoft 搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。将SQL Server max server memory服务器配置选项配置为物理内存的1.5倍(虚拟内存大小设置的一半。 7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务,就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行,SQL SERVER根据系统的负载情况决定最优的并行等级,复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE,INSERT, DELETE还不能并行处理。 8、如果是使用like进行查询的话,简单的使用index是不行的,但是全文索引,耗空间。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查询时,查询耗时和字段值总长度成正比,所以不能用CHAR类型,而是VARCHAR。对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离;OLTP和OLAP分离 10、分布式分区视图可用于实现数据库服务器联合体。
SQLServer性能优化工具
SQLServer性能优化工具 数据和工作负荷示例 使用下例说明 SQL Server 性能工具的使用。首先创建下表。 create table testtable (nkey1 int identity, col2 char(300) default 'abc', ckey1 char(1)) 接下来，在这个表中填充 10,000 行测试数据。可以为列 nkey1 中所填充的数据创建非聚集索引。可以为列 ckey1 中的数据创建聚集索引，col2 中的数据仅仅是填充内容，将每一行增加 300 字节。 declare @counter int set @counter = 1 while (@counter <= 2000) begin insert testtable (ckey1) values ('a') insert testtable (ckey1) values ('b') insert testtable (ckey1) values ('c')
insert testtable (ckey1) values ('d') insert testtable (ckey1) values ('e') set @counter = @counter + 1 end 数据库服务器将进行下面的两个查询： select ckey1,col2 from testtable where ckey1 = 'a' select nkey1,col2 from testtable where nkey1 = 5000 Profiler SQL Server Profiler 记录数据库服务器中所发生活动的详细信息。可以配置 Profiler 以便用大量的可配置性能信息监视并记录在 SQL Server 中执行查询的一个或多个用户。可在 Profiler 中记录的性能信息有：I/O 统计信息、CPU 统计信息、锁定请求、T-SQL 和 RPC 统计信息、索引和表扫描、警告和引发的错误、数据库对象的创建/除去、连接/断开、存储过程操作、游标操作等等。有关 SQL Profiler 可记录的全部信息，请在SQL Server Books Online 中搜索字符串“Profiler”。 将 Profiler 信息装载到 .trc 文件中以便用于 Index Tuning Wizard 中 Profiler 和 Index Tuning Wizard 是强大的工具组合，以帮助数
SqlServer数据库优化方案
第一部分SQL SERVER数据库优化方案 微软公司的SQL SERVER 是一个功能完备的数据库管理系统，它提供了完整的关系数据库创建、开发和管理功能。现社会信息技术的快速发展，对数据库技术的要求也越来越高，SQL SERVER数据库在信息化的过程中得到了广泛的应用。 第一章数据库系统概述 从20世纪60年代开始到现在，数据库技术经过了30多年的发展。在这30多年的历程中，在数据库技术的理论研究和系统开发上取得了辉煌的成就，确立了数据技术在现代计算机系统中不可或缺的地位。成为现代信息科学与技术的重要组成部分以及计算机数据处理和信息管理系统的核心。 1．1 基本概念 与数据库技术密切相关的基本概念包括：数据、数据库、数据库管理系统和数据库系统四大概念。 1.数据（Data） 数据是对客观事物的一种描述，是由能被计算机识别与处理的数值、字符等符号构成的集合，即数据是指描述事物的符号记录。 广义地说，数据是一种物理符号的序列，用于记录事物的情况，是对客观事物及其属性进行的一种抽象化及符号化的描述。数据的概念应包括数据的内容和形式两个方面。数据的内容是指所描述的客观事物的具体特性，也就是通常所说的数据的“值”；数据的形式则是指数据内容所存储的具体形式，即数据的“类型”。故此，数据可以用数据类型和值来表示。
2.数据库（Data Base，DB） 数据库是指长期存储在计算机内部、有组织的、可共享的数据集合，即在计算机系统中按一定的数据模型组织、存储和使用的相关联的数据集合成为数据库。 数据库中的数据按照一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性、易扩展性、集中性和共享性，以文件的形式存储在存储介质上的。数据库中的数据由数据库管理系统进行统一管理和控制，用户对数据库进行的各种数据操作都是通过数据库管理系统实现。 3.数据库管理系统（Data Base Management System，DBMS） 数据库管理系统是数据库系统的核心，是为数据库的建立、使用和维护而配置的软件，是位于操作系统与用户之间的一层数据管理软件。主要功能是对数据库进行定义、操作、控制和管理。 1)数据定义 数据的定义包括：定义构成数据库结构的外模式、模式和内模式，定义各个外模式和模式之间的映射，定义模式与内模式之间的映射，定义有关的约束条件。 2)数据处理 对数据的处理操作主要包括对数据库数据的检索、插入、修改和删除等基本操作。 3)安全管理 对数据库的安全管理主要体现在：对数据库进行并发控制、安全性检查、完整性约束条件的检查和执行、数据库的内部维护（如索引、数据字典的自动维护）等。并且能够管理和监督用户的权限，防止拥护有任何破坏或者恶意的企图。 4)数据的组织、存储和管理 负责分类地组织、存储和管理数据库数据，确定以何种文件结构和存取方式物理地组织数
Windows IIS SQLServer性能测试有关计数器监视及相应的分析方法@
有关windows资源计数器：
相应的分析方法： 一、内存 1、查看Available MBytes (memory)。 可用物理内存数。一般要保留10%的可用内存。最低不能<4M，此值过小可能是内存不足或内存泄漏。 2、查看page faults/sec(memory)、pages input/sec(memory)及page reads/sec(memory)。 如果有个程序请求内存中的一页，但系统无法在所需的位置上找到它，就会构成一个分页错误。如果此页位于内存中的其它位置，则此错误便称为软件分页错误。如果必须从磁盘获取此页，则此错误便称为硬件分页错误。大部分的处理器可以处理大量的软件错误而不会引起任何后果。但是，硬件错误却会导致严重的延迟。 「page faults/sec」是指处理器处理错误页 (包括硬件及软件分页错误) 的整体速度。「pages input/sec」是指为了解决硬件分页错误而从磁盘读取的总页数。 「pages reads/sec」是指为了解决硬件分页错误而读取磁盘的次数。 「pages input/sec」会大于或等于「page reads/sec」，并且能够清楚地让您了解硬件分页错误率。如果这些数字都很低，则服务器应该可以快速地响应请求。如果很高，则可能是因为您用了太多的内存在缓存处理上，而没有留足够的内存供系统的其它部份使用。可以增加内存或降低缓存的ram大小来解决。 详细： page Faults/sec:只表明数据不能在内存的指定工作集中立即使用； page Input/sec: page input/sec > page reads/sec; page Reads/sec: 阈值为>5.越小越好,大数值表示磁盘读而不是缓存读； Page/sec：指为解析硬页错误从磁盘读取或写入磁盘的页数(是Pages Input/sec 和 Pages Output/sec 的总和)。其值推荐00-20如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题(太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法)，如果值比较低，说明Web 服务器响应请求比较快，否则可能是服务器系统内存短缺引起（也可能是缓存太大，导致系统内存太少）。 3、查看Pool Nonpaged Bytes（Memory）计数器的值。 Pool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指系统内存(操作系统使用的物理内存)中可供对象(指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。缓慢增长表示存在内存泄漏问题。 二、处理器 1、%processor time（processor）、%user time（processor）、%privileged time（processor）
SqlServer性能检测和优化工具使用详细
工具概要 如果你的数据库应用系统中，存在有大量表，视图，索引，触发器，函数，存储过程，sql语句等等，又性能低下，而苦逼的你又要对其优化，那么你该怎么办？哥教你，首先你要知道问题出在哪里？如果想知道问题出在哪里，并且找到他，咱们可以借助本文中要讲述的性能检测工具--sql server profiler（处在sql安装文件--性能工具--sql server profiler） 如果知道啦问题出现在哪里，如果你又是绝世高手，当然可以直中要害，写段代码给处理解决掉，但是如果你不行，你做不到，那么也无所谓，可以借助哥的力量给你解决问题。哥给你的武功的秘诀心法是---数据库引擎优化顾问（处在sql 安装文件--性能工具--数据库引擎优化顾问） sql server profiler功能 此工具比柯南还柯南，因为他能检测到数据库中的一举一动，即便你不动他，他也在监视你，他很贱的。他不但监视，还监视的很详细，有多详细一会再说，还把监视的内容记录到数据库或者是文件中，给你媳妇告状说你把数据库哪里的性能搞的多么不好，不过他也会把好的给你记录下来，好与不好这当然需要你来分析，其实他也是个很2的柯南。 数据库引擎优化顾问功能 此武功，乃上乘武功。像张无忌的乾坤大挪移，先是接受sql server profiler 检测出来的sql，视图，存储过程，数据结构等等，然后他再自己分析，然后再在怀中转两圈，感觉自己转的差不多啦，就给抛出来个威力更炫，更好的索引，统计，分区等等建议信息。让你承受不住，happly致死。。下面听哥给你先讲讲咱们的很2柯南。 sql server profiler的使用 打开系统主菜单--sqlserver几---性能工具--->>sql server profiler;笨样儿，找到没？哥等你会儿，给你上张打开他后的图，让你看看。。 然后文件--新建跟踪--显示跟踪属性窗口
SQLSERVER数据库的优化
SQLSERVER数据库的优化（论文）提纲 设计概况 (2) 正文 (2) 前言 (2) 第一章问题的分析数据库性能问题通常包括 (2) 1.1锁死 (2) 1.2查询 (3) 第二章 SQLSERVER数据库的优化采取的措施 (3) 2.1分区视图 (3) 2.2数据库维护命令 (3) 2.3存储过程设计 (4) 2.3.1查询条件的问题 (4) 2.3.2存储过程的动态重新编译 (5) 2.3.3用表变量还是临时表 (6) 第三章结束语 (6) 3.1结束语 (6)
设计概况 数据库的设计包括两个组成部分：逻辑设计和物理设计。逻辑数据库设计包括使用数据库组件（如表和约束）为业务需求和数据建模，而无须考虑如何或在哪里物理存储这些数据。物理数据库设计包括将逻辑设计映射到物理媒体上、利用可用的硬件和软件功能使得尽可能快地对数据进行物理访问和维护，还包括生成索引。要在设计后更改这些组件很困难，因此在数据库应用程序开发的早期阶段正确设计数据库、使其为业务需求建模并利用硬件和软件功能很重要。 正文 微软公司开发的SQL Server是基于Windows操作系统的关系型数据库管理系统,它是一个覆盖面广、集成的、端到端的数据解决方案,为企业中的用户提供了一个安全、稳定和效率高的平台用于企业数据管理和商业智能应用。近些年来,由于应用的扩大和深入,数据库性能问题日渐显现出来。 前言 实现SQL Server数据库的优化，首先要有一个好的数据库设计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。实现良好的数据库设计必须考虑这些问题。 第一章问题的分析数据库性能问题通常包括 1.1锁死 即A进程锁住了B，B锁住了C，C又锁住了A，必须人工干预杀进程，或者等待系统自行杀进程。造成死锁最常见的情况是某个数据库表的更新操作会对一系列其他表要进行相应更新操作，这样每次执行时会时间较长，此期间对这些表的查询进程就会被锁，而本进程又在等待其他进程，最后体现出“死锁”。
Sql server优化50法
Sqlserver优化50法 查询速度慢的原因很多，常见如下几种： 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 可以通过如下方法来优化查询 : 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5 倍。如果另外安装了全文检索功能，并打算运行Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍（虚拟内存大小设置的一半）。 7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫
SQLServer性能监控指标说明
性能监控指标说明 --MSSQL SERVER 2005 赵小艳 2010年6月30日
从MSSQL SERVER2005开始，微软开始了漫长的向ORACLE学习之旅，本文以oracle优化为基础，整理了一部分MSSQL SERVER2005监控指标，这些指标不能全部反映MSSQL SERVER2005的性能信息，因此还需要从更多的开发的角度后继完成优化过程，其中最重要的一环是设计。 由于下一步的工作就是实际的优化，请大家指出文档中的不足和错误之处。 本文整理用到的资料：清华大学出版社的《SQL SERVER 2005性能调优》，微软技术资料库，MSDN。
1. 配置硬件 (5) 1.1. 内存 (5) 1.1.1. 物理地址空间 (5) 1.1.2. 虚拟地址空间 (5) 1.1.3. 虚拟内存管理器 (5) 1.1.4. 3GB内存 (5) 1.1.5. PAE (6) 1.1.6. AWE (6) 1.1.7. 选择/3GB 、/PAE、还是/AWE (6) 1.1.8. 64bit系统内存配置 (6) 1.1.9. 内存预计大小 (6) 1.2. I/O (7) 1.2.1. 网络IO (7) 1.2.2. 磁盘IO (7) 1.2.3. 存储设计 (7) 1.2.4. 配置分区 (7) 1.2.5. 扇区对齐 (8) 1.2.6. 卷的类型 (8) 1.2.7. NTFS分配空间的大小 (8) 1.2.8. 磁盘破碎 (8) 1.3. CPU (9) 1.4. 32bit x86处理器 (9) 1.4.1. 多核 (9) 1.4.2. 超线程 (9) 1.4.3. 64bit (9) 1.4.4. X64或IA64 (9) 1.4.5. 高速缓存 (10) 1.5. 系统架构 (10) 1.5.1. SMP (10) 1.5.2. NUMA (10) 1.5.3. SOFT NUMA (10) 2. 系统监控指标 (11) 2.1. 内存 (11) 2.1.1. 外部压力 (11) 2.1.2. 内部内存压力 (11) 2.1.3. 确认内存瓶颈 (11) 2.2. 磁盘 (12) 2.2.1. 基于配置的磁盘瓶颈 (12) 2.2.2. 基于模式的磁盘瓶颈 (12) 2.2.3. 指标 (13) 2.3. Cpu (13)