索引是数据库系统重要的feature，无论是传统的关系型数据库还是时兴的NoSQL数据库，它攸关查询性能，因而在设计数据库时需要细加考量。然而，Lotus Notes隐藏技术底层，以用户界面为导向，追求快速开发的理念，使得“索引”鲜有开发人员提及，甚至了解。大家只论及视图，而当不同的人在不同的场合说“视图”时，所指各异。普通用户如果用视图一词，指的是显示一行行信息的列表；开发人员口里的视图，是数据库里的一类设计元素。这种设计元素，按照Lotus Notes的风格，将视图层的设计与数据层的定义混合在一起，前者例如列的字体、颜色、宽度；后者包括选择文档，提取字段和计算列内容，定义排序、分类、总计等等。如果单纯考虑Notes的数据库部分，后者的数据定义才是有关主题的。
Notes应用程序往往在使用了一段时间后，也就是在数据库变大，用户变多后，变得很慢。其中一个重要因素就是视图，打开应用程序、新建修改文档、执行代理都可能或明或暗地打开视图。这些时候，正是索引隐藏在视图背后影响着性能。
在主流开发所用的技术组合中，数据库是独立的一块，开发人员需用与编写业务逻辑时所用的语言不同的专业知识来设计和定义数据，所以才会衍生出专精于此的数据库管理员。在Lotus Notes应用程序中，数据库、业务逻辑和用户界面的开发紧密耦合，在大公司里虽然也有人专职维护服务器，部署和更新数据库，但是他们一般不会检查数据库的设计来优化性能。数据库的性能是程序开发人员的分内之事，而实际上，若非经验丰富的程序员，应用程序慢到很多用户无法忍受，性能在Notes程序员开发时，几乎不会被考虑。数据库慢只会被归咎于文档太多、附件太大、Notes数据库本来就如此。许多老程序员开发的应用程序里，同一类文档仅仅是为了分类顺序的不同就建了十来个视图，每个视图十多二十个列，六七列为分类，其它几乎全设置了排序。文档数量一旦增多，如此设计将严重影响性能，而在设计者眼里，只是为了方便用户并且是Notes便利性的证明。这样的视图设计和其功能滥用，当然责任不全在程序员身上，引导他们这样做的Notes的开发理念、帮助文档都难辞其咎。
说了这么长的开场白，现在就来讨论索引及其和应用程序性能的关系。先概括关系型数据库里的索引的作用，以作为Notes视图索引的对照。简单地说，索引就是在大量数据中为了快速查询建立的从数据中某些有用的信息到这些信息所在位置的映射。字典前面的拼音和部首检字表就是索引，更形象的例子是国外很多图书的末尾都附有的索引，可以此查到重要的词语出现的页码。数据库里的记录数量庞大，实际使用时又有找出符合各种各样条件的记录的需求。例如一个记录了一百万条人员信息的表，包含姓名、生日、性别、地址、电话号码等等信息。要从中找出姓赵的或者电话号码是26538941的人，如果没有特别的帮助，数据库系统只能逐行检查记录是否符合条件，找到一条记录平均所需读取和检查记录的数量是N/2（N为记录的总数）。如果从记录中提取电话号码字段，排序，并且每条号码指向对应记录在表中的位置，就建成了一个索引。此时再要查询电话号码是26538941的人，只需对索引应用二分查询算法，工作量就会减少到log2(N)的级别，再加上从定位的索引行确定和读取原始数据行的一次操作。另外，由于索引的每一行数据比原始记录的每一条要短很多，单次读取本身也更快。索引的负面影响则是空间和维护成本。索引的数据本身要占据空间，这很好理解。原始记录更新（新增、修改和删除）时，索引自然也要随着更新。索引的更新可以选择与原始记录同时、定时或者在用到索引也就是查询时再进行，但无论如何，与没有索引相比，都需要额外的计算。新增记录时，更新索引单纯是性能上的开销。修改和删除时，除非是对所有记录，否则都有选择条件，此时的索引正起到与查询时同样的帮助，而修改和删除后更新索引则是开销，因为前者的好处更大，所以合起来的效果一般对性能还是正面的（除非记录数量不大或者索引数量过多）。
在《从视图索引说Notes数据库（下）》里将接着详细讨论Notes视图索引。
原文地址：http://blog.csdn.net/starrow/article/details/40619221
