软件性能优化最佳实践
(作者：张宝玉)
1经验总结
1.1应用程序设计优化
当系统中业务数据量较大时，避免业务变更的历史数据和正式的业务数据同时存储，由于业务新增的数据及历史业务变更产生的数据，会到时存储表越来越庞大，而且历史数据会逐步增多，一段时间后，历史数据往往会大于正式数据，而正式数据是要经常使用的，历史数据只会在个别查询时会用到，庞大的数据存储会直接导致正式业务数据的查询性能及程序处理复杂度，同时，如果系统未来进行升级时，庞大的数据量会大大增大数据迁移割接的难度，增加数据迁移的时间；建议将正式数据独立存储，业务修改后的历史数据采用日志存储或新建表进行存储，保证正式数据的查询处理效率。 对于不可变字符类型char和可变字符类型varchar 最大长度都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。
数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。
历史数据存储建议
当数据库中的某种业务数据增加量很大时，如短信业务或用户交易业务，往往涉及最近记录和历史记录查询问题，建议建立与正式业务表属性相同的历史记录表，同时采用定时程序或存储过程等方法将正式业务表的数据按过期规则迁移至历史记录表，在用户进行记录查询是分表查询，一般用户比较关注近期的记录，这样直接查询正式业务表，数据量不是很大，保证的较高的查询响应效率，个别情况下用户会查询历史记录，系统会从历史记录表中查询；使用这样的方式可以保证大部分时间用户的查询效率
消息服务的应用
J2EE规范在JMS中提供了内置的异步处理服务。当涉及到系统需求时，应该了解在什么情况下应该采用JMS进行异步处理的设计。一旦确定要执行一些异步处理，那么同步处理的任务就应该越少越好，将数据库密集的操作安排在稍后的异步处理中完成。
大字段处理
当业务表中包括用来存储附件、图片、大文本的大字段的数据类型时，在列表页面一般情况下不要获取大字段内容，如列表页面获取大字段，却不进行展现，如数据量增大后，会大大影响页面展示速度，在查看页面加载大字段类型，可在对象实体类中增加一个钩子函数，只把基本属性传入，这样列表页面就不会获取到大字段，当然，也可以通过Hibernate配置解决这个问题，hibernate2可以将BLOB字段与基本信息分离，生成两个PO，这样我们可以通过延迟加载特性以提高效率，字段单独拆分出来，以提高数据库操作的性能。Hibernate3中对于POJO的属性提供了延迟加载, 只要设置属性的的lazy="true"，以后通过getXXX 才能真正从数据库中读取数据，这样可以有效地提高我们读取部分表字段的性能。流的关闭
对于应用中的I/O流、网络传输流、数据库连接等要及时关闭和释放，否则会造成内存溢出，会话数占满等问题。在流关闭的时候要注意关闭的顺序。
1.2数据库优化
连接池配置
目前数据库连接池开源组件是非常多的，DBCP、C3P0、Proxool、BoneCP等都是非常优秀的产品。连接池的性能和稳定性会对我们的程序造成极大的影响，因此，有必要对这些连接池产品进行一些选择。另外，连接池的配置是否恰当，将会决定该连接池的性能和稳定性表现，Hibernate开发组推荐使用c3p0，spring开发组推荐使用dbcp(dbcp连接池有weblogic连接池同样的问题，就是强行关闭连接或数据库重启后，无法reconnect，但可通过配置来解决)，Hibernate in action推荐使用c3p0和proxool。三个产品都能很方便地整合到Springframework中，也都可以配置为JNDI资源，因此，它们可以随意更换，不会影响程序代码。根据网络上各种比较结果分析，在性能上，BoneCP>Proxool>C3P0>DBCP，在稳定性上DBCP>C3P0>Proxool。所以在项目中要根据实际情况，选择适当的连接池。针对大批量的数据处理建议使用JDBC。
Hibernate提供了两级缓存，第一级是Session的缓存。由于Session对象的生命周期通常对应一个数据库事务或者一个应用事务，因此它的缓存是事务范围的缓存。第一级缓存是必需的，不但而且事实上也无法被卸除。在第一级缓存中，持久化类的每个实例都具有唯一的OID。第二级缓存是一个可插拔的的缓存插件，它是由SessionFactory负责管理。由于SessionFactory对象的生命周期和应用程序的
多媒体操作系统
整个过程对应，因此第二级缓存是进程范围或者集范围的缓存。这个缓存中存放的对象的松散数据。第二级对象有可能出现并发问题，因此需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别。缓存适配器用于把具体的缓存实现软件与Hibernate集成。第二级缓存是可选的，可以在每个类或每个集合的粒度上配置第二级缓存。
正确的利用二级缓存，可极大的提高系统的查询效率。
以下数据适合存放到第二级缓存中：
●很少被修改的数据
●不是很重要的数据，但出现偶然并发的数据
●不会被并发访问的数据
●参考数据分界开关控制器
以下数据不适合存放到第二级缓存中：
●经常被修改的数据
●财务数据，绝对不能出现并发
●与其他应用共享的数据。
SQL优化
我们要做到不但会写 SQL，还要做到写出性能优良的 SQL。SQL优化需要注意及遵循的准则很多，本文只列举核心部分：
1)尽量少用IN操作符，基本上所有的IN操作符都可以用EXISTS代替。
2)不用NOT IN操作符，可以用NOT EXISTS或者外连接+（外连接+判断为空）
替代。
3)不用“<>”或者“!=”操作符。对不等于操作符的处理会造成全表扫描，可
以用“<”or “>”代替。例如：a<>0 改为a>0 or a<0，a<>’’改为a>’’4)Where子句中出现IS NULL或者IS NOT NULL时，Oracle会停止使用索引而执
行全表扫描。可以考虑在设计表时，对索引列设置为NOT NULL。这样就可以用其他操作来取代判断
NULL的操作。
5)当通配符“%”或者“_”作为查询字符串的第一个字符时，索引不会被使用，
因此一般不要作为第一个字符出现。
6)对于有连接的列“||”，最后一个连接列索引会无效。尽量避免连接，可以
分开连接或者使用不作用在列上的函数替代。
7)如果索引不是基于函数的，那么当在Where子句中对索引列使用函数时，索
引不再起作用。
精准灌溉系统海棠
8)Where子句中避免在索引列上使用计算，否则将导致索引失效而进行全表扫
描。
9)对数据类型不同的列进行比较时，会使索引失效。
10)用“>=”替代“>”。
11)UNION操作符会对结果进行筛选，消除重复，数据量大的情况下可能会引起
磁盘排序。如果不需要删除重复记录，应该使用UNION ALL。
12)Oracle从下到上处理Where子句中多个查询条件，所以表连接语句应写在其
他Where条件前，可以过滤掉最大数量记录的条件必须写在Where子句的末尾。
13)Oracle从右到左处理From子句中的表名，所以在From子句中包含多个表的
情况下，将记录最少的表放在最后。
14)Order By语句中的非索引列会降低性能，可以通过添加索引的方式处理。严
格控制在Order By语句中使用表达式。
15)不同区域出现的相同的Sql语句，要保证查询字符完全相同，以利用SGA共
享池，防止相同的Sql语句被多次分析。
16)多利用内部函数提高Sql效率。
声波驱散器17)当在Sql语句中连接多个表时，使用表的别名，并将之作为每列的前缀。这
烟卷引流样可以减少解析时间。
18)根据SQL不同设定优化模式的方式，选择不同的优化策略，通过SELECT
/*+ALL+_ROWS*/ ……；来设定。可用的HINT包括/*+ALL_ROWS*/、/*+FIRST_ROWS*/、/*+CHOOSE*/、/*+RULE*/ 等一般在SQL前加first_rows 策略，速度都会提高，特殊情况下改用choose策略。
19)对于大表查询中的列应尽量避免进行诸如Ｔｏ＿ｃｈａｒ，ｔｏ＿ｄａｔｅ，
ｔｏ＿ｎｕｍｂｅｒ等转换。
20)有索引的尽量用索引，有用到索引的条件写在前面。
21)如有可能和有必要就建立一些索引，在使用索引字段作为条件时，如果该
索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
22)尽量避免进行全表扫描，限制条件尽可能多，以便更快搜索到要查询的数据。
23)Select子句中尽量避免使用‘*’，当你想在SELECT子句中列出所有的COLUMN
时，使用动态SQL列引用‘*’ 是一个方便的方法。但是，这是一个非常低效的方法。实际上，ORACLE在解析的过程中，会将‘*’ 依次转换成所有的列名，这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间。合理写WHERE子句，不要写没有WHERE的SQL语句。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议