我的第一份外包经历及所得（转）

今年的6月份,我找到了我现在的公司,还不错,公司性质是软件外包,我也非常兴奋的来到了我的第一个客户工作。外包的人员和客户公司内部的人员当然在分工上会有很多不同的地方，因为外包人员是有时间的，所有不会安排特别费时，而且熟悉起来特别难的模块，所以要想学习客户环境中的优点，就要靠自己的努力了，这里我说下我这6个月的所得。

6月份之前我的工作都不是特别固定，二年半的时间换了三家公司，可以说一年一次吧。当中的原因我就不多说了，家家有本难念的经。回想在客户这边的6个月，收获那是一个大啊，个人认为,嘿嘿。

第一：数据库优化方面的进步；

记的在面试的时候，有很多面试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%左右。

第二：索引视图需要额外的系统开销，比起提高的性能，作用不明显。

3：应用include是我从DBA翻译的SQL2005技术内幕中发现的，它让我知道了什么叫覆盖索引。

总之上面就是我的第一次SQL优化经历，在工作过程中写下来十多篇关于数据库的文章，下面再次厚着脸皮show一下。

1:SQL2005性能分析一些细节功能你是否有用到?

2:SQL2005性能分析一些细节功能你是否有用到?(二)

3:SQL2005性能分析一些细节功能你是否有用到?(三)

4:SQL开发中容易忽视的一些小地方(一)