离，并在应用设计中完成对历史数据的相应处理功能（历史数据的剥离规则须经业务使用部门的确认）；
f索引的设计
索引是从数据库中获取数据的最高效方式之一。95的数据库性能问题都可以采用索引技术得到解决。但大量的DML操作会增加系统对索引的维护成本，对性能会有一定影响，对于插入相当频繁的表要慎重建索引，索引也会占相当的存储空间，所以要根据硬件环境和应用需求在空间和时间上达到最好的平衡点，主要原则：
适当利用索引提高查询速度：当数据量比较大，了解应用程序的会有哪些查询，依据这些查询需求建相应的索引；最好亲自试验一下，模拟一下生产环境的数据量，在此数据量下，比较一下建索引前后的查询速度；索引对性能会有一定影响，对于DML频繁列的索引要定期维护（重建）。但是，索引的结构对于索引的更新（比如在插入数据的时候）是有一定优化的，所以不要在没有试验以前过分夸大它对性能的影响。最终还是以试验为准；
要建实际用不上的索引，与上条相关，如果建的索引并不提高任何一应用中的查询速度，则要把它删除；有些数据库有相关工具可以发现实际未被使用的索引，可以利用一下；
索引类型的选择：要根据数据分布及应用来决定如何建立索引，一般的高基数数据列（高基数数据列是指该列有很多不同的值）时建立BTree索引（一般数据库索引的缺省类型）；当低基数数据列（该列有大量相同的值）时，可以考虑建立位图索引（如果所选数据库支持的话），但位图索引是压缩类型索引，所以DML（增、删、改）的代价更高，要综合考虑；
索引列的选择：如果检索条件有可能包含多列，创建联合主键或者联合索引，把最常用于检索条件的列放在最前端，其他的列排在后面；不要索引使用频繁的小型表，假如这些小表有频繁的DML就更不要建立索引，维护索引的代价远远高于扫描表的代价；
主键索引在建立的时候一定要明确的指定名称，不能让系统默认建立主键索引（可能有些数据库无法指定主键名，则例外）；
外键必须需建索引。当有一定数据量，并且经常以外键所在列为关联，进行关联查询时，需要建索引（可能有些数据库自动为外键建索引，则例外）；
当有联合主键或者联合索引时，注意不要建重复的索引。举例说明：
f表EMPLOYEES，它的主键是建立在列DEPARTID和EMPLOYEEID上的联合主键，并且创建主键的语句中DEPARTID在前，EMPLOYEEID在后。在这样一个表里，通常就没有必要再为DEPARTID建一个索引了；联合索引的情况也一样；
更复杂的情况，比如表r