怎么选择键呢？以及如何索引字段以获得最佳性能
1.  数据采掘要预先计划
我所在的市场部门一度要处理8万多份联系方式，同时填写每个客户的必要数据（这绝对不是小
活）。我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候，我试图不
在主索引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘
既不准确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发现有一个指示计划相
当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢？我可以用传真号码
进行检索，但是它几乎就象系统类型一样对我来说并不重要。采用后者作为主字段，数据库更新
后重新索引和检索就快多了。

可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数据索引是有差别的。在DW环境
下，你要考虑销售部门是如何组织销售活动的。他们并不是数据库管理员，但是他们确定表内的
键信息。这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间
的最佳条件。

2.  使用系统生成的主键
这一天类同技巧1，但我觉得有必要在这里重复提醒大家。假如你总是在设计数据库的时候采用
系统生成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就
有效地控制了对存储数据中每一行的访问。
 
采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易。

3.  分解字段用于索引
为了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组
成要素以便用户可以对其进行索引。索引将加快SQL和报表生成器脚本的执行速度。比方说，
我通常在必须使用SQL LIKE表达式的情况下创建报表，因为 case number字段无法分解为
year、serial number、case type和defendant code等要素。性能也会变坏。假如年度和类型字
段可以分解为索引字段那么这些报表运行起来就会快多了。

4.  键设计4原则
  为关联字段创建外键。
  所有的键都必须唯一。
  避免使用复合键。
  外键总是关联唯一的键字段。

5.  别忘了索引
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到
解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用
唯一的非成组索引，对任何外键列采用非成组索引。不过，索引就象是盐，太多了菜就篌了。你
得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。

大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比
如运行查询显示主表和所有关联表的某条记录就用得上。还有，不要索引memo/note字段，不
要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。

6.  不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和
删除操作的索引维护可能比扫描表空间消耗更多的时间。

7.  不要把社会保障号码（SSN）选作键
永远都不要使用SSN作为数据库的键。除了隐私原因以外，须知政府越来越趋向于不准许把
SSN用作除收入相关以外的其他目的，SSN需要手工输入。永远不要使用手工输入的键作为主
键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。

上个世纪70年代我还在读大学的时候，我记得那时SSN还曾被用做学号，当然尽管这么做是非
法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增
加，我现在的大学校园正痛苦地从一大摊子数据中把SSN删除。

8.  不要用用户的键
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要
选择用户可

[1] [2] 下一页