上周到昨晚，一直在维护服务器，只要一启动iis，即使关闭所有站点，都会出现远程断开，ping丢包的现象，装了一些第三方防火墙，连检查都没能检查出个啥，最后使用ip策略
开始---管理工具---- 本地安全策略---ip安全策略在本计算机----右键----所有任务----导入安全策略----选择 “rwIP策略.ipsec文件”
选中---分配 --ok
对普通开发人员来说经常能接触到上千万条数据优化的机会也不是很多，这里还是要感谢公司提供了这样的一个环境，而且公司让我来做优化工作。当数据库中的记录不超过10万条时，很难分辨出开发人员的水平有多高，当数据库中的记录条数超过1000万条后，还是蛮能考验开发人员的综合技术能力。
当然不是每个公司都能请得起专业的DBA，话又说过来专业的DBA也未必能来我们公司长期工作，这就不只是薪资待遇问题了还会涉及到人家的长期发展规划了，当然我也不是专业的DBA，本着能把问题解决好就是好猫的理念。
我们先看图，数据库中的记录数如下：记录数为10581490条同时还需要从另外一个表读取7万多条数据。
页面运行效果如下： 这是查看某个单位的数据，每页显示16条、记录数1087292条、分页数为67956页。 
遇到的难题如下：
1：当客户用了几年后数据变得很庞大分页速度缓慢得要命几乎到了无法忍受的程度。
2：分页到最后一页时往往速度很慢会有死机现象出现，特别是记录条数很多时死机现象比较多。
那再讲讲，解决问题的方法步骤：
1：首先优化数据库、因为程序也很复杂一时也看不过来也不敢乱改，先从数据库字段类型优化开始入手会好很多。
先把数据库里的 datetime 都修改为 smalldatetime，数据库变小了几百M很有成就感，最起码磁盘的读取压力减少不少吧。由于数据库数据有上千万条，无法用管理工具修改结构，只能用新建查询执行SQL命令才可以。
会有如下超时现象会发生。
那我们只能用执行查询的方式对表结构进行调整了，每次执行一个SQL指令大概需要10分钟时间才能顺利执行好，数据量实在是太大了。
2：接着再优化，数据库索引，原先的索引很乱可以理解为是乱来的所以我全部干掉重新进行了组织。
把多余的索引先通通干掉，然后重新建立索引，因为记录数太庞大了，有多余的索引会使数据库变大很庞大，给他先减轻减轻体重。
把主键设置为倒序的、非聚集的，这样的好处是可以把最新的数据排序在最前面。
把主要查询的条件设置为索引，Group By 的放第一个位置然后设置为聚集索引，这样的好处时查询时会快很多很多，普通所以没这个效率高，数据实在是太庞大了，超过了1000万条数据后，对比一下还是很明显的，都能感觉得到。
完成以上2个步骤后分页速度快了很多最起码没死机现象了， 还有一点遗憾是当数据量大时最后一页的分页速度还是有些慢，有些难以忍受的感觉，但是最起码不会死机了。
3：接着重点优化，数据库分页的存储过程，最后一页难以忍受的问题先解决一下。分页是用了 SELECT TOP N 的反转的方式，我把最后一页到底获取多少条记录准确数字计算出来，适当的修改了一下最后一页慢得死去活来的问题，得到了适当的环节，虽然没能彻底解决也速度明显快了一些，由于写的这个分页程序也有些复杂，我也不敢乱动，就把问题解决好就完事大吉的目的了，不去惹更多的麻烦了。
4：对比一下数据库结构优化后的前后如下图
索引优化前索引占用空间 2706.109M
索引优化后索引占用空间 520.805M
我想就这么一个1000w条记录的表光索引就优化了2200M空间，就单单这个也提高不少性能了。
5：接着重点优化，程序代码部分了，其实代码优化是在索引优化之前的，因为先读懂了代码、读懂了业务逻辑才好优化索引，这边文章写着写着顺序有些颠倒了，大家心里有数就可以了，我还是按照我的思路继续写吧。
在上图的企业编号、企业名称等，在程序里都进行了LIKE处理，当数据库记录超过1000万条时，对字符进行Like操作，那真是会要命的，毕竟那么多数据都进行一次匹配，虽然电脑的运算速度很快，但是上千万条记录，这么被计算过一下，能快到哪里去啊？
改进方法：
A: 输入企业编号、企业名称修改为模糊查询，能明确定位一个药店的名称。
B: 若已经获得企业编号了，不再匹配企业名称，而且企业编号用 = 来判断，并把企业编号进行索引。
海量数据库分页优化总结：
折腾了接近1周左右，终于把这个1千多万条记录的数据表给优化好了，难题也解决好了虽然不太科学也不专业也缺少理论依据、试验数据、图表对比、性能调试工具等等，但是还好把问题都解决好了，老鼠抓到了就是好猫咪了哈哈。
数据库进行了彻底的翻天覆地的优化、程序代码也进行了彻底的翻天覆地的优化后，分页速度飞快了。每页显示16条、记录数1087292条、分页数为67956页，每页分页速度都完全在3秒内，最后一页也不会死机了，也蛮快的足够可以忍受了。
等有空时，再把最后一页分页速度慢的问题再深入解决一下，先不去惹麻烦了稍微休息一下再说。
优化的每个动作需要10分钟左右才会执行好，若做错一次基本上就代表半个小时白忙乎了，还需要删除掉，再重新执行修正过的SQL语句，所以一天下来优化的成果并不会非常明显、需要几天时间才能优化好。
作为技术总监，如果只负责一个项目，那么他必须对整个项目了解度到100%，无一遗漏，哪怕只是下属发的工作文档里有提到。但是技术总监身兼多个项目，而且大小不一，需求五花八门，那么可以根据实际而定。
作为项目经理，对项目必须达到90%以上的了解度，从项目范围上来说包括项目的模块、功能、业务流程。从项目进度上来说需要制定项目的计划、阶段、可交付结果。从项目人员上来说包括每个成员所能负责的最合适的模块。从技术上来说包括项目的架构，层次，数据处理方式，采用的设计模式，主体功能，附属功能，用户体验质量层次。
作为项目组长仅次于项目经理的职位，对项目的了解也需要达到70%--90%的了解，当然我们可以理解一个大的项目可以分解为若干小项目。
记得公司招进一批人，正好公司也启动了一个项目，对于小企业来说算是一个大的项目，因为客户对质量的要求，没有立足在二次开发上，因为定制的特殊性，以及项目所包含各个平台的整合，所以从战略上来说采用原创，从战术上来说使用一些网上现成的demo。我这里说一下，战略就是大体方向，战术就是依靠经验以及临时灵活的解决方式来达到局部的OK。
我从中选择了一个工作3年的开发人员做项目组长，因为他在交谈上比较稳重，因为不是为了某个长期项目或者平台运营项目而招的人，所以在专业上我没有针对某个项目的特点来做要求。这样我对人员的各方面能力并不是十分了解，但是项目已经开启，而且我之前也对项目做了阶段性大概的工作内容以及移交结果说明。正好我又是一个身兼多个项目的CTO，在项目需求上我知道一些模块，以及模块主体的功能、流程、表现形式。在与下属（项目组长）做了几次初步的沟通，以及让其准备了开发需要的基础库，整理的项目的结构、层次、数据处理方式。接着我叫上了客户一起沟通，本想着项目组长可以和客户更细的沟通，然后完成我的计划。
但是问题出现了，项目有些大，而且个个模块的数据有关联，业务权限复杂，我可以说下包括百科、用户自主建站、导医服务、家庭医生、B2C、广告竞价、会员模块、CRM、健康档案、企业架构管理。要一下子了解并透彻整个项目的业务流程、细节等等可不是一朝一夕的事情，恐怕一个星期也很难整理，因为客户并不是专业的软件公司客户，他提出的需求是无层次的、无结构的、逻辑混乱的、甚至是随机因为思想改变的，所以花太多时间在项目范围的确定上并不能带来太大的帮助。
因为整个项目需求不完整，项目质量无界定，项目组长陷入了工作茫然状态，可以表现为：明明知道有很多事情要做，但是不知道先做什么，总感觉先做任何一件事情都觉得不妥或者觉得思路很乱。形成了无从下手的局面，即使我拟出了软件开发几个阶段以及交付物，因为模块与模块之间的管理使得项目组长无法确定某些细节在几个模块之间的影响。
同时也会出现零一个问题，眼看时间流逝，那么项目组长就着急了，他开始写一些基本的功能，例如登陆、注册、用户资料完善引导、企业资格审核、用户资格申请。做了大概40%的时候，项目组长发现自己在写这些功能的时候花在用户体验上的时间非常多，2天下来发现自己没写什么东西，但是自己确实也花了心思的，甚至会问我一些某些页面或着功能是不是做成用户体验很好的方式。
我立刻察觉到事情的严重性，这对我和项目组长来说，我们彼此都有责任，因为我忽略了他对我的短期工作交付，例如他的理解、计划、解决思路等等。所以我立刻让他停下了工作，让他把我第一阶段的工作内容了解透彻，然后让他把需求以分解的方式列了一份功能文档给我，并让他将业务流程整理给我，其中包括需要的字段名称都写出来。当然我叫他忽略用户体验的方式去分解任务，去计划工作阶段。然后我就这样让他花了两天时间把我计划的第一阶段工作任务做了熟悉之后，让他开始了代码开发工作，然后我施加了压力，需要他在规定的时间内完成第一阶段的任务。
可以这样简单的说，当技术总监给项目经理/组长分配任务的时候，一定要让项目经理/组长反馈一个工作计划给你，然后你根据这份计划开一个讨论会议，征求项目组的建议，同时适当做一些调整，让彼此知道自己应该做的工作，以及工作的质量要求。
鄙人个人工作经历简单介绍，若有总结有误，请高人指点。
质量、时间、成本这三者永远不会让你完全如意，不仅仅只表现在项目控制上，在项目工作分解分配上，根据自身工作复杂度来说，工作分解并非越细越好。
工作分解的越细，意味着你需要花更多的时间，除了工作分解工作力度带来的时间流失外，你还需要各个粒度的人员调配。当然能做到这样相当的好，证明你能把控得更好。但是管理与控制不仅仅只是你一个人的事情，你依旧可以讲管理与控制的工作分解给你的下属。比如说，你能很好的分解工作，然后分配给你的下属，让整个流程的风险系数降到最低，但是在一个很长的时间里，你也许做着类似 简单数据库操作代码编写 的工作，因为一部分的任务分解工作就是机械运动，即使你的工作内容变了，但是你的思想却没有转变到管理的角度。
可以这样理解，工作的执行以及工作管理控制，你将根据下属能力的级别以及你监控的频率来做不同的分解，当你发现时间不够的时候，你跳出来思考项目管理与控制的不同层面，你会发现，即使时间少，你依旧可以游刃有余。
所以工作的粒度你可以让你的下属来为你分解一部分并执行，项目的质量，时间，成本你依然可以让你的下属来为你执行一部分，而不仅仅只是你一个人孤军奋战，这也可以称之为：更好的发挥你所能控制的人力成本的价值。
想到这些，我很快的把服务器的维护工作交付到一个新人手里，即使新项目需求不完善的情况下，依然分配他们开展一些基础工作。
2012-03-03 （补 2012-02-24的感想）
今天去谈一个业务，大概1.5W的样子吧，说真的，我不太喜欢这样的小业务，业务我还不够淡定，但是为了锻炼自己，还是和客服MM一起去了。
地点在杨家坪，当然我是一个很强势的人，一开始认为自己能很风度霸气的解决业务交谈，并拿下资金这块的问题，可是我错了，客户永远是那么的刁钻，甚至不可理喻，对于客户没有道理的对与错，道理也不一定能全部解决你与客户之间存在的意见差异。
客户油盐不进，在针对首付款与二次付款上，我做了一些退让，同时对两次收款的款额都做了调整，客户依然不予退让。
借倒水的一个时间，联络了老总，老总说放弃业务。
但是在接下来的时间里，我犯了一个错误，那就是过于绝对，激动。我说：你可以找别的公司做推广的事情，建站这块如果可以，我们可以继续合作。
在接下来与客服MM的交谈中了解到，我已经把自己与对方的路划得太死了，可能就如我所说的定局。她提醒我说：“XX，关于这块我们的确很为难，我们先谈到这样，回去之后我们会考虑你的方案，同时也请XX你也考虑一下。”这样双方才有退路。
所以退路不一定只给自己留，有时候也要为对方留后路，留一个台阶下。
2012.03.01