SQL Server数据库性能优化技术(转)
来源:http://www.newasp.net/tech/data/2430.html
摘 要：影响SQL Server数据库性能的一些因素及SQL Server进行性能优化的原理，
关键词：SQL Server数据库 性能优化 查询
设计1个应用系统似乎并不难，但是要想使系统达到最优化的性能并不是一件容易的
事。在开发工具、数据库设计、应用程序的结构、查询设计、接口选择等方面有多种选择，这
取决于特定的应用需求以及开发队伍的技能。本文以SQL Server为例，从后台数据库的角度讨
1 数据库设计
要在良好的SQL Server方案中实现最优的性能，最关键的是要有1个很好的数据库设
计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。所
1.1 逻辑库规范化问题
一般来说，逻辑数据库设计会满足规范化的前3级标准：
1.第1规范：没有重复的组或多值的列。
2.第2规范：每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字
3.第3规范：1个非关键字段不能依赖于另1个非关键字段。
遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少
了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某
种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种
不同的方法进行，但以下方法经实践验证往往能提高性能。
1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体(表)
2.常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。
比如某一个项目的计划管理系统中有计划表，其字段为：项目编号、年初计划、二次
计划、调整计划、补列计划…，而计划总数(年初计划+二次计划+调整计划+补列计划)是用户
经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字
段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。
3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是：
(1)把1个实体(表)分割成2个表(把所有的属性分成2组)。这样就把频繁被访问的数据
同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利
(2)把1个实体(表)分割成2个表(把所有的行分成2组)。这种方法适用于那些将包含
大量数据的实体(表)。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁
被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组(部门
、销售分区、地理区域等)访问的，那么这种方法也是很有好处的。
1.2 生成物理数据库
要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，
主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。
1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引
的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地
读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。
2.把1个表放在某个物理设备上，再通过SQL Server段把它的不分簇索引放在1个不
同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术
3.用SQL Server段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制
器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性
4.用SQL Server段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能
2 与SQL Server相关的硬件系统
与SQL Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部
分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。
2.1 系统处理器(CPU)
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的
过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就
足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。
2.2 内存(RAM)
为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL
Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多
能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相
Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由
Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL
Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。
Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内
存多于可用的物理内存时，会降低SQL Server的性能。
这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它
软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存
。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的
法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需
要32MB+100用户*100KB＝42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说
2.3 磁盘子系统
设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨
论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统
的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下：
(1)控制器高速缓存。
(2)总线主板上有处理器，可以减少对系统CPU的中断。
(3)异步读写支持。
(4)32位RAID支持。
(5)快速SCSI?2驱动。
(6)超前读高速缓存(至少1个磁道)。
3 检索策略
在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应
用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查
询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引；第2
3.1 SQL Server优化器
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交
的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE
和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字
符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用
图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供
SQL Server的优化通过3个阶段完成：查询分析、索引选择、合并选择。
1.查询分析 在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“<>”的子句。因为“<>”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。
2.索引选择
对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用
于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为
是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原
来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所
有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否
符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。
所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为
(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的
索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，
较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储
和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的
(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须
做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。
(4)对1个经常被更新的列建立索引，会严重影响性能。
(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些
(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可
(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子
(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快
(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“
ORDER BY”命令中用到的列上有分簇索引，那么就不会再生成1个工作表了，因为行已经排序
(10)分簇索引不应该构造在经常变化的列上，因为这会引起整行的移动。在实现大型
交易处理系统时，尤其要注意这一点，因为这些系统中数据往往是频繁变化的。
3.合并选择
当索引选择结束，并且所有的子句都有了一个基于它们的访问计划的处理费用时，优
化器开始执行合并选择。合并选择被用来找出一个用于合并子句访问计划的有效顺序。为了做
到这一点，优化器比较子句的不同排序，然后选出从物理磁盘I/O的角度看处理费用最低的合
并计划。因为子句组合的数量会随着查询的复杂度极快地增长，SQL Server查询优化器使用树
剪枝技术来尽量减少这些比较所带来的开支。当这个合并选择阶段结束时，SQL Server查询优
化器已经生成了1个基于费用的查询执行计划，这个计划充分利用了可用的索引，并以最小的
3.2 高效的查询选择
从以上查询优化的3个阶段不难看出，设计出物理I/O和逻辑I/O最少的方案并掌握好
处理器时间和I/O时间的平衡，是高效查询设计的主要目标。也就是说，希望设计出这样的查
询：充分利用索引、磁盘读写最少、最高效地利用了内存和CPU资源。
以下建议是从SQL Server优化器的优化策略中总结出来的，对于设计高效的查询是很
1.如果有独特的索引，那么带有“＝”操作符的WHERE子句性能最好，其次是封闭的
2.从数据库访问的角度看，含有不连续连接词(OR和IN)的WHERE子句一般来说性能不
会太好。所以，优化器可能会采用R策略，这种策略会生成1个工作表，其中含有每个可能匹
配的执行的标识符，优化器把这些行标志符(页号和行号)看做是指向1个表中匹配的行的“动
态索引”。优化器只需扫描工作表，取出每一个行标志符，再从数据表中取得相应的行，所以
R策略的代价是生成工作表。
3.包含NOT、<>、或! =的WHERE子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。
4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式
生成索引选择。例如：
paycheck * 12>36000 or substring(lastname,1,1)=“L”
如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改
写上面的条件表达式为：
paycheck<36000/12 or lastname like “L%”
5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为
6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表
中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作
表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。 所以应该注意RAM中或磁
盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的
4 性能优化的其他考虑
上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也
很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选
项也不同程度上影响了SQL Server的性能。
影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实
的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优
化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。
摘 要：影响SQL Server数据库性能的一些因素及SQL Server进行性能优化的原理，
关键词：SQL Server数据库 性能优化 查询
设计1个应用系统似乎并不难，但是要想使系统达到最优化的性能并不是一件容易的
事。在开发工具、数据库设计、应用程序的结构、查询设计、接口选择等方面有多种选择，这
取决于特定的应用需求以及开发队伍的技能。本文以SQL Server为例，从后台数据库的角度讨
1 数据库设计
要在良好的SQL Server方案中实现最优的性能，最关键的是要有1个很好的数据库设
计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。所
1.1 逻辑库规范化问题
一般来说，逻辑数据库设计会满足规范化的前3级标准：
1.第1规范：没有重复的组或多值的列。
2.第2规范：每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字
3.第3规范：1个非关键字段不能依赖于另1个非关键字段。
遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少
了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某
种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种
不同的方法进行，但以下方法经实践验证往往能提高性能。
1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体(表)
2.常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。
比如某一个项目的计划管理系统中有计划表，其字段为：项目编号、年初计划、二次
计划、调整计划、补列计划…，而计划总数(年初计划+二次计划+调整计划+补列计划)是用户
经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字
段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。
3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是：
(1)把1个实体(表)分割成2个表(把所有的属性分成2组)。这样就把频繁被访问的数据
同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利
(2)把1个实体(表)分割成2个表(把所有的行分成2组)。这种方法适用于那些将包含
大量数据的实体(表)。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁
被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组(部门
、销售分区、地理区域等)访问的，那么这种方法也是很有好处的。
1.2 生成物理数据库
要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，
主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。
1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引
的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地
读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。
2.把1个表放在某个物理设备上，再通过SQL Server段把它的不分簇索引放在1个不
同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术
3.用SQL Server段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制
器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性
4.用SQL Server段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能
2 与SQL Server相关的硬件系统
与SQL Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部
分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。
2.1 系统处理器(CPU)
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的
过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就
足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。
2.2 内存(RAM)
为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL
Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多
能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相
Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由
Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL
Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。
Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内
存多于可用的物理内存时，会降低SQL Server的性能。
这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它
软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存
。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的
法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需
要32MB+100用户*100KB＝42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说
2.3 磁盘子系统
设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨
论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统
的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下：
(1)控制器高速缓存。
(2)总线主板上有处理器，可以减少对系统CPU的中断。
(3)异步读写支持。
(4)32位RAID支持。
(5)快速SCSI?2驱动。
(6)超前读高速缓存(至少1个磁道)。
3 检索策略
在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应
用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查
询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引；第2
3.1 SQL Server优化器
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交
的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE
和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字
符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用
图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供
SQL Server的优化通过3个阶段完成：查询分析、索引选择、合并选择。
1.查询分析 在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“<>”的子句。因为“<>”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。
2.索引选择
对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用
于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为
是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原
来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所
有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否
符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。
所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为
(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的
索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，
较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储
和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的
(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须
做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。
(4)对1个经常被更新的列建立索引，会严重影响性能。
(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些
(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可
(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子
(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快
(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“
ORDER BY”命令中用到的列上有分簇索引，那么就不会再生成1个工作表了，因为行已经排序
(10)分簇索引不应该构造在经常变化的列上，因为这会引起整行的移动。在实现大型
交易处理系统时，尤其要注意这一点，因为这些系统中数据往往是频繁变化的。
3.合并选择
当索引选择结束，并且所有的子句都有了一个基于它们的访问计划的处理费用时，优
化器开始执行合并选择。合并选择被用来找出一个用于合并子句访问计划的有效顺序。为了做
到这一点，优化器比较子句的不同排序，然后选出从物理磁盘I/O的角度看处理费用最低的合
并计划。因为子句组合的数量会随着查询的复杂度极快地增长，SQL Server查询优化器使用树
剪枝技术来尽量减少这些比较所带来的开支。当这个合并选择阶段结束时，SQL Server查询优
化器已经生成了1个基于费用的查询执行计划，这个计划充分利用了可用的索引，并以最小的
3.2 高效的查询选择
从以上查询优化的3个阶段不难看出，设计出物理I/O和逻辑I/O最少的方案并掌握好
处理器时间和I/O时间的平衡，是高效查询设计的主要目标。也就是说，希望设计出这样的查
询：充分利用索引、磁盘读写最少、最高效地利用了内存和CPU资源。
以下建议是从SQL Server优化器的优化策略中总结出来的，对于设计高效的查询是很
1.如果有独特的索引，那么带有“＝”操作符的WHERE子句性能最好，其次是封闭的
2.从数据库访问的角度看，含有不连续连接词(OR和IN)的WHERE子句一般来说性能不
会太好。所以，优化器可能会采用R策略，这种策略会生成1个工作表，其中含有每个可能匹
配的执行的标识符，优化器把这些行标志符(页号和行号)看做是指向1个表中匹配的行的“动
态索引”。优化器只需扫描工作表，取出每一个行标志符，再从数据表中取得相应的行，所以
R策略的代价是生成工作表。
3.包含NOT、<>、或! =的WHERE子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。
4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式
生成索引选择。例如：
paycheck * 12>36000 or substring(lastname,1,1)=“L”
如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改
写上面的条件表达式为：
paycheck<36000/12 or lastname like “L%”
5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为
6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表
中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作
表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。 所以应该注意RAM中或磁
盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的
4 性能优化的其他考虑
上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也
很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选
项也不同程度上影响了SQL Server的性能。
影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实
的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优
化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。
来源：http://zhidao.baidu.com/question/1236568.html
本文首先讨论了基于第三范式的数据库表的基本设计，着重论述了建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。
关键词： 优化（Optimizing） 第三范式（3NF） 冗余数据（Redundant Data） 索引（Index） 数据分割（Data Partitioning） 对象放置（Object Placement）
1 引言
数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。为了便于读者阅读和理解，笔者参阅了Sybase、Informix和Oracle等大型数据库系统参考资料，基于多年的工程实践经验，从基本表设计、扩展设计和数据库表对象放置等角度进行讨论，着重讨论了如何避免磁盘I/O瓶颈和减少资源竞争，相信读者会一目了然。
2 基于第三范式的基本表设计
在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式（3NF）。第三范式的基本特征是非主键属性只依赖于主键属性。基于第三范式的数据库表设计具有很多优点：一是消除了冗余数据，节省了磁盘存储空间；二是有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；三是数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；四是因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；五是对大多数事务(Transaction)而言，运行性能好；六是物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。
在基本表设计中，表的主键、外键、索引设计占有非常重要的地位，但系统设计人员往往只注重于满足用户要求，而没有从系统优化的高度来认识和重视它们。实际上，它们与系统的运行性能密切相关。现在从系统数据库优化角度讨论这些基本概念及其重要意义：
（1）主键(Primary Key)：主键被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个表只有一个主键。主键应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用（众所周知）的列作为主键才有意义。短主键最佳（小于25bytes），主键的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成，自然主键可以是复合性的，在形成复合主键时，主键列不能太多，复合主键使得Join*作复杂化、也增加了外键表的大小。人为主键是，在没有合适的自然属性键、或自然属性复杂或灵敏度高时，人为形成的。人为主键一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外键的表的大小。
（2）外键（Foreign Key）：外键的作用是建立关系型数据库中表之间的关系（参照完整性），主键只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外键。
（3）索引(Index)：利用索引优化系统性能是显而易见的，对所有常用于查询中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，这样减少数据存取时间；利用索引可以优化或排除耗时的分类*作；把数据分散到不同的页面上，就分散了插入的数据；主键自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；索引码越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和Update*作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的数据页按物理有序储存，占用空间小。选择策略是，被用于Where子句的列：包括范围查询、模糊查询或高度重复的列（连续磁盘扫描）；被用于连接Join*作的列；被用于Order by和Group by子句的列。聚族索引不利于插入*作，另外没有必要用主键建聚族索引。
② 非聚族索引（Nonclustered Index）：与聚族索引相比，占用空间大，而且效率低。选择策略是，被用于Where子句的列：包括范围查询、模糊查询（在没有聚族索引时）、主键或外键列、点（指针类）或小范围（返回的结果域小于整表数据的20%）查询；被用于连接Join*作的列、主键列（范围查询）；被用于Order by和Group by子句的列；需要被覆盖的列。对只读表建多个非聚族索引有利。索引也有其弊端，一是创建索引要耗费时间，二是索引要占有大量磁盘空间，三是增加了维护代价（在修改带索引的数据列时索引会减缓修改速度）。那么，在哪种情况下不建索引呢？对于小表（数据小于5页）、小到中表（不直接访问单行数据或结果集不用排序）、单值域（返回值密集）、索引列值太长（大于20bitys）、容易变化的列、高度重复的列、Null值列，对没有被用于Where子语句和Join查询的列都不能建索引。另外，对主要用于数据录入的，尽可能少建索引。当然，也要防止建立无效索引，当Where语句中多于5个条件时，维护索引的开销大于索引的效益，这时，建立临时表存储有关数据更有效。
批量导入数据时的注意事项：在实际应用中，大批量的计算（如电信话单计费）用C语言程序做，这种基于主外键关系数据计算而得的批量数据（文本文件），可利用系统的自身功能函数（如Sybase的BCP命令）快速批量导入，在导入数据库表时，可先删除相应库表的索引，这有利于加快导入速度，减少导入时间。在导入后再重建索引以便优化查询。
（4）锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则Server的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。
（5）查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询*作。经验告诉我们，在优化查询时，必须做到：
① 尽可能少的行；
② 避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中*作；用简单的键（列）排序，如整型或短字符串排序；
③ 避免表内的相关子查询；
④ 避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符串连接；
⑤ 在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接；
⑥ 利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。
除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序。
3 基本表扩展设计
基于第三范式设计的库表虽然有其优越性（见本文第一部分），然而在实际应用中有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表，许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程从多表获取数据时引发大量的连接*作，当数据来源于多表时的连接*作；这都消耗了磁盘I/O和CPU时间。
尤其在遇到下列情形时，我们要对基本表进行扩展设计：许多过程要频繁访问一个表、子集数据访问、重复计算和冗余数据，有时用户要求一些过程优先或低的响应时间。
如何避免这些不利因素呢？根据访问的频繁程度对相关表进行分割处理、存储冗余数据、存储衍生列、合并相关表处理，这些都是克服这些不利因素和优化系统运行的有效途径。
3.1 分割表或储存冗余数据
分割表分为水平分割表和垂直分割表两种。分割表增加了维护数据完整性的代价。
水平分割表：一种是当多个过程频繁访问数据表的不同行时，水平分割表，并消除新表中的冗余数据列；若个别过程要访问整个数据，则要用连接*作，这也无妨分割表；典型案例是电信话单按月分割存放。另一种是当主要过程要重复访问部分行时，最好将被重复访问的这些行单独形成子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但在分割表以后，增加了维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。
垂直分割表（不破坏第三范式），一种是当多个过程频繁访问表的不同列时，可将表垂直分成几个表，减少磁盘I/O（每行的数据列少，每页存的数据行就多，相应占用的页就少），更新时不必考虑锁，没有冗余数据。缺点是要在插入或删除数据时要考虑数据的完整性，用存储过程维护。另一种是当主要过程反复访问部分列时，最好将这部分被频繁访问的列数据单独存为一个子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但这增加了重叠列的维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。垂直分割表可以达到最大化利用Cache的目的。
总之，为主要过程分割表的方法适用于：各个过程需要表的不联结的子集，各个过程需要表的子集，访问频率高的主要过程不需要整表。在主要的、频繁访问的主表需要表的子集而其它主要频繁访问的过程需要整表时则产生冗余子集表。
注意，在分割表以后，要考虑重新建立索引。
3.2 存储衍生数据
对一些要做大量重复性计算的过程而言，若重复计算过程得到的结果相同（源列数据稳定，因此计算结果也不变），或计算牵扯多行数据需额外的磁盘I/O开销，或计算复杂需要大量的CPU时间，就考虑存储计算结果（冗余储存）。现予以分类说明：
若在一行内重复计算，就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器更新这个新列。
若对表按类进行重复计算，就增加新表（一般而言，存放类和结果两列就可以了）存储相关结果。但若参与计算的列被更新时，就必须要用触发器立即更新、或存储过程或应用代码批量更新这个新表。
若对多行进行重复性计算（如排名次），就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器或存储过程更新这个新列。
总之，存储冗余数据有利于加快访问速度；但违反了第三范式，这会增加维护数据完整性的代价，必须用触发器立即更新、或存储过程或应用代码批量更新，以维护数据的完整性。
3.3 消除昂贵结合
对于频繁同时访问多表的一些主要过程，考虑在主表内存储冗余数据，即存储冗余列或衍生列（它不依赖于主键），但破坏了第三范式，也增加了维护难度。在源表的相关列发生变化时，必须要用触发器或存储过程更新这个冗余列。当主要过程总同时访问两个表时可以合并表，这样可以减少磁盘I/O*作，但破坏了第三范式，也增加了维护难度。对父子表和1：1关系表合并方法不同：合并父子表后，产生冗余表；合并1：1关系表后，在表内产生冗余数据。
4 数据库对象的放置策略
数据库对象的放置策略是均匀地把数据分布在系统的磁盘中，平衡I/O访问，避免I/O瓶颈。
⑴ 访问分散到不同的磁盘，即使用户数据尽可能跨越多个设备，多个I/O运转，避免I/O竞争，克服访问瓶颈；分别放置随机访问和连续访问数据。
⑵ 分离系统数据库I/O和应用数据库I/O。把系统审计表和临时库表放在不忙的磁盘上。
⑶ 把事务日志放在单独的磁盘上，减少磁盘I/O开销，这还有利于在障碍后恢复，提高了系统的安全性。
⑷ 把频繁访问的“活性”表放在不同的磁盘上；把频繁用的表、频繁做Join*作的表分别放在单独的磁盘上，甚至把把频繁访问的表的字段放在不同的磁盘上，把访问分散到不同的磁盘上，避免I/O争夺；
⑸ 利用段分离频繁访问的表及其索引（非聚族的）、分离文本和图像数据。段的目的是平衡I/O，避免瓶颈，增加吞吐量，实现并行扫描，提高并发度，最大化磁盘的吞吐量。利用逻辑段功能，分别放置“活性”表及其非聚族索引以平衡I/O。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活。
参考资料：http://www.xiaotianya.com/read-7-2026-1.html
本文首先讨论了基于第三范式的数据库表的基本设计，着重论述了建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。
关键词： 优化（Optimizing） 第三范式（3NF） 冗余数据（Redundant Data） 索引（Index） 数据分割（Data Partitioning） 对象放置（Object Placement）
1 引言
数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。为了便于读者阅读和理解，笔者参阅了Sybase、Informix和Oracle等大型数据库系统参考资料，基于多年的工程实践经验，从基本表设计、扩展设计和数据库表对象放置等角度进行讨论，着重讨论了如何避免磁盘I/O瓶颈和减少资源竞争，相信读者会一目了然。
2 基于第三范式的基本表设计
在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式（3NF）。第三范式的基本特征是非主键属性只依赖于主键属性。基于第三范式的数据库表设计具有很多优点：一是消除了冗余数据，节省了磁盘存储空间；二是有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；三是数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；四是因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；五是对大多数事务(Transaction)而言，运行性能好；六是物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。
在基本表设计中，表的主键、外键、索引设计占有非常重要的地位，但系统设计人员往往只注重于满足用户要求，而没有从系统优化的高度来认识和重视它们。实际上，它们与系统的运行性能密切相关。现在从系统数据库优化角度讨论这些基本概念及其重要意义：
（1）主键(Primary Key)：主键被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个表只有一个主键。主键应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用（众所周知）的列作为主键才有意义。短主键最佳（小于25bytes），主键的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成，自然主键可以是复合性的，在形成复合主键时，主键列不能太多，复合主键使得Join*作复杂化、也增加了外键表的大小。人为主键是，在没有合适的自然属性键、或自然属性复杂或灵敏度高时，人为形成的。人为主键一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外键的表的大小。
（2）外键（Foreign Key）：外键的作用是建立关系型数据库中表之间的关系（参照完整性），主键只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外键。
（3）索引(Index)：利用索引优化系统性能是显而易见的，对所有常用于查询中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，这样减少数据存取时间；利用索引可以优化或排除耗时的分类*作；把数据分散到不同的页面上，就分散了插入的数据；主键自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；索引码越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和Update*作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的数据页按物理有序储存，占用空间小。选择策略是，被用于Where子句的列：包括范围查询、模糊查询或高度重复的列（连续磁盘扫描）；被用于连接Join*作的列；被用于Order by和Group by子句的列。聚族索引不利于插入*作，另外没有必要用主键建聚族索引。
② 非聚族索引（Nonclustered Index）：与聚族索引相比，占用空间大，而且效率低。选择策略是，被用于Where子句的列：包括范围查询、模糊查询（在没有聚族索引时）、主键或外键列、点（指针类）或小范围（返回的结果域小于整表数据的20%）查询；被用于连接Join*作的列、主键列（范围查询）；被用于Order by和Group by子句的列；需要被覆盖的列。对只读表建多个非聚族索引有利。索引也有其弊端，一是创建索引要耗费时间，二是索引要占有大量磁盘空间，三是增加了维护代价（在修改带索引的数据列时索引会减缓修改速度）。那么，在哪种情况下不建索引呢？对于小表（数据小于5页）、小到中表（不直接访问单行数据或结果集不用排序）、单值域（返回值密集）、索引列值太长（大于20bitys）、容易变化的列、高度重复的列、Null值列，对没有被用于Where子语句和Join查询的列都不能建索引。另外，对主要用于数据录入的，尽可能少建索引。当然，也要防止建立无效索引，当Where语句中多于5个条件时，维护索引的开销大于索引的效益，这时，建立临时表存储有关数据更有效。
批量导入数据时的注意事项：在实际应用中，大批量的计算（如电信话单计费）用C语言程序做，这种基于主外键关系数据计算而得的批量数据（文本文件），可利用系统的自身功能函数（如Sybase的BCP命令）快速批量导入，在导入数据库表时，可先删除相应库表的索引，这有利于加快导入速度，减少导入时间。在导入后再重建索引以便优化查询。
（4）锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则Server的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。
（5）查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询*作。经验告诉我们，在优化查询时，必须做到：
① 尽可能少的行；
② 避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中*作；用简单的键（列）排序，如整型或短字符串排序；
③ 避免表内的相关子查询；
④ 避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符串连接；
⑤ 在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接；
⑥ 利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。
除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序。
3 基本表扩展设计
基于第三范式设计的库表虽然有其优越性（见本文第一部分），然而在实际应用中有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表，许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程从多表获取数据时引发大量的连接*作，当数据来源于多表时的连接*作；这都消耗了磁盘I/O和CPU时间。
尤其在遇到下列情形时，我们要对基本表进行扩展设计：许多过程要频繁访问一个表、子集数据访问、重复计算和冗余数据，有时用户要求一些过程优先或低的响应时间。
如何避免这些不利因素呢？根据访问的频繁程度对相关表进行分割处理、存储冗余数据、存储衍生列、合并相关表处理，这些都是克服这些不利因素和优化系统运行的有效途径。
3.1 分割表或储存冗余数据
分割表分为水平分割表和垂直分割表两种。分割表增加了维护数据完整性的代价。
水平分割表：一种是当多个过程频繁访问数据表的不同行时，水平分割表，并消除新表中的冗余数据列；若个别过程要访问整个数据，则要用连接*作，这也无妨分割表；典型案例是电信话单按月分割存放。另一种是当主要过程要重复访问部分行时，最好将被重复访问的这些行单独形成子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但在分割表以后，增加了维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。
垂直分割表（不破坏第三范式），一种是当多个过程频繁访问表的不同列时，可将表垂直分成几个表，减少磁盘I/O（每行的数据列少，每页存的数据行就多，相应占用的页就少），更新时不必考虑锁，没有冗余数据。缺点是要在插入或删除数据时要考虑数据的完整性，用存储过程维护。另一种是当主要过程反复访问部分列时，最好将这部分被频繁访问的列数据单独存为一个子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但这增加了重叠列的维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。垂直分割表可以达到最大化利用Cache的目的。
总之，为主要过程分割表的方法适用于：各个过程需要表的不联结的子集，各个过程需要表的子集，访问频率高的主要过程不需要整表。在主要的、频繁访问的主表需要表的子集而其它主要频繁访问的过程需要整表时则产生冗余子集表。
注意，在分割表以后，要考虑重新建立索引。
3.2 存储衍生数据
对一些要做大量重复性计算的过程而言，若重复计算过程得到的结果相同（源列数据稳定，因此计算结果也不变），或计算牵扯多行数据需额外的磁盘I/O开销，或计算复杂需要大量的CPU时间，就考虑存储计算结果（冗余储存）。现予以分类说明：
若在一行内重复计算，就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器更新这个新列。
若对表按类进行重复计算，就增加新表（一般而言，存放类和结果两列就可以了）存储相关结果。但若参与计算的列被更新时，就必须要用触发器立即更新、或存储过程或应用代码批量更新这个新表。
若对多行进行重复性计算（如排名次），就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器或存储过程更新这个新列。
总之，存储冗余数据有利于加快访问速度；但违反了第三范式，这会增加维护数据完整性的代价，必须用触发器立即更新、或存储过程或应用代码批量更新，以维护数据的完整性。
3.3 消除昂贵结合
对于频繁同时访问多表的一些主要过程，考虑在主表内存储冗余数据，即存储冗余列或衍生列（它不依赖于主键），但破坏了第三范式，也增加了维护难度。在源表的相关列发生变化时，必须要用触发器或存储过程更新这个冗余列。当主要过程总同时访问两个表时可以合并表，这样可以减少磁盘I/O*作，但破坏了第三范式，也增加了维护难度。对父子表和1：1关系表合并方法不同：合并父子表后，产生冗余表；合并1：1关系表后，在表内产生冗余数据。
4 数据库对象的放置策略
数据库对象的放置策略是均匀地把数据分布在系统的磁盘中，平衡I/O访问，避免I/O瓶颈。
⑴ 访问分散到不同的磁盘，即使用户数据尽可能跨越多个设备，多个I/O运转，避免I/O竞争，克服访问瓶颈；分别放置随机访问和连续访问数据。
⑵ 分离系统数据库I/O和应用数据库I/O。把系统审计表和临时库表放在不忙的磁盘上。
⑶ 把事务日志放在单独的磁盘上，减少磁盘I/O开销，这还有利于在障碍后恢复，提高了系统的安全性。
⑷ 把频繁访问的“活性”表放在不同的磁盘上；把频繁用的表、频繁做Join*作的表分别放在单独的磁盘上，甚至把把频繁访问的表的字段放在不同的磁盘上，把访问分散到不同的磁盘上，避免I/O争夺；
⑸ 利用段分离频繁访问的表及其索引（非聚族的）、分离文本和图像数据。段的目的是平衡I/O，避免瓶颈，增加吞吐量，实现并行扫描，提高并发度，最大化磁盘的吞吐量。利用逻辑段功能，分别放置“活性”表及其非聚族索引以平衡I/O。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活。
参考资料：http://www.xiaotianya.com/read-7-2026-1.html