Oracle查询速度优化问题

Posted 2023-04-05

select *
from ADOPT_NOTICE_INFO a, CHILD_BASIC_INFO b
where a.CHILD_ID=b.ID
and b.WELFARE_ID = 15

就这样一条简单的查询，a、b表的id都是主键，a.CHILD_ID、b表的WELFARE_ID列也已经建立了索引，查询时不带WELFARE_ID的条件，速度<1秒，加上那个过滤条件后，速度异常缓慢，出结果需要40秒左右

另外：两个表的数据量都是8万左右

1. 选用适合的ORACLE优化器
ORACLE的优化器共有3种:
a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性)
设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖.
为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行analyze 命令,以增加数据库中的对象统计信息(object statistics)的准确性.
如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关. 如果table已经被analyze过, 优化器模式将自动成为CBO , 反之,数据库将采用RULE形式的优化器.
在缺省情况下,ORACLE采用CHOOSE优化器, 为了避免那些不必要的全表扫描(full table scan) , 你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器.

2. 访问Table的方式
ORACLE 采用两种访问表中记录的方式:
a. 全表扫描
全表扫描就是顺序地访问表中每条记录. ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描.
b. 通过ROWID访问表
你可以采用基于ROWID的访问方式情况,提高访问表的效率, , ROWID包含了表中记录的物理位置信息..ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系. 通常索引提供了快速访问ROWID的方法,因此那些基于索引列的查询就可以得到性能上的提高.

3. 共享SQL语句
为了不重复解析相同的SQL语句,在第一次解析之后, ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享. 因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它
和之前的执行过的语句完全相同, ORACLE就能很快获得已经被解析的语句以及最好的
执行路径. ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用.
可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering) ,这个功能并不适用于多表连接查询.
数据库管理员必须在init.ora中为这个区域设置合适的参数,当这个内存区域越大,就可以保留更多的语句,当然被共享的可能性也就越大了.
当你向ORACLE 提交一个SQL语句,ORACLE会首先在这块内存中查找相同的语句.
这里需要注明的是,ORACLE对两者采取的是一种严格匹配,要达成共享,SQL语句必须完全相同(包括空格,换行等).

4.选择最有效率的表名顺序(只在基于规则的优化器中有效)
ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理. 在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.当ORACLE处理多个表时, 会运用排序及合并的方式连接它们.首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行派序,然后扫描第二个表(FROM子句中最后第二个表),最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.
5. WHERE子句中的连接顺序．
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.
6. SELECT子句中避免使用 ‘ * ‘
当你想在SELECT子句中列出所有的COLUMN时,使用动态SQL列引用 ‘*' 是一个方便的方法.不幸的是,这是一个非常低效的方法. 实际上,ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间.
7. 减少访问数据库的次数
当执行每条SQL语句时, ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等等. 由此可见, 减少访问数据库的次数 , 就能实际上减少ORACLE的工作量.
注意: 在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200.

8. 使用DECODE函数来减少处理时间
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.

9. 整合简单,无关联的数据库访问
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系)

10. 删除重复记录
最高效的删除重复记录方法 ( 因为使用了ROWID)
DELETE FROM EMP E
WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X
WHERE X.EMP_NO = E.EMP_NO);

11. 用EXISTS替代IN
在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接.在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率.
12. 用NOT EXISTS替代NOT IN
在子查询中,NOT IN子句将执行一个内部的排序和合并. 无论在哪种情况下,NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用NOT IN ,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS 参考技术A 1.
理论上，第2种写法应该更快，
第1种写法有问题：
1).
第一种写法应该改成to_char(time,'yyyy-mm-dd')或trunc(time,'dd')，比如按日统计，不然字符串类型的数据比大小会有问题
2).
即便第一种写法改了，也会因为主键的unique
index是基于id和time的，第一种写法将time转换成字符串类型，从而无法在查询中使用索引，导致全表扫描(full
table
scan,fts)
2.
如果查询速度慢，需要先看执行计划(比如plsql按f5)，最好是通过alter
session
set
sql_trace=true，抓取实际运行时的执行计划，加以分析
3.
to_char()后的字符串比较，有oracle的逻辑，比如哈稀或者通过转换成hex编码比较大小
举例说明：
declare
a
varchar2(20);
b
varchar2(20);
begin
a:='aaa';
b:='bbb';
if
a>b
then
dbms_output.put_line('true');
else
dbms_output.put_line('false');
end
if;
exception
when
others
then
dbms_output.put_line('exception
occured');
end;
＝＝＝
上述代码将a,b两个字符串变量赋值，并进行比较
能得到结果false，而不是例外(exception) 参考技术B 不知道你的oracle版本是什么时候的？
如果是8以前的版本的话，执行计划是基于规则的。8以上的版本后，在使用的时候大多是基于开销的。
如果你的是早期版本的oracle的话，你应该这写：
select *
from ADOPT_NOTICE_INFO a, CHILD_BASIC_INFO b
where b.WELFARE_ID = 15
and a.CHILD_ID=b.ID
怎么说，才8万多笔的数据没这么差的性能吧，更何况还建了index 参考技术C 可能你的WELFARE_ID索引坏了导致查询WELFARE_ID=15时全表扫描了，将B.WELFARE_ID=15放到AND前面试试（即跟A.CHILD_ID=B.ID调换位置），再不行就重建下WELFARE_ID的索引。
（BS贴答案的） 参考技术D 个人感觉也是WELFARE_ID未建立索引的原因，建议楼主把此索引加上然后再查询，我觉得速度会提高很多的

为啥NATIVE FOR ORACLE查询速度慢

使用NATIVE FOR ORACLE查询一张数据量为10W的表时，查询速度特别慢

　　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 语句中的锁提示。
　　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), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。
　　29、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。 select
　　*
　　from chineseresume where title in (\'男\',\'女\') Select
　　*
　　from chineseresume where
　　between
　　\'男\'
　　and
　　\'女\' 是一样的。由于in会在比较多次，所以有时会慢些。
　　30、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
　　31、不要建没有作用的事物例如产生报表时，浪费资源。只有在必要使用事物时使用它。
　　32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
　　33、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
　　34、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理。 SELECT
　　top
　　20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in(\'JCNAD00329667\',\'JCNAD132168\',\'JCNAD00337748\',\'JCNAD00338345\',\'JCNAD00333138\',\'JCNAD00303570\', \'JCNAD00303569\',\'JCNAD00303568\',\'JCNAD00306698\',\'JCNAD00231935\',\'JCNAD00231933\',\'JCNAD00254567\', \'JCNAD00254585\',\'JCNAD00254608\',\'JCNAD00254607\',\'JCNAD00258524\',\'JCNAD00332133\',\'JCNAD00268618\', \'JCNAD00279196\',\'JCNAD00268613\') order
　　by postdate desc
　　35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。
　　36、当用SELECT INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是select INTO. drop
　　table t_lxh begin
　　tran
　　select
　　*
　　into t_lxh from chineseresume where name =
　　\'XYZ\'
　　--commit 在另一个连接中SELECT * from sysobjects可以看到 SELECT INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它!!!这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
　　37、一般在GROUP BY 个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
　　38、一次更新多条记录比分多次更新每次一条快,就是说批处理好
　　39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好
　　40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：
　　a、计算字段的表达是确定的
　　b、不能用在TEXT,Ntext，Image数据类型
　　c、必须配制如下选项 ANSI_NULLS =
　　ON, ANSI_PADDINGS =
　　ON, …….
　　41、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。反复执行的动态SQL,可以使用临时存储过程，该过程(临时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持，所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算，函数的返回值不要太大，这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源，如果返回大的结果采用存储过程
　　42、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快
　　43、SELECT
　　COUNT(*)的效率教低，尽量变通他的写法，而EXISTS快.同时请注意区别： select
　　count(Field of
　　null) from
　　Table 和 select
　　count(Field of
　　NOT
　　null) from
　　Table 的返回值是不同的!!!
　　44、当服务器的内存够多时，配制线程数量 = 最大连接数+5，这样能发挥最大的效率;否则使用 配制线程数量<最大连接数启用SQL SERVER的线程池来解决,如果还是数量 = 最大连接数+5，严重的损害服务器的性能。
　　45、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
　　46、通过SQL Server Performance Monitor监视相应硬件的负载 Memory: Page Faults / sec计数器如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。 Process:
　　1、% DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。(DPC 正在运行的为比标准间隔优先权低的间隔)。 由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间 百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部 分。这个总数显示了作为实例时间百分比的平均忙时。
　　2、%Processor Time计数器　如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
　　3、% Privileged Time 指非闲置处理器时间用于特权模式的百分比。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种处理模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限处理模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。 特权时间的 % 包括为间断和 DPC 提供服务的时间。特权时间比率高可能是由于失败设备产生的大数量的间隔而引起的。这个计数器将平均忙时作为样本时间的一部分显示。
　　4、%
　　User Time表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 Physical Disk: Curretn Disk Queue Length计数器该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。 SQLServer:Cache Hit Ratio计数器该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。
　　47、分析select emp_name form employee where salary >
　　3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。
　　48、查询的关联同写的顺序 select a.personMemberID, *
　　from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID =
　　\'JCNPRH39681\' (A = B ,B = ‘号码\') select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = \'JCNPRH39681\' and b.referenceid = \'JCNPRH39681\' (A = B ,B = ‘号码\'， A = ‘号码\') select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = \'JCNPRH39681\' and a.personMemberID = \'JCNPRH39681\' (B = ‘号码\'， A = ‘号码\') 参考技术A 数据量大查询肯定慢啊，你看看要不要加点索引什么的