ORACLE select 递归查询

发布时间:2025-05-20 12:46:30 发布人:远客网络

ORACLE select 递归查询

一、ORACLE select 递归查询

1、START WITH定义数据行查询的初始起点；

2、CONNECT BY prior定义表中的各个行是如何联系的；

3、connect by后面的"prior"如果缺省，则只能查询到符合条件的起始行，并不进行递归查询；

4、条件2：col_1= col_2，col_1是父键（它标识父），col_2是子键（它标识子）。

5、条件3过滤递归前相应节点及其子节点，如果上级节点不满足则下级节点自动过滤掉；

6、条件4过滤递归后相应的节点或子节点，如果上级节点不满足则下级结点自动提升一级。

7、CURRVAL AND NEXTVAL使用序列号的保留字

8、LEVEL显示层次树中特定行的层次或级别

9、CONNECT_BY_ROOT返回当前层的根节点(当前行数据所对应的最高等级节点的内容)

10、SYS_CONNECT_BY_PATH(<column>,<char>)函数实现将从父节点到当前行内容以"path"或者层次元素列表的形式显示出来

11、CONNECT_BY_ISCYCLE须带参数NOCYCLE，当前行中引用了某个父亲节点的内容并在树中出现了循环，如果循环显示"1"，否则就显示"0"。

12、CONNECT_BY_ISLEAF判断当前行是不是叶子。如果是叶子显示"1"，如果不是叶子而是一个分支（例如当前内容是其他行的父亲）就显示"0"

13、而在 Oracle 10g中，只要指定"NOCYCLE"就可以进行任意的查询操作。与这个关键字相关的还有一个伪列——CONNECT_BY_ISCYCLE，如果在当前行中引用了某个父亲节点的内容并在树中出现了循环，那么该行的伪列中就会显示"1"，否则就显示"0"。

14、create table test(superid varchar2(20),id varchar2(20),mc varchar2(20));

15、insert into test values('0','1','A1');

16、insert into test values('0','2','A2');

17、insert into test values('1','11','A11');

18、insert into test values('1','12','A12');

19、insert into test values('2','21','A21');

20、insert into test values('2','22','A22');

21、insert into test values('11','111','A111');

22、insert into test values('11','112','A112');

23、insert into test values('12','121','A121');

24、insert into test values('12','122','A122');

25、insert into test values('21','211','A211');

26、insert into test values('21','212','A212');

27、insert into test values('22','221','A221');

28、insert into test values('22','222','A222');

29、select level||'级' jc,lpad('',(level-1)*4)||id id,mc

30、start with superid='0' connect by prior id=superid;

31、select level||'级' jc,connect_by_isleaf mxf,lpad('',(level-1)*4)||id id,mc

32、start with superid='0' connect by prior id=superid;

33、--给出两个以前在"数据库字符串分组相加之四"中的例子来理解start with... connect by...

34、--功能：实现按照superid分组,把id用";"连接起来

35、--实现：以下两个例子都是通过构造2个伪列来实现connect by连接的。

二、数据库的多表大数据查询应如何优化

数据库的多表大数据查询应如何优化？

1.应尽量避免在 where子句中对字段进行 null值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

2.应尽量避免在 where子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

3.应尽量避免在 where子句中使用 or来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

select id from t where num=10

select id from t where num=20

4.in和 not in也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：

select id from t where num in(1,2,3)

对于连续的数值，能用 beeen就不要用 in了：

select id from t where num beeen 1 and 3

5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。

SELECT* FROM T1 WHERE NAME LIKE‘%L%’

SELECT* FROM T1 WHERE SUBSTING(NAME,2,1)=’L’

SELECT* FROM T1 WHERE NAME LIKE‘L%’

即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

6.必要时强制查询优化器使用某个索引，如在 where子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t where num=@num

select id from t with(index(索引名)) where num=@num

7.应尽量避免在 where子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

SELECT* FROM T1 WHERE F1/2=100

SELECT* FROM T1 WHERE F1=100*2

SELECT* FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’

SELECT* FROM RECORD WHERE CARD_NO LIKE‘5378%’

SELECT member_number, first_name, last_name FROM members

WHERE DATEDIFF(yy,datofbirth,GETDATE())> 21

SELECT member_number, first_name, last_name FROM members

WHERE dateofbirth< DATEADD(yy,-21,GETDATE())

即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name,1,3)='abc'--name以abc开头的id

select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

select id from t where name like'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

9.不要在 where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

11.很多时候用 exists是一个好的选择：

elect num from a where num in(select num from b)

select num from a where exists(select 1 from b where num=a.num)

SELECT SUM(T1.C1)FROM T1 WHERE(

(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)

SELECT SUM(T1.C1) FROM T1WHERE EXISTS(

SELECT* FROM T2 WHERE T2.C2=T1.C2)

两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

String query="select列名 from表名 where id=11 and fname='xx' order by列名 desc limit 1";

stmt= conn.createStatement();

rs= stmt.executeQuery(query);

传统数据库处理大数据很困难吧，不建议使用传统数据库来处理大数据。

建议研究下，Hadoop，Hive等，可处理大数据。

如果有预算，可以使用一些商业大数据产品，国内的譬如永洪科技的大数据BI产品，不仅能高性能处理大数据，还可做数据分析。

当然如果是简单的查询，传统数据库如果做好索引，可能可以提高性能。

select 100* from tbllendlist where fldserialNo not in( select 300100 fldserialNo from tbllendlist order by fldserialNo) order by fldserialNo

SELECT TOP 100* FROM tbllendlist WHERE(fldserialNo>(SELECT MAX(fldserialNo) FROM(SELECT TOP 300100 fldserialNo FROM tbllendlist ORDER BY fldserialNo) AS T)) ORDER BY fldserialNo

影响命中率的因素有四种：字典表活动、临时段活动、回滚段活动、表扫描，应用DBA可以对这四种因素进行分析，找出数据库命中率低的症结所在。 1)字典表活动当一个SQL语句第一次到达Oracle内核时数据库对SQL语句进行分析，包含在查询中的数据字典对象被分解，产生SQL执行路径。如果SQL语句指向一个不在SGA中的对象?表或视图，Oracle执行SQL语句到数据典中查询有关对象的信息。数据块从数据字典表被读取到SGA的数据缓存中。由于每个数据字典都很小，因此，我们可缓存这些表以提高对这些表的命中率。但是由于数据字典表的数据块在SGA中占据空间，当增加全部的命中率时，它们会降低表数据块的可用空间，所以若查询所需的时间字典信息已经在SGA缓存中，那么就没有必要递归调用。 2)临时段的活动当用户执行一个需要排序的查询时，Oracle设法对内存中排序区内的所有行进行排序，排序区的大小由数据库的init.ora文件的数确定。如果排序区域不够大，数据库就会在排序操作期间开辟临时段。临时段会人为地降低OLTP(online transaction processing）应用命中率,也会降低查询进行排序的性能。如果能在内存中完成全部排序操作，就可以消除向临时段写数据的开销。所以应将SORT_AREA_SIZE设置得足够大，以避免对临时段的需要。这个参数的具体调整方法是:查询相关数据，以确定这个参数的调整。 select* from v$sysstat where name='sorts(disk)'or name='sorts(memory);大部分排序是在内存中进行的，但还有小部分发生在临时段，需要调整值，查看init.ora文件的 SORT_AREA_SIZE值，参数为：SORT_AREA_SIZE＝65536;将其调整到SORT_AREA_SIZE＝131072、这个值调整后，重启ORACLE数据库即可生效。 3)回滚段的活动回滚段活动分为回滚活动和回滚段头活动。对回滚段头块的访问会降低应用的命中率，对OLTP系统命中率的影响最大。为确认是否因为回滚段影响了命中率，可以查看监控输出报表中的“数据块相容性读一重写记录应用”的统计值，这些统计值是用来确定用户从回滚段中访问数据的发生次数。 4)表扫描通过大扫描读得的块在数据块缓存中不会保持很长时间，因此表扫描会降低命中率。为了避免不必要的全表扫描，首先是根据需要建立索引，合理的索引设计要建立人对各种查询的分析和预测上，笔者会在SQL优化中详细谈及；其次是将经常用到的表放在内存中，以降低磁盘读写次数。

1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。

调整不良SQL通常可以从以下几点切入：

?检查不良的SQL，考虑其写法是否还有可优化内容

?检查子查询考虑SQL子查询是否可以用简单连接的方式进行重新书写

2.避免出现SELECT* FROM table语句，要明确查出的字段。

3.在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。

4.查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。

5.在判断有无符合条件的记录时建议不要用SELECT COUNT（*）和select 1语句。

6.使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。

7.应绝对避免在order by子句中使用表达式。

8.如果需要从关联表读数据，关联的表一般不要超过7个。

9.小心使用 IN和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。

10.<>用<、>代替，>用>=代替，<用<=代替，这样可以有效的利用索引。

11.在查询时尽量减少对多余数据的读取包括多余的列与多余的行。

12.对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。

13.多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where(table1的等值条件（=）) and(table1的非等值条件) and(table2与table1的关联条件) and(table2的等值条件) and(table2的非等值条件) and(table3与table2的关联条件) and(table3的等值条件) and(table3的非等值条件)。

注:关于多表查询时from后面表的出现顺序对效率的影响还有待研究。

14.子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。

15.在WHERE子句中，避免对列的四则运算，特别是where条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring可以用like代替。

16.如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。

17.对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。

18.请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。

19.用union all代替 union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。

当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。

1.在一个事物中，对同一个表的多个insert语句应该集中在一起执行。

2.在一个业务过程中，尽量的使insert,update,delete语句在业务结束前执行，以减少死锁的可能性。

为了避免I/O的冲突，我们在设计数据库物理规划时应该遵循几条基本的原则(以ORACLE举例)：

?? table和index分离：table和index应该分别放在不同的tablespace中。

?? Rollback Segment的分离：Rollback Segment应该放在独立的Tablespace中。

?? System Tablespace的分离：System Tablespace中不允许放置任何用户的object。（mssql中primary filegroup中不允许放置任何用户的object）

?? Temp Tablesace的分离：建立单独的Temp Tablespace，并为每个user指定default Temp Tablespace

??避免碎片：但segment中出现大量的碎片时，会导致读数据时需要访问的block数量的增加。对经常发生DML操作的segemeng来说，碎片是不能完全避免的。所以，我们应该将经常做DML操作的表和很少发生变化的表分离在不同的Tablespace中。

当我们遵循了以上原则后，仍然发现有I/O冲突存在，我们可以用数据分离的方法来解决。

??连接Table的分离：在实际应用中经常做连接查询的Table，可以将其分离在不同的Taclespace中，以减少I/O冲突。

??使用分区：对数据量很大的Table和Index使用分区，放在不同的Tablespace中。

在实际的物理存储中，建议使用RAID。日志文件应放在单独的磁盘中。

给出你的查询，然后才可以对其进行优化

如果你的查询比较固定，并且查询的条件区别度较高，可以建立相应的索引。

其他的一些规则，比如使用exists代替 in都可以试试

查询速度慢的原因很多，常见如下几种：

1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)

2、I/O吞吐量小，形成了瓶颈效应。

3、没有创建计算列导致查询不优化。

6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）

7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)

8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。

1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要.

2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)

4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段

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处理查询计划的过程是这样的：

2、将语句提交给DBMS的查询优化器

3、优化器做代数优化和存取路径的优化

5、然后在合适的时间提交给系统处理执行

6、最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。

12、Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物.没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) mit 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 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),在前台调用这个存储过程传入二进制参数，这样处理速度明显改善