系统性能优化的心的.doc

系统性能优化的心的最近在找工作的时候，参加了一些面试（都是架构啊，项目经理之类的岗位），面试官的问题都会涉及到“大数据量的系统性能优化”，自己根据自己的经验简单阐述了些，今天回忆了下，感觉回答的不是很好，虽然曾经解决过很多类似问题。今天我总结下，大家交流下。我是走jee路线的，涉及的项目结构大致如下：不同之处就是使用的应用服务器，中间件的区别，我们这里将定应用服务，中间件的配置管理，以及架构的涉及和编码的实现都是在没有问题的环境下，系统出现了性能的瓶颈，常见的现象如下：v 客户点击一个按钮，要经过几分钟，几十分钟，甚至几小时（视不同的操作而定），才能看到预期的效果或者干脆没有结果（一直等待）或者直接去错误提示页面了。总之就是客户根本无法接受的响应速度。出现上述情况对客户来说是致命的，一般都会坚决要求开发人员或维护人员给予快速解决。这类问题的出现会严重影响客户对企业的技术能力的信任，尤其是当今信息化高速发展，各行业对IT有足够的认识的环境下。要解决问题，必须快速定位问题的根源，依据我的经验，问题一般出现在如下几个地方：1 客户端与服务的通讯过程 传递数据量大或解析传递的数据效率低（比如：WebService架构) , 一般通过压缩数据，更换解析数据工具或跟换数据传递方式可以解决问题。 Web服务器出现大量并发，导致服务器运行压力，这种情况一般要弄清楚并发的原因。访问量巨大，达到服务器处理阀值，一般可以通过如下手段解决：（1） 静动态页面分离或缓存静态（2） Web服务器集群（3） 硬件调整 由于业务处理缓慢，导致并发量大。这种情况是最为常见的。要解决这类问题 必须保证业务实现是快速执行的。业务逻辑的处理一般都是很长快速的，多数 问题都出现业务逻辑和数据库的交互上，具体的方式下面介绍。2 持久层与数据库的通讯过程 数据库驱动程序效率低下，更换响应的驱动程序或者直接使用数据库api来解决。 操作数据库时，传递的数据量过大，这种情况一般重新审视需求，更换处理方式来解决。比较常见的分页查询等3 数据库的内部运行这里是多数问题的根源，尤其是数据量巨大的情况下。多数的问题都是基础数据表大数据量的情况。由于商业系统大部分操作都会映射成对数据库的检索操作，主要体现就是如果快速从大数据量的基础表获取期望数据就成了解决该类的问题的根本。一般按两种情况来分别解决： （1） 基础表存储的数据量在数据库管理系统的承受范围内这类情况一般从两个角度去解决 A 使用索引对于索引的使用开发人员都不陌生了，但正确使用索引还真不是件容易的事，我们先来看下常见的索引，弄清楚索引的机制再使用，是很有必要的，至少俺是这么认为的。常用索引分为1 聚集索引 2 非聚集索引 ， 这两种索引的本质是由区别的，记得有个哥们打了个比方来分析这两种索引的机制，非常贴切，这里偷用下：大家都用过新华字典吧，小学用的，虽然很久了，可应该记得，如果真的忘了，你的宝贝会教会你的。在新华字典中检索汉子有两种方法：v 拼音检索，根据汉子的拼音组成目录，快速查找汉子。v 偏旁部首检索，根据的汉子的偏旁组成目录，快速查找汉子。 还有个重点就是：v 字典的内容默认是按照汉语拼音字母顺序来编写的，就是说。哎，不明白问小学生去。拼音检索就类似于聚集索引，偏旁部首检索就类似于非聚集索引.也就是说，聚集索引的索引字段的值重复的多，有明显的顺序；而非聚集索引没有重复或重复少，是杂乱的。那就是说，利用聚集索引更易于拆分数据块，更易于快速找到数据。但作为聚集索引的字段必须满足“类似于拼音”的规则哟。那么寻找这个关键字段就非常重要了。不幸的是数据库表只支持一个聚集索引，这是自然顺序只能有一个吗。现在来看个例子：R( id , / 主键name , / 姓名 time, / 时间dept, / 机构busy / 业务数据)假定上述关系对应基础表有1000万行数据，可能出现如下检索a 检索 张三 的对应数据。b 检索某时间范围的对应数据c 检索某时间范围内的张三的对应需求d 检索 xx公司 对应数据E 检索某时间段内xx公司对应数据索引字段现在有如下选择 “id”字段，“name”字段，“time”字段 ，“dept”字段，应该选择哪个呢？我们先整理下，聚集索引的优势：以最快的速度缩小查询范围；以最快的速度进行字段排序。 那么选择索引字段应该是：最频繁使用的、用以缩小查询范围的字段上；便于、需要排序的字段上 这里就不难确定索引字段是：“time”字段 。 可以设计成无论查询什么都加上固定的过滤条件“ time ”,以缩小查询范围，减少IO操作，减少返回数据量。 【注：】在我自己的团队中，明确要求任何查询必须返回有限的数据（分页查 询），分页排序字段一般都是聚集索引字段.聚集索引是非常宝贵的资源，象妈妈的儿子，爸爸的女儿，需要尽心地呵护。B 优化sql语句在主流数据库产品中，sql语句的优化引擎已经很优秀了，但低效的sql语句的编写仍然会带来很严重的灾难。在海量数据库环境下就表现的更加突出。现总结下常见的优化点：v 关键字的选择*， 用明确的查询目标代替. top, 可以减少数据量及检索范围，同时还能大大优化数据库底层的IO操作。慎用以下关键字，防止全表扫描字段名替代方法null设定默认值between and 条件1 and 条件2or union allin existslike v 过滤条件多个过滤条件时，能缩小范围的放在前面，索引字段过滤的必须放在第1个；过滤条件中“=”左边的字段上不应添加任何表达式运算；在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致；设定能够有效缩减查询范围的字段作为固定过滤条件，做为分页语句；v 子查询一般情况下如果能用关联查询就不用子查询子查询可以合并的尽量个兵，以减少表扫描Sql语句的优化根具体的场景有一定关系，但优化原则如下： 减少查询范围 减少查询结果数据 优先使用索引 防止全表扫描或尽量减少扫描次数 使用数据库特性技术“top rownum limit .” 慎用子查询 慎用临时表 （2） 基础表存储的数据量超过了数据库管理系统的承受阀值处理这种大数据量情况最常见的方法就是利用数据库的表分区技术，来缩减基础表的数据量，原理很简单：大数据量小数据量小数据量小数据量小数据量. 把大数据量的基础表拆分成若干个数据量较小的表，这样检索的基础数据就少了。同样的方法也可以用在索引上，即：把索引表拆分成较小的若干个索引表。各数据库厂商都提供了“表分区”的方法来支持此类操作。分区多的情况下，可以创建数据字典来管理表分区。具体的表分区操作，这里就不说了。如果数据量大刀分区后仍然过大，就要从硬件上来解决了。比如：v 数据库服务器集群v 增加或更换存储设备仔细分析所有的性能问题，你会发现都是可以预防的，也就是说性能