经常听说SQL Server最难的部分是性能优化，不禁让人感到优化这个工作很神秘，这种事情只有高手才能做。很早的时候我在网上看到一位高手写的博客，介绍了SQL优化的问题，从这些内容来看，优化并不都是一些很复杂的问题，掌握了基本的知识之后也可以尝试优化自己的SQL程序，甚至是其他相关的程序。优化是一些工作积累之后的经验总结和代码意识，只要平时注意积累，你也可以做优化的工作。这一篇随笔是转载，不过我强烈推荐给所有对数据库优化有兴趣的博友，读了这一篇之后下一次别人谈论优化的时候我们这些小菜就可以跟别人侃侃而谈了，不至于面面相觑，不知所措。

　　始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。

　　一、分析阶段

　　一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。

　　二、设计阶段

　　设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。

　　以下是性能要求设计阶段需要注意的：

　　1、数据库逻辑设计的规范化

　　数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：

　　第1规范：没有重复的组或多值的列，就是一个表中的列不可再分，这是数据库设计的最低要求。

　　第2规范：每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。就是说一个表中的行可以唯一标识。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。

　　第3规范：一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。

　　更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。

　　2、合理的冗余

　　完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。

　　冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。

　　冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。

　　3、主键的设计

　　主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。

　　在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前面。

　　4、外键的设计

　　外键作为数据库对象，很多人认为麻烦而不用，实际上，外键在大部分情况下是很有用的，理由是：外键是最高效的一致性维护方法，数据库的一致性要求，依次可以用外键、CHECK约束、规则约束、触发器、客户端程序，一般认为，离数据越近的方法效率越高。

　　谨慎使用级联删除和级联更新，级联删除和级联更新作为SQL SERVER 2000当年的新功能，在2005作了保留，应该有其可用之处。我这里说的谨慎，是因为级联删除和级联更新有些突破了传统的关于外键的定义，功能有点太过强大，使用前必须确定自己已经把握好其功能范围，否则，级联删除和级联更新可能让你的数据莫名其妙的被修改或者丢失。从性能看级联删除和级联更新是比其他方法更高效的方法。