首先写好单元测试,保证不影响老的功能点
重构点:明白哪些代码是不好的代码
1 方法过长,需要拆分成各个子方法
2 重复代码,将重复代码封装成独立的方法以便复用
3 命名规范,尽量做到命名一眼看出含义(类名、方法名、变量名等)
4 对于model中字段的定义,已经代码各个模块的主要功能点、模糊点加上注释
5 减少不必要的临时变量的创建
6 控制方法的入参个数(当个数过多时封装成对象传入)
7 使用卫语句取代嵌套表达式 参考:http://blog.csdn.net/jw903/article/details/45506777
性能优化:
1 sql优化(待扩展)
a 取数据只取需要的字段,不要全部取出
b 当我们不确定自己sql的性能,尝试用explain解析sql
c 对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引
d 我们的大多数时间损耗大的sql都在查询操作,查询sql的优化尤为重要(如建立索引,大数据量的分页查询和建立临时表等)
e sql语句尽可能简单:一条sql只能在一个cpu运算;大语句拆小语句,减少锁时间;一条大sql可以堵死整个库
f 对于连续数值,使用BETWEEN不用IN
g 需要去重查询,尽量用group by代替distinct
3 循环里面尽量减少与业务无关的操作,如变量的申明等
4 复制对象copyProperties 方法用beanUtil类中的而不是ProperityUtil类(前者效率高且可以进行类型转换)
5 arraylist和linklist
6 性能分析工具(jconsole)
7 在使用正则表达式时,利用好其预编译功能,可以有效加快正则匹配速度
8 尽量使用基本类型而非对象
9 当使用redis缓存时,尽量使用hset/hget代替set/get(hash存储节约内存)
MySQL数据库优化:
1 引擎尽量使用innodb
2 多表查询少用join,尽量在应用层做关联查询(join查询特点:http://blog.csdn.net/jhgdike/article/details/55052064)
3 单表的字段不要太多(最好不超过20)分表原则上尽量少(单表数据量int型瓶颈至少一千万,varchar为主至少五百万)
4 页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决
5 配置参数使用:#{},#param# 不要使用${} 此种方式容易出现 SQL 注入
6 定期分析和检查表:
分析表的语法:ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tb1_name [, tb1_name]...
以上语句用于分析和存储表的关键字分布,分析的结果将可以使得系统得到准确的统计信息,使得SQL能够生成正确的执行计划。如果用户感觉实际执行计 划并不是预期的执行计划,执行一次分析表可能会解决问题。在分析期间,使用一个读取锁定对表进行锁定。这对于MyISAM,DBD和InnoDB表有作 用。
例如分析一个数据表:analyze table table_name
检查表的语法:CHECK TABLE tb1_name[,tbl_name]...[option]...option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
检查表的作用是检查一个或多个表是否有错误,CHECK TABLE 对MyISAM 和 InnoDB表有作用,对于MyISAM表,关键字统计数据被更新
CHECK TABLE 也可以检查视图是否有错误,比如在视图定义中被引用的表不存在。
7 定期优化表
优化表的语法:OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tb1_name [,tbl_name]...
如果删除了表的一大部分,或者如果已经对含有可变长度行的表(含有 VARCHAR、BLOB或TEXT列的表)进行更多更改,则应使用OPTIMIZE TABLE命令来进行表优化。这个命令可以将表中的空间碎片进行合并,并且可以消除由于删除或者更新造成的空间浪费,但OPTIMIZE TABLE 命令只对MyISAM、 BDB 和InnoDB表起作用。
例如: optimize table table_name
注意: analyze、check、optimize执行期间将对表进行锁定,因此一定注意要在MySQL数据库不繁忙的时候执行相关的操作。32.存储引擎的选择如果数据表需要事务处理,应该考虑使用InnoDB,因为它完全符合ACID特性。如果不需要事务处理,使用默认存储引擎MyISAM是比较明智的。
9 运用procedure analyze分析优化MySQL表结构(参考:http://www.cnblogs.com/freeliver54/archive/2012/12/05/2802560.html)