优化心得一二

本月斩鬼（心）中，事情多了点是一回事，blog写一段存一段草稿，想起来的时候没时间继续，有时间的时候又不记得了，月底争取补齐。。。

这个月终于把上个项目的所有扫尾工作搞定了，出去happy了一次，压抑了太久时间，啤酒喝道吐。。。

废话不罗嗦了，进入正题

优化的本质就是提高访问速度，当然这里讲的优化是客户所谓的优化，本文仅讨论这个方面

客户不会关心系统的架构有多么的优秀，使用的技术有多么的先进成熟，他们最在乎的就是在可控成本内最大限度的满足用户体验。换句话说，在空间允许的条件下，合理搭配系统资源，提高响应速度才是开发人员应该追求的东西（此处强调合理二字，下文会解释）。

下面来看看几个优化的例子：

优化示例1：负担转嫁

背景：数据库info表中有8W多条信息，信息自带一个short的标记位，此标记位被解析成了15个bit位（符号位除外），其中使用了前8个bit作为类型标记（每个信息只能有1个标记为为1），最后一个bit作为状态（1为有效）。系统的首页要显示info的8个类型（即short的前8个标记位）的有效信息各5条（共40条）

原始方案：此方案仅仅实现了这40条信息的读取，使用存储过程访问8次info表，抽取各标记位有效数据前5条，然后汇总到结果集返回。系统在测试的时候发现首页的访问速度很低下，尽管在相关列上加了索引和统计信息，但是性能提升并不明显

改进方案：考虑首页的大访问量，新建了一个物理表，包含首页显示的信息所需要的所有字段，每当首页的信息改变时，由存储过程向此物理表重新填充数据，然后首页访问时直接从此物理表中抽取数据显示。

改进评论：此处优先考虑了大访问量数据的流畅性，牺牲了一定物理空间，且因为信息更改标记位时需要重新装载首页信息，此处牺牲了一定的效率。从整体上来讨论可以认为将首页访问需要耗费的时间转嫁到了更改信息标记位的操作上，但首页访问的频繁度比修改信息标记位高，且前者对响应速度的要求比后者高，总体认为此改进是合理的。

总结：在任何时候都需要保证高访问量的页面的绝对效率，条件允许的话可以牺牲某些低访问量的页面的效率

优化示例2：空间换时间

背景：数据库中有一个目录表dir,此目录表描述了一个层级架构（类似windows资源管理器），包含key、name、parentKey、level四个基本属性。系统中有一个目录浏览的页面，在浏览目录的时候，需要显示当前目录的完整路径（如：我的电脑-C盘-windows-System），其路径中的各级目录名称实际上是可以点击的超链接（点击后进入相应目录）

优化后的设计思想：其实目录表中本来是没有level的，加入level后，极大的方便了另外一个操作

预备知识：sqlserver2005、db2 v8数据库都提供了with，这个东西最大的好处就是可以做递归运算，这里不详细介绍

最终实现方式：

1.使用with建立视图，包含以下列：key、name、parentKey、Level、完整路径的id序列，排序方式为 level asc

2.在application_start 里从上述视图抽取信息

3.接2，将key、name放入静态空间存储（使用struct），并自带linkedlist<struct>用于索引目录链（此处即体现了level存在的意义：因为level是从小到大，所以在最初的时候，完整路径序列中只有根节点的key，在level增加的时候，首先有当前的节点，然后才有完整序列。

例如：

key0、我的电脑、null、0、key0

key2、D盘、key0，1，key0|key2

key6、programfiles、key2、2、key0|key2|key6

当处理到key2时，已经能从静态空间读取到key0的信息；处理到key6时，已经能读取到key2的信息）

4.在每次要使用完整目录名称时，传入一个PlaceHolder和目录的key，由工具方法负责从Hashtable中由key查找到linkedlist，然后从linkedlist抽取struct渲染PlaceHolder

总结：一个牺牲空间换时间的优化案例，增加了数据库冗余和内存的开销，但是可以快速获得目录链

优化示例3：数据库访问（sqlserver2005 以上版本）

前提：其实这个示例所描述的问题是最早碰到的，但是它解决的问题却是很多时候没办法全面解决的

背景：系统中有好几个页面访问涉及多表的n对m的表连接，造成系统访问效率的及其低下。这个问题其实是在第一次大数据量测试的时候发现的（这个测试很重要），在多表的多对多连接查询时直接超时死机

基本方案：（不是原始方案，是在固有条件下所必须的策略）sql的优化

      1.使用inner join代替left join,表连接时，需从能反映最终结果集行数的表开始操作

      2.对于所有的做连接的字段，必须是fk、pk

      3.对于大表连接的条件列，必须做索引

 基本方案对业务逻辑的作用不是很明显，这里只能用外部手段了

优化方案：开启sql profiler，将系统运行一段时间（随便点，保证所有的操作都被点击两次以上），保存运行文件，打开“数据库引擎优化顾问”，选择分析文件，然后会发现一大堆系统建议。注意此时不要盲目的将所有建议生效，先大致浏览一下建议的内容。此步骤优化之后系统效率一般会有很大提升，而且不需要很高级的数据库理论基础

（额外说明：当然每个项目中都会有sql的强人，但是这种优化是建立在对数据库本身和项目的深层次理解的基础之上，既然是能够节约时间的工具，那就应该去了解）

关于优化的总结：对于客户来说，客户最关心系统的负载和效率，这也要求我们在很多时候需要从速度出发去考虑问题，而不是考虑如何把代码写得自己看得舒服（虽然说这也是优秀的代码的要求的一部分，但是当二者的利益冲突时，就必须考虑解决方案了）。之前看过一个经典的例子，在程序中大量运用了反射。代码写的简单、整洁，但是运行效率很差，尤其是多路并发的时候。后来把代码改成非反射后，差不多可以接受了。可以遵循20/80原则去优化系统。虽然出发点不同，但是终点都是一样的，条条大路通罗马，问题在于路好不好走而已