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 = ’号码’）

　　49、

　　(1)IF 没有输入负责人代码THEN code1=0 code2=9999 ELSE code1=code2=负责人代码END IF执行SQL语句为: select负责人名FROM P2000 where负责人代码>=:code1 AND负责人代码 <=:code2

　　(2)IF 没有输入负责人代码THEN 　select负责人名FROM P2000 ELSE code= 负责人代码 select 负责人代码FROM P2000 where负责人代码=:code END IF第一种方法只用了一条SQL语句,第二种方法用了两条SQL语句。在没有输入负责人代码时,第二种方法显然比第一种方法执行效率高,因为它没有限制条件;在输入了负责人代码时,第二种方法仍然比第一种方法效率高,不仅是少了一个限制条件,还因相等运算是最快的查询运算。我们写程序不要怕麻烦

　　50、关于JOBCN现在查询分页的新方法（如下），用性能优化器分析性能的瓶颈，如果在I/O或者网络的速度上，如下的方法优化切实有效，如果在CPU或者内存上，用现在的方法更好。请区分如下的方法，说明索引越小越好。

　　begin
　　DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
　　insert into @local_variable (ReferenceID)
　　select top 100000 ReferenceID from chineseresume order by ReferenceID
　　select * from @local_variable where Fid > 40 and fid <= 60
　　end

　　和

　　begin
　　DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
　　insert into @local_variable (ReferenceID)
　　select top 100000 ReferenceID from chineseresume order by updatedate
　　select * from @local_variable where Fid > 40 and fid <= 60
　　end

　　的不同

　　begin
　　create table #temp (FID int identity(1,1),ReferenceID varchar(20))
　　insert into #temp (ReferenceID)
　　select top 100000 ReferenceID from chineseresume order by updatedate
　　select * from #temp where Fid > 40 and fid <= 60 drop table #temp
　　end