数据库设计参考--收藏转帖

 审核索引的使用情况不是一件容易的任务，但对于你服务器的性能来说是紧迫的 。例如，怎样去审核超过1500个表的数据库的索引？审核单个索引相对简单些，审核多个数据库里的成千上万个索引就不是一件容易的任务了。不管这项任务是否容易，对于优化SQLServer数据库的性能来说却是重要的。

        在着手处理大量索引的审核时有两个不同的方法。一个是分成更小的更容易管理的单元，首先着眼于那些最可能影响SQLServer性能的索引。例如，你可以在你服务器最忙的数据库上启动审核，如果它有很多表，首先从最多数据的那些表开始，然后逐步到那些少一点的表。这样，你将在那些最可能有很大实际影响服务器性能的地方看到最初的成就。

       另一个方法，也是我通常使用的方法（因为我有点懒），就是使用排除法。我的意思是如果看不到数据库的任何性能问题，就不必要评估数据库的每一个索引。但如果数据库显示正好存在性能问题，那么对那些不是最优的索引来说是一个好的调优机会，特别注意它们，尤其在数据库任务紧急的时候。如果有大量的索引要审核，那么先从最大的入手，因为它们最可能引起性能问题。例如，在有1500个表的数据库里，我仅仅小心的审核大约一打的表（都是很大的表），我认为它们应该受到最多的关注。 

       当你决定审核你所管理的数据库的索引的时候，你需要拿出合理的计划并系统地实现。 

        正如你已经看到的，我上面提供的审核列表不是很长。这是故意的。记住，这一系列关于性能监控的文章的目的是为了分辨容易和显而易见的性能问题，不是找出全部。上面列出来的将使你走很长的路去分辨和纠正容易的与索引相关的性能问题。一旦你掌握了它们，就可以更上一层楼了。例如，本网站上有很多索引相关的提示，大部分都很高级，比如下面的主题：

普通索引
聚集索引
复合索引
覆盖索引
非聚集索引
重建索引
索引调优向导
如果你还没有做过的话，你需要复习这些提示的网页。

你最近运行过索引调优向导吗？

微软在SQLServer7.0和2000里给我们最好的工具就是之一就是索引调优向导。它不是一个完美的工具，但它确实能帮助你分辨存在的索引是否正被使用，同时提供能加快查询的新索引。如果你正使用SQLServer2000，它也能推荐索引视图的使用。它使用目前你正在数据库里运行的查询，所以它的建议是基于你数据库是真正怎么使用的。它用来分析所需的查询来源于你用SQLServer事件探查器创建的跟踪。

当在一个新的SQLServer上进行性能审核时我做的第一件事就是在捕捉到的服务器活动的跟踪上运行索引调优向导。大多数情况下，它能帮助我快速的分辨出任何一个不被使用的可以被删掉的索引，分辨出为了提升数据库性能需要新建的索引。

这里有一些对于在使用索引调优向导审核SQLServer数据库索引时的提示：

当你在使用事件探查器捕捉数据时（索引调优向导用来分析性能），选择一天中数据库正常负荷的具有代表性的时段。我通常喜欢选择在上午或者下午3点，然后运行事件探查器跟踪至少一个小时以上。
一旦事件探查器跟踪完，索引调优向导可以随时运行。但是，一个好的想法是在数据库一段时间不忙的最适宜的时候运行，这是因为使用索引调优向导进行性能分析时会影响服务器的一些性能，既然不必要，对服务器性能产生负面影响就毫无意义。也要避免在产品服务器上运行分析（向导仍不得不连接到产品服务器），当执行分析的时候在另一台服务器上运行向导可以减少产品服务器的负载。
尽管要花费更多的时间去完成分析，你需要在索引调优向导的几个选项的设置期间列一个清单来帮助进行彻底的分析。这些包括：不要选择"Keep all existing indexes"（保留所有现有索引），因为你要分辨哪些索引没有用;指定你要进行"Thorough"（彻底的）分析，而不是"Fast"（快速）或者 "Medium"（适中）;不要选择"Limit the number of workload queries to sample"（将要抽样的工作负荷查询的数目限制为）选项，保留"maximize columns per index"（每个索引的最大列数）设置的最大设置为16;选择所有被用来调优的表。通过选择这些选项，索引调优向导将进行彻底的工作，尽管要花费几个小时才能完成，这依赖于跟踪文件的大小和你执行分析的硬件的速度。注：这些只针对SQLServer2000，SQLServer7.0稍微有些不同。
一旦分析完成，向导也许没有任何建议，也许建议删除一个或更多的索引，或者建议添加一个或更多的索引，或者建议既添加也删除。你需要在采纳建议之前小心评估它们。例如，向导也许建议删除一个特殊的索引，但你知道该索引是真正需要的。那么当你知道这不是一个好想法可为什么向导建议删除呢？这是因为向导没有分析在跟踪文件（仅仅是一个抽样而已）里发现的每一个查询，加之你的抽样跟踪数据可能没有包括需要那个索引的查询。这种情况下，向导也许建议删除该索引，即使这不是一个好的建议。一旦你检查到一个索引是不需要的，你应该删除它。
如果向导建议添加新的索引，那么你要评估它们，也要和目前表上存在的索引比较看看它们是否有意义，会不会引起潜在的新的问题。例如，一个建议的索引或许能帮助一部分查询，但它也可能降低每小时成千上万次的INSERT操作。向导不知道这些，你必须决定哪个更重要，一些查询运行快了点而INSERT去慢了，反之亦然。
最后，即使索引调优向导没有任何新索引的建议，这也不意味着新索引是不需要的，仅仅根据跟踪数据来分析可能不会有任何建议。为了更好的帮助分辨出需要的索引。你要考虑好几天运行多个跟踪以便得到更多的抽样数据。即使那样，索引调优向导也不能找出全部需要的索引，但它将找出所有显而易见需要的索引。
一旦你完成分析并根据建议做出了更改，我建议你再次跟踪分析以便看看你的更改是否有效果。谨记索引调优向导分析不是一蹴而就的事情。随着时间的推移数据库的数据发生了潜在的变化，随着一起变化的还有查询的类型。所以，作为一个要点：定期的对服务器进行跟踪和分析以保持定期的优化。?

 每个数据库的每个表都有聚集索引吗？

首要的原则是每个表都应该有聚集索引。聚集索引通常但不总是应该建在单调递增的一列上如自增列，或者其他的值是递增并唯一的列上。大多数情况下，主键是作为聚集索引理想的列。

如果你曾经调优过SQLServer6.5的性能，你也许听说在单调递增列上创建聚集索引不是一个好的方法，因为它可能由于磁盘的"hotspot"（热区）引起性能问题。那个建议在SQLServer6.5中是正确的。

在SQLServer7.0和2000中，"hotspots"通常不是问题了。只有在每秒超过1000个的事务的情况下，"hotspot"才对性能有负面的影响。事实上，"hotspot"在这些环境下是有用的，因为它消除了页拆分。

下面是原因。如果你正在向一个主键上建聚集索引的表里插入新的行，主键是单调递增的，这意味着每个INSERT将在磁盘上逐个的物理顺序出现，因此，页拆分不会发生，这本身就节省了资源。这是因为SQLServer有能力决定数据是否被插入到有单调递增序列的表里，如果是，就不会执行页拆分。

如果你正插入很多行到一个堆表（没有聚集索引的表）中，数据不会按任何特定的顺序插入到数据页，不管数据单调递增与否。这样当从磁盘上访问数据时， SQLServer会花费更多的读操作。另一方面，如果给表添加聚集索引，数据被顺序的插入到数据页上，通常在读取数据时花费更少的磁盘I/O。

如果数据被插入到一个或多或少有随机顺序的聚集索引里，数据通常是随机的插入到数据页里，就象堆表一样，会发生页拆分。

那么说回来，为了全面的提升性能，最好的建议就是在一个单调递增列（假定有一列是符合条件的）上添加聚集索引。如果表上有很多INSET、 UPDATE和DELETE操作更是应该这样。但如果表的更改很少，大部分是SELECT语句，那么这个建议就不是很有用，为聚集索引考虑其他的选择。

作为索引监控的一部分，检查看看数据库里每个表是否都有索引。如果根本没有索引，认真的考虑给添加一个聚集索引，参考上面的建议。事实上给表添加一个聚集索引不会比没有聚集索引时引起性能下降。?

每个表的任一列是否被多次索引?

听上去这个建议是显而易见的，但它比你认为的要普遍得多，特别是多个DBA每人管理一段时间的数据库。SQLServer不关心你是否这样做，只要索引的名称不同它就认可了。所以当检查表目前的索引时，看看是否有列在不必要的重复索引中。删除它们不仅能节约磁盘空间，也能加快对表数据的访问和修改。?

重复索引的一个通常例子就是忘记了列上有主键，或者列是唯一的，这样列上会自动创建索引，可是又在上面以不同的索引名称创建了索引。

查询里是否有没有被使用的索引?

这里有另外一个显而易见的建议，但也是一个普遍的问题，特别是在数据库正式启用以前DBA或开发人员猜测的为数据库创建的最初的那些索引。仅仅看看表的索引不会告诉你这些索引是否有用，所以分辨没用的索引通常是不容易的。

分辨没用的索引的最好途径是使用索引调优向导，前面讨论过。

不必要的索引，象重复索引，既浪费磁盘空间又对数据的访问修改的性能没有多大的好处。?

索引是否太宽?

索引越宽，明显地就变得越大，访问或修改数据时SQLServer就不得不做更多的操作。因此，你应该避免在太宽的列上添加索引。索引越窄，性能越快。

另外，复合索引，包括两个或更多的列，也可能出现同样潜在的问题。通常要尽可能的避免复合索引。数据库使用复合索引越多，常常意味着数据库的设计有缺陷。

不可能总是避免宽索引或复合索引，但不得不用时，确信对你的选择做过仔细的评估并且没有其他的办法帮助提高性能。?

连接的表的连接列上是否有适当的索引?

基本上，为了最好的性能，表里用来连接的列上都应该建索引。这是直接了当的建议，也是相当显而易见的，但为了最优的JOIN性能监控索引却是不容易的，因为为了全面的性能监控你必须熟悉数据库里所有执行的连接。

当创建主外键关系（通常用来JOIN的）时，很多人都忘记了主键列上会自动创建索引而外键列上不会自动创建，外键列上必须手动创建。

由于经常忘记，作为监控的一部分，你要分辨出表的所有主外键关系并检查每一个外键列上是否有正确的索引。

除此之外，你也能使用索引调优向导帮助分辨出丢失的连接索引，但我发现向导不总是能为连接表分辨出丢失的索引。说穿了，除非你知道数据库里通常运行连接的类型，否则是很难分辨出索引建在哪些列上能获得帮助。


索引是否足够唯一到有用？

仅仅因为一个表有一个或更多的索引并不意味着SQLServer查询分析器会用到它们。在它们被使用之前，查询优化器不得不考虑它们是否有用。如果表的列上不是至少有95％是唯一的，那么查询优化器最可能不用这个列上的非聚集索引。因此，不要给那些没有95％唯一值的列上添加非聚集索引。例如，一个只有"yes"和"no"的列上不是至少95％都是唯一的，在这列上创建索引基本上永远不会得到使用，我们已经知道这对性能有很大的拖累。

作为监控的一部分，考虑在表上目测数据。换句话说，查看表里的数据，再看看索引的那些列。通常，列是否可选来做索引是非常显而易见的。如果你注意到数据都是男或女，是或否等等，那么这些数据不可选来做索引，并且它们上面的任何索引都将浪费空间并影响性能。?

覆盖索引是否带来了好处？

覆盖索引是复合索引的一种形式，包括查询里SELECT、JOIN、WHERE语句引用的所有的列。因此，索引包含了你要查询的数据， SQLServer不必去表里查找实际的数据了，这样减少了逻辑或物理I/O，从而提升性能。当非覆盖的复合索引不能提升性能时，覆盖索引就派上用场了，大多数情况下，它确实能提升查询的性能。

分辨出覆盖索引在什么地方最有用是很困难的。虽然索引调优向导能有所帮助，但它仍会丢失大量的找到覆盖索引有用的地方的机会。另外，唯一的方法就是小心检查你数据库里运行的所有查询，当然这几乎是不可能的，除非你真的有时间且没有其他更好的事情去做。

在这点上，你监控的目的本身不是找出新的覆盖索引，而是理解它们以便你在你的环境里遇到它们有用的地方时能从中获得好处。?

索引重建的频率是多少？

随着时间的推移，索引会出现碎片，这会引起SQLServer访问它们时降低性能。唯一的解决方法就是定期整理数据库里所有索引的碎片。有几种不同的方法来整理，怎样去整理不会在这儿讨论，这个在SQLServer的帮助文档里有，本网站以后也会介绍。

你监控的目的是找出正在监控的数据库的索引是否在定期的整理碎片。整理碎片的频率从每天每周到每月不等，依赖于修改的频率和数据库的大小。如果数据库每天要进行很多修改，那么碎片整理应该更频繁的执行。如果数据库很大，这意味着碎片整理要花更长的时间，因此由于碎片整理过程占用太多的资源从而影响用户的使用，所以不能太频繁的整理碎片。作为监控的一部分，你要评估碎片产生的频率，找到最佳的频率。

至少，如果索引目前没有重建，而它们又需要重建，作为监控的一部分，你需要确认一些适当的索引重建计划。

索引的填充因子是多少？

和索引重建最相关的是填充因子。当创建一个新索引，或重建一个存在的索引时，你可以指定一个填充因子，它是在索引创建时索引里的数据页被填充的数量。填充因子设置为100意味着每个索引页100％填满，50％意味着每个索引页50％填满。

如果你创建一个填充因子为100的聚集索引（在一个非单调递增的列上），那意味着每当一个记录被插入（或修改）时，页拆分都会发生，因为在现存的页上没有这些数据的空间。很多的页拆分会降低SQLServer的性能。

举个例子：假定你刚刚用缺省的填充因子新创建了一个索引。当SQLServer创建它时，它把索引放在相邻的物理页面上，因为数据能够顺序的读所以这样会有最优的I/O访问。但当表随着INSERT、UPDATE、DELETE增加和改变时，发生了页拆分。当页拆分发生时， SQLServer必须在磁盘的某处分配一个新的页，这些新的页和最初的物理页不是连续的。因此，访问使用的是随机的I/O，而不是有顺序的I/O，这样访问索引页会变得更慢。

那么理想的填充因子是多少呢？它依赖于应用程序对SQLServer表的读和写的比率。首要的原则，按照下面的指导：

低更改的表（读写比率为100：1）：100％的填充因子

高更改的表（写超过读）：50-70％的填充因子

读写各一半的：80-90％的填充因子

在为应用程序找到最优的填充因子前也不得不进行试验。不要假定一个低的填充因子总比高的好。低的填充因子会减少页拆分，它也增加了SQLServer查询期间读的页数量，从而减少性能。太低的填充因子不仅增加I/O开销，也影响缓存。当数据页从磁盘移到缓存中时，整个页（包括空的空间）都移到缓存中。所以填充因子越低，不得不移到SQLServer缓存中的页面就越多，意味着同时为其他重要数据页驻留的空间就少，从而降低性能。

如果你没有指定填充因子，缺省的填充因子时0，意味着100％的填充因子（索引的叶页100％的填满，但索引的中间页有预留的空间）。

作为监控的一部分，你要决定新建索引或重建索引时的填充因子是多少。事实上，除了只读数据库，所有的情况，缺省值0都是不适合的。你想要一个填充因子保留合适的自由空间，按照上面的方法来做。

 

 

基于第三范式的基本表设计

　　在基于表驱动的信息管理系统（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。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活