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

 

   今年的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开发中容易忽视的一些小地方(一)

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

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

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

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

           9:如何应付表数据过大的查询问题?(如何尽量避免大表关联)

           10:怎样才能充分利用SQL索引

           11:select查询原理

           12:通用分页存储过程真的有注入漏洞吗? 

 

 

 

    第二:开发工具的应用,在开发时,有些小工具的应用往往会使你的工作带来非常大的效率提高,下面的推荐下我应用过的工具:

            1:nant工具,这是我在客户这边网站打包时应用的,它的应用可以看这篇文章。

                 小工具大智慧

            2:UE,文本编辑器,比起传统的记事本强多了。

            3:beyondCompare,文件比较器,文件的比较,非常精确。

            4:reg gate,SQL帮助工具。

            5:log4net,非常强大的日志组件,配置简单而且实用,强烈推荐。

                log4net日志组件经验分享

    第三:新技术的学习,后期我接触了一个应用了LINQ的站点,从而学习了不少LINQ基础知识,可以参考下面的文章。

            1:LINQ学习中关于null相关的问题及解决方案

            2:LINQ TO SQL中的selectMany

            3:LINQ TO SQL 中的join

            4:LINQ TO SQL 中的group

            5:LINQ TO SQL中的select

            6:转载:LINQ to SQL更新数据库操作

     第四:素质的提升,在客户中明白了这样的一句话:你帮助别人,你得到的会更多。客户这边的同事和领导那个态度好的没法说,什么不明白了非常乐意指点你。并不是每个人都是全才,我是一个变通的程序员,所以需要得到大家的帮助,同样我也有好的地方值得大家学习,哈哈。好好学习,天天向上。

     第五:多余的时间让我有空学习设计模式,因为我有一部分时间就是做网站打包,什么是网站打包,我就不说了,不太好说明白,这期间我学习的文章如下:

           1:老生常谈:代理模式

           2:老生常谈:组合模式

           3:老生常谈:模板方法模式

           4:老生常谈:建造者模式(设计模式到底离我们有多远)

           5:老生常谈:外观模式

           6:老生常谈:单件模式

           7:老生常谈:抽象工厂模式

           8:老生常谈:装饰者模式

     总结:在客户的半年,收获了不少知识和经验,和周围的同事积累了不少感情,人都是有感情的,外包到期了多少有点不舍之情,但路还是要走的,希望我们大家都能共同进步。
 

posted on 2008-12-25 13:38  min.jiang  阅读(10578)  评论(48编辑  收藏  举报