数据库优化（转载）
记的在面试的时候，有很多面试B/S的技术员都会问你是否在数据优化的经验，当时记的问我索引的分类，以及使用场合的主要区别，我当时实在没怎么用，所有 只能凭想象回答了几句。对索引的应用少是因为以前的公司数据量不大，很少遇到性能瓶颈的问题，还好在客户这边有这样一个机会，虽然是一个老系统，但数据那 是一个大啊，动不动就是上千万的，我想这下机会来了，正好由于业务需求的调整，要对原有查询逻辑做修改，这就要考虑重新创建聚集索引，和如何优化非聚集索 引的问题。
业务需求:按离开时间leaveDate，和订单状态:state来查询订单表orders同时关联会员表member，按离开时间leaveDate排 序,查询条件是：leaveDate,代理ID：proxyID，订单状态。两者数据量均在600百万以上，关联的条件为会员ID和代理ID，并创建了索 引。
表结构说明:
1:订单表，有大约十多个字段，其中包含:生成时间:createDate，离开时间leaveDate,会员ID等字段;会员ID，createDate上有联合聚集索引
2:会员表：字段大约三十以上,包含会员ID，代理ID等。 在会员ID和代理ID上创建了一个联合索引。
两表数据量说明:
1:订单表，1200万以上,且每天增加;
2:会员表：600万以上,变化速度不是太大。
我的第一个做法：因为查询中有一个order by "createDate"，所有我想在这个时间字段上创建聚集索引，但效果不明显;
我的第二个做法：因为条件中有一个"leaveDate"，所以在leaveDate上创建聚集索引，效果还行。
我的第三个做法：因为条件中有按订单状态来查询，何不把"leaveDate"和"订单状态"建立联合聚集索引呢，事实说明非常有效果；
我的第四个做法：因为订单表要和会员表关联，而这个会员表也不少，600百多万，这样大表关联，速度自然快不了，因为会员表字段特别多，而且数据量大，关 联时，只用到会员表的三个字段，会员ID，代理ID，会员的姓名，关联时的条件为会员ID和代理ID，自然在这两个字段上已经创建了索引。所有我想通过索 引视图来解决这个问题，创建一个只包含这三列的索引视图，发现效果一般；虽然数据列少了，但数据行还是那么多。
我的第五个做法：修改会员表的会员ID和代理ID的索引，应用SQL05的特性include把用户姓名包含进索引中，形成覆盖索引，这样一次索引查找就OK，这样做的好处就是改动最小，而且效果不错。
我的第六个做法：说服业务，将原来的排序"createDate"变成已经创建了聚集索引的"leaveDate"，节省了不少IO；
小结：经过我多次的强奸，终于有所成效，这其中的做法并不是我一个人想出来的。
1：其实第二个做法，在条件的"leaveDate"上创建聚集索引是园友zping告诉我的，当时我并不清楚聚集索引适用于这种可能存在重复键的列，只 知道自增的列适合创建聚集索引。因为我们比较习惯的利用自增的列当成主键，而这种情况下，主键就已经是一个聚集索引了。
2：放弃索引视图的做法是通过和客户这边的DBA讨论的结果，非常感谢DBA。理由如下：
第一：索引视图只缩小了列的数量，数据行还是没有减少的。所有效果不太明显，经我的证明，也就提高15%左右。
第二：索引视图需要额外的系统开销，比起提高的性能，作用不明显。
总之上面就是我的第一次SQL优化经历，在工作过程中写下来十多篇关于数据库的文章，下面再次厚着脸皮show一下。
11:select查询原理
第二：开发工具的应用，在开发时，有些小工具的应用往往会使你的工作带来非常大的效率提高，下面的推荐下我应用过的工具：
1：nant工具，这是我在客户这边网站打包时应用的，它的应用可以看这篇文章。
2：UE，文本编辑器，比起传统的记事本强多了。
3：beyondCompare,文件比较器，文件的比较，非常精确。
4：reg gate，SQL帮助工具。
5：log4net,非常强大的日志组件，配置简单而且实用，强烈推荐。
第三：新技术的学习，后期我接触了一个应用了LINQ的站点，从而学习了不少LINQ基础知识，可以参考下面的文章。第四：素质的提升，在客户中明白了这样的一句话：你帮助别人，你得到的会更多。客户这边的同事和领导那个态度好的没法说，什么不明白了非常乐意指点你。并不是每个人都是全才，我是一个变通的程序员，所以需要得到大家的帮助，同样我也有好的地方值得大家学习，哈哈。好好学习，天天向上。
第五:多余的时间让我有空学习设计模式，因为我有一部分时间就是做网站打包，什么是网站打包，我就不说了,不太好说明白，这期间我学习的文章如下：
转自 http://www.cnblogs.com/ASPNET2008/archive/2008/12/25/1361167.html
。