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、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件'分区视图'）
a、在实现分区视图之前，必须先水平分区表
b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
1、 查询语句的词法、语法检查
2、 将语句提交给DBMS的查询优化器
3、 优化器做代数优化和存取路径的优化
4、 由预编译模块生成查询规划
5、 然后在合适的时间提交给系统处理执行
6、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
12、Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物. 没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) commit trans 或者将动态SQL 写成函数或者存储过程。
13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
14、SQL的注释申明对执行没有任何影响
15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。游标可以按照它所支持的提取选项进行分类： 只进 必须按照从第一行到最后一行的顺序提取行。FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能很强大，他的目的是支持循环。有四个并发选项 READ_ONLY：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。 OPTIMISTIC WITH valueS:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时，没有锁控制其中的行，这将有助于最大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。选择这个并发选项OPTIMISTIC WITH ROW VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有所更改。在 SQL Server 中，这个性能由 timestamp 数据类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值：@@DBTS。每次以任何方式更改带有 timestamp 列的行时，SQL Server 先在时间戳列中存储当前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 个表具有 timestamp 列，则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需比较 timestamp 列即可。如果应用程序对没有 timestamp 列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。 SCROLL LOCKS 这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交或回滚；当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下一行时，锁就被丢弃。因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更新该行。然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的 Select 语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则 COMMIT 语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标 Select 语句中的锁提示。锁提示 只读 乐观数值 乐观行版本控制 锁定无提示 未锁定 未锁定 未锁定 更新 NOLOCK 未锁定 未锁定未锁定 未锁定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 错误 更新 更新 更新 TABLOCKX 错误 未锁定 未锁定更新其它 未锁定 未锁定 未锁定 更新 *指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。
16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在; 用索引优化器优化索引
17、注意UNion和UNion all 的区别。UNION all好
18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的
19、查询时不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。 SET LOCKTIME设置锁的时间
21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "＜＞", "!=", "!＞", "!＜", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因为他们不走索引全是表扫描。也不要在Where字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'（索引扫描），一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"＜＞"等还是不能优化，用不到索引。
23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，我们优化的重点是这些慢的地方。
24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、将需要查询的结果预先计算好放在表中，查询的时候再Select。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。
26、MIN() 和 MAX()能使用到合适的索引。
27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint（约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束）,Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。
28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串（尺寸是它的两倍），服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善
如何解决SQL Server查询速度缓慢的问题
SQL Server查询速度慢的原因有很多，常见的有以下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock,sp_who，活动的用户查看，原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
sql server数据库查询慢怎么优化
在安装有SQLServer数据库的计算机上，我们在使用数据库的过程中，有时候会在任务管理器里发现sqlservr.exe这个进程的内存和CPU占用率较高。
接下来我们来看一下，如何解决上面这个问题，需要设置SQLServer数据库的内存配置。登录数据库，这里使用的是SQLServer2008,右键点击最上方的服务器名，在弹出的菜单中，点击【属性】
打开服务器属性窗口。默认显示的是第一项【常规】内容，点击第二项【内存】进行内存配置。
点击【内存】后，打开服务器内存选项配置界面。这里的【使用AWE分配内存】可以对内存进行扩展支持，我们要做的是更改下方的最大服务器内存。这个数值根据自己服务器内存大小来做适当设置。
5
个人建议设置本机内存的一半或稍微高一点，如机器内存为2G，那么我们这里填写1000。需要注意的是内存设置调小以后，在数据库执行较复杂SQL语句的时候，可能会比较慢，出现这种情况，我们再适当上调最大内存配置大小。
如何做SqlServer 数据查询优化！
影响查询效率的因素
SQLServer处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给SQLServer的查询优化器，查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接，并生成若干执行计划，然后通过分析执行开销来评估每个执行计划，从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。所以，SQLServer中影响查询效率的因素主要有以下几种：
1．没有索引或者没有用到索引。索引是数据库中重要的数据结构，使用索引的目的是避免全表扫描，减少磁盘I/O，以加快查询速度。
2．没有创建计算列导致查询不优化。
3．查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。
4．返回了不必要的行和列。
5．查询语句不好，没有优化。其中包括：查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个 表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。
SQLServer数据查询优化方法
3.1建立合适的索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。当根据索引码的值搜索数据时，索引提供了对数据的快速访问。事实上，没有索引,数据库也能根据SELECT语句成功地检索到结果，但随着表变得越来越大，使用“适当”的索引的效果就越来越明显。索引的使用要恰到好处，其使用原则有：
(1)对于基本表，不宜建立过多的索引；
(2)对于那些查询频度高，实时性要求高的数据一定要建立索引，而对于其他的数据不考虑建立索引；
(3)在经常进行连接，但是没有指定为外键的列上建立索引；
(4)在频繁进行排序或分组（即进行groupby或 orderby操作）的列上建立索引；
(5)在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度；
(6)如果待排序的列有多个，可以在这些列上建立复合索引。 在SQLServer中，索引按索引表达式包含的列分为单列索引和复合索引。检查查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列都是可能的侯选索引，为能达到最优的性能，例如：对于在where子句中给出了 column1这个列，下面的两个条件可以提高索引的优化查询性能！
第一：在表中的column1列上有一个单索引；
第二：在表中有多索引，但是 column1是第一个索引的列。避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能。例如：下面的例子用了pubs数据库。 SELECTau_id,au_lname,au_fname FROMauthorsWHEREau_lname=’White’ 按下面几个列上建立的索引将会是对优化器有用的索引 au_lname au_lname,au_fname 而在下面几个列上建立的索引将不会对优化器起到好的作用 au_address au_fname,au_lname 在SQLServer中，索引按存储结构分为聚簇索引和非聚簇索引。聚簇索引是按照定义数据列值的顺序在物理上对记录排序，在一个表上只能有一个聚簇索引，聚簇索引查询速度较快，但缺点是对表进行修改操作时速度较慢，因为为了保证表中记录的物理顺序与索引的顺序一致，必须将记录插入到数据页的相应位置，从而数据页中的数据必须重排。在下面的几个情况下，可以考虑用聚簇索引：
(1)某列包括的不同值的个数是有限的（但是不是极少的）。如顾客表的州名列有50个左右的不同州名的缩写值，可以使用聚簇索引。
(2)对返回一定范围内值的列可以使用聚簇索引，如用between,>,>=, Select*fromsaleswhereord_datebetween’5/1/93’and’6/1/93’
(3)对查询时返回大量结果的列可以使用聚簇索引。 SELECT*FROMphonebookWHERElast_name=’Smith’ 当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立聚簇索引。如果你建立了聚簇的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。
非聚簇索引指定表中的逻辑顺序，一个表上可以建立多达249个非聚簇索引，它查询的速度比不建立索引快，但比聚簇索引慢，插入数据比聚簇索引快，因为纪录直接被追加到数据末尾。可以在以下情况下考虑使用非聚簇索引。
(1)在有很多不同值的列上可以考虑使用非聚簇索引，如employee表中的emp_id列可以建立非聚簇索引。
(2)查询结果集返回的是少量或单行的结果集。例如
select*fromemployeewhereemp_id=’pcm9809f’
(3)查询语句中orderby子句的列上可以考虑使用非聚簇索引。
3.2常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。 例如仓库管理系统中有材料入库表，其字段为:材料编号、材料名称、型号，单价，数量…，而金额是用户经常需要在查询和报表中用到的，在表的记录量很大时，有必要把金额作为一个独立的字段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。
3.3用where子句来限制必须处理的行数。 在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。例如： ||| select qty from sales where stor_id=’7131’是很有效的，比无限制的查询selectqtyfromsales有效，避免给客户的最后数据选择返回大量的结果集。当然也可以用TOP限制返回结果集的行数。
3.4尽量使用数字型字段。 一部分开发人员和数据库管理人员喜欢把包含数值信息的字段设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
3.5查询语句的优化。 对于一条复杂的查询语句来说，对相同查询条件的实现一般总可以有多种不同的表达方法，而不同的表达会使数据库的响应速度大相径庭。据统计，约有80%以上的性能问题是由于使用了不恰当的查询语句造成的，因此SQL语句的质量对整个系统效率有重大关系。
下面介绍查询语句优化方面的一些技巧:
(1)避免使用不兼容的数据类型。例如float和int、char和varchar、 binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: SELECTnameFROMemployeeWHEREsalary＞60000 在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。这条语句可以改为： SELECTnameFROMemployeeWHEREsalary＞$60000
(2)尽量避免在Where条件里使用非聚合表达式,因为非聚合表达式很难利用到索引，通常SQLServer不得不进行大规模的扫描。像!=或＜＞、 ISNULL或ISNOTNULL、IN，NOTIN等这样的操作符构成的表达式都是非聚合表达式。非聚合表达式会导致查询效率大大降低。例如: SELECTidFROMemployeeWHEREid!='B%' 优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
(3)尽量避免在WHERE子句中对字段进行函数或表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
SELECT*FROMemployeeWHEREsalary/2=100应改为:
SELECT*FROMemployeeWHEREsalary=100*2 SELECT*FROMemployeeWHERESUBSTRING(emp_id,1,3)=’PCM’应改为:
SELECT*FROMemployeeWHEREemp_idLIKE‘5378%’ SELECTmember_number,first_name,last_nameFROMmembers WHEREDATEDIFF(yy,datofbirth,GETDATE())>21应改为:
SELECT member_number,first_name,last_name FROM members WHERE dateofbirth 即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
(4)避免使用LEFTJOIN SQL的一个有价值的常用功能是LEFTJOIN。它可以用于检索第一个表中的所有行、第二个表中所有匹配的行、以及第二个表中与第一个表中不匹配的所有行。例如，如果希望返回每个客户及其定单，使用LEFTJOIN则可以显示有定单和没有定单的客户。LEFTJOIN消耗的资源非常之多，因为它们包含与 NULL（不存在）数据匹配的数据。因此在构造查询语句时尽量避免使用LEFTJOIN。
(5)尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。 见如下例子：
SELECT*FROMmembersWHEREfirst_nameLIKE‘%MA%’ SELECT*FROMmembersWHERESUBSTING(first_name,3,1)=’MA’ SELECT*FROMmembersWHEREfirst_nameLIKE‘MA%’ 即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。(6)避免相关子查询 一个列的标签同时在主查询和 WHERE子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。可 以采用子查询“展平”技术，将子查询转变为连接,半连接或反连接,从而达到优化查询的目的。例如查询找出有工资超过10000的职工所在的部门名称。 SELECT部门名FROM部门WHERE部门号IN (SELECT部门号FROM职工WHERE工资>10000) 此查询将扫描部门表的 每一行查找所有满足子查询条件的职工记录。可以将部门表作为连接的内表,在这种情况下,查询作为通常的连接来执行,首先对职工表进行唯一的部门号筛选,以 消除冗余的部门号，转化后的语句为: SELECTB.部门名FROM(SELECTDISTINCT部门号FROM职工WHERE工 资>10000,部门DWHEREB.部门号=D.部门号 对于SQL语句的优化方法还有很多，在这里就不一一例举了。