早1EI 1.1 编写目的 一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，面是在整个 软件生命周期都需要注意，进行有效工作才能达到的.
所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关 的注意事项.
1.2 分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引 了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、 响应时间的需求、硬件的配置等.
最好能有各种需求的量化的指标.
另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是0LTP（联机事务处理系统）和0LAP （联机分析处理系统）.
1.3 设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎性能调优的过程一数据库设计.
在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的 性能打下良好的基确.
以下是性能要求设计阶段需要注意的： 1.3.1数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求.
第2规范每个非关键字段必须依赖于主关键字，不能依额于一个组合式主关键字的某些组成部分.
消除部分依额，大 部分情况下，数据库设计都应该达到第二范式.
第3规范一个非关键字段不能依赖于另一个非关键字段-消除传运依赖，达到第三范式应该是系统中大部分表的要求， 除非一些特殊作用的表.
更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的 列和较多的表，因而减少了数据瓦余，也利于性能的提高.
1.3.2合理的余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入余是必要的.
》余可以是余数据库、余表或者余字段，不同粒度的瓦余可以起到不同的作用.
究余可以是为了编程方使而增加，也可以是为了性能的提高面增加.
从性能角度来说，余数据库可以分散数据库压 力，余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，余字段可以有效减少数据库表的连接， 提高效率.
1.3.3主键的设计 主键是必要的，SQLSERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键， 第1页共19页
所以主键往往适合作为表的聚集索引.
聚集索引对查询的影响是比较大的，这个在下面索引的叙述.
在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键 的B树结构的层次更少.
主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般 应该选择重复率低、单独或者组合查询可能性大的字段放在前面.
1.3.4外键的设计 》外键作为数据库对象，很多人认为麻烦而不用，实际上，外键在大部分情况下是很有用的，理由是： 》外键是最高效的一致性维护方法，数据库的一致性要求，依次可以用外键、CHECK约束、规则约束、触发器、客 户端程序，一般认为，离数据越近的方法效率越高.
谨慎使用级联删除和级联更新，级联删除和级联更新作为SQLSERVER2000当年的新功能，在2005作了保留， 应该有其可用之处.
我这里说的谨慎，是因为级联删除和级联更新有些突破了传统的关于外键的定义，功能有点 太过强大，使用前必须确定自已已经把握好其功能范围，否则，级联删除和级联更新可能让你的数据莫名其妙 的被修改或者丢失.
从性能看级联删除和级联更新是比其他方法更高效的方法.
1.3.5字段的设计 字段是数据库最基本的单位，其设计对性能的影响是很大的.
需要注意如下： 数据类型尽量用数字型，数字型的比较比字符型的快很多.
数据类型尽量小，这里的尽量小是指在满足可以预见的未来需求的前提下的.
尽量不要允许NULL，除非必要，可以用NOT NULLDEFAULT代替.
少用TEXT和IMAGE，二进制字段的读写是比较慢的，而且，读取的方法也不多，大部分情况下最好不用.
》自增字段要慎用，不利于数据迁移.
1.3.6数据库物理存储和环境的设计 在设计阶段，可以对数据库的物理存储、操作系统环境、网络环境进行必要的设计，使得我们的系统在将来能适应比 较多的用户并发和比较大的数据量.
这里需要注意文件组的作用，适用文件组可以有效把10操作分散到不同的物理硬盘，提高并发能力.
1.3.7系统设计 第2页共19页
整个系统的设计特别是系统结构设计对性能是有很大影响的，对于一般的OLTP系统，可以选择CS结构、三层的CS结 构等，不同的系统结构其性能的关键也有所不同.
系统设计阶段应该归纳一些业务逻辑放在数据库编程实现，数据库编程包括数据库存储过程、触发器和函数.
用数据 库编程实现业务逻辑的好处是减少网络流量并可更充分利用数据库的预编译和缓存功能.
1.3.8索引的设计 在设计阶段，可以根据功能和性能的需求进行初步的索引设计，这里需要根据预计的数据量和查询来设计索引，可 能与将来实际使用的时候会有所区别.
关于索引的选择，应改主意： 根据数据量决定哪些表需要增加索引，数据量小的可以只有主键.
根据使用频率决定哪些字段需要建立索引，选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候 选字段， 把经常一起出现的字段组合在一起，组成组合索引，组合索引的字段顺序与主键一样，也需要把最常用的字段放在前 面，把重复率低的字段放在前面.
一个表不要加太多索引，因为索引影响插入和更新的速度.
1.4 编码阶段 编码阶段是本文的重点，因为在设计确定的情况下，编码的质量几乎决定了整个系统的质量.
编码阶段首先是需要程序员有性能意识，也就是在实现功能同时有考虑性能的思想，数据库是能进行集合运算 的工具，我们应该尽量的利用这个工具，所谓集合运算实际是批量运算，就是尽量减少在客户端进行大数据量的循环操作， 而用SQL语句或者存储过程代替.
关于思想和意识，很难说得很清楚，需要在编程过程中来体会.
下面罗列一些编程阶段需要注意的事项： 1.4.1只返回需要的数据 返回数据到客户端至少需要数据库提取数据、网络传输数据、客户端接收数据以及客户端处理数据等环节，如果返回 不需要的数据，就会增加服务器、网络和客户端的无效劳动，其害处是显而易见的，避免这类事件需要注意： 横向来看，不要写SELECT的语句，面是选择你需要的字段.
纵向来看，合理写WHERE 子句，不要写没有 WHERE 的 SQL语句.
注意SELECTINTO后的WHERE子句，因为 SELECTINTO把数据插入到临时表，这个过程会锁定一些系统表，如果这个 WEE子句返回的数据过多或者速度太慢，会造成系统表长期锁定，诸塞其他进程.
对于聚合查询，可以用HAVING子句进一步限定返回的行.
第3页共19页
1.4.2尽量少做重复的工作 这一点和上一点的目的是一样的，就是尽量减少无效工作，但是这一点的侧重点在客户端程序，需要注意的如下： 控制同一语句的多次执行，特别是一些基确数据的多次执行是很多程序员很少注意的.
减少多次的数据转换，也许需要数据转换是设计的问题，但是减少次数是程序员可以做到的.
杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销.
合并对同一表同一条件的多次UPDATE，比如 UPDATE EMPLOYEE SET FNAME=HAIVER* WHERE EMP_ID=* VPA30890F* UPDATE EMPL0YEE SET LNAME=YANG KHERE EMP_ID=* YPA30890F*这两个语句应该合并成以下个语句UPDATE EMPLOYEE SET FNAME=HAIVER' LNAME=YANG’WHERE EMP_ID=* YPA30890F* UPDATE 操作不要拆成DELETE 操作INSERT 操作的形式，虽然功能相同，但是性能差别是很大的.
不要写一些没有意义的查询，比如SELECT FROM EMPLOYEE WHERE 1=2 1.4.3注意事务和锁 事务是数据库应用中和重要的工具，它有原子性、一致性、隔离性、持久性这四个属性，很多操作我们都需要利用事 务来保证数据的正确性.
在使用事务中我们需要做到尽量避免死锁、尽量减少阻塞.
具体以下方面需要特别注意： 事务操作过程要尽量小，能拆分的事务要拆分开来.
事务操作过程不应该有交互，因为交互等待的时候，事务并未结束，可能锁定了很多资源.
事务操作过程要按同一顺序访间对象.
提高事务中每个语句的效率，利用索引和其他方法提高每个语句的效率可以有效地减少整个事务的执行时间.
尽量不要指定锁类型和索引，SQLSERVER允许我们自己指定语句使用的锁类型和索引，但是一般情况下，SQL SERVER 优化器选择的锁类型和索引是在当前数据量和查询条件下是最优的，我们指定的可能只是在目前情况下更有，但是数 据量和数据分布在将来是会变化的.
查询时可以用较低的隔离级别，特别是报表查询的时候，可以选择最低的隔离级别（未提交读）.
1.4.4注意临时表和表变量的用法 在复杂系统中，临时表和表变量很难避免，关于临时表和表变量的用法，需要注意： 如果语句很复杂，连接太多，可以考虑用临时表和表变量分步完成.
如果需要多次用到一个大表的同一部分数据，考虑用临时表和表变量暂存这部分数据.
第4页共19页
如果需要综合多个表的数据，形成一个结果，可以考虑用临时表和表变量分步汇总这多个表的数据.
其他情况下，应该控制临时表和表变量的使用.
》关于临时表和表变量的选择，很多说法是表变量在内存，速度快，应该首选表变量，但是在实际使用中发现，这个选 择主要考虑需要放在临时表的数据量，在数据量较多的情况下，临时表的速度反而更快.
关于临时表产生使用 SELECT INTO 和 CREATE TABLEINSERT INTO 的选择，我们做过测试，一般情况下，SELECT INTO 会比 CREATE TABLE INSERT INTO 的方法快很多 但是 SELECT INTO 会锁定 TEIPDB 的系统表 SYSOBJECTS、SYSINDEXES、 SYSCOLLMNS，在多用户并发环境下，容易阻塞其他进程，所以我的建议是，在并发系统中，尽量使用CREATE TABLE INSERT INTO，而大数据量的单个语句使用中，使用 SELECT INT0.
注意排序规则，用CREATETABLE建立的临时表，如果不指定字段的排序规则，会选择TEMIPDB的默认排序规则，而不 是当前数据库的排序规则.
如果当前数据库的排序规则和TEMPDB的排序规则不同，连接的时候就会出现排序规则的冲 突错误.
一般可以在CREATE TABLE建立临时表时指定字段的排序规则为 DATABASE_DEFAULT来避免上述间题.
1.4.5子查询的用法 子查询是一个SELECT查询，它嵌套在 SELECT、INSERT、UPDATE、DELETE语句或其它子查询中.
任何允许使用表达 式的地方都可以使用子查询.
子查询可以使我们的编程灵活多样，可以用来实现一些特殊的功能.
但是在性能上，往往一个不合适的子查询用法会 形成一个性能颈.
如果子查询的条件中使用了其外层的表的字段，这种子查询就叫作相关子查询.
相关子查询可以用IN、NOTIN、 EXISTS、 NOT EXISTS 引I 入. 关于相关子查询，应该注意： NOT IN、NOTEXISTS的相关子查询可以改用LEFT JOIN代替写法.
比如： 如果保证子查询没有重复，IN、EXISTS 的相关子查询可以用INNER JOIN 代替.
比如： IN的相关子查询用EXISTS 代替，比如 不要用COUNTO的子查询判断是否存在记录，最好用LEFT JOIN或者EXISTS，比如有人写这样的语句： 1.4.6慎用游标 数据库一般的操作是集合操作，也就是对由WERE子句和选择列确定的结果集作集合操作，游标是提供的一个非集合 操作的途径.
一般情况下，游标实现的功能往往相当于客户端的一个循环实现的功能，所以，大部分情况下，我们把游标功 能搬到客户端.
游标是把结果集故在服务器内存，并通过循环一条一条处理记录，对数据库资源（特别是内存和锁资源）的消耗是非 第5页共19页
