常见的性能问题解决方法

常见的性能问题解决方法

1      数据库表设计

1.1      不满足数据库三范式：

第一范式：每一列都是不可分割的原子数据项

 

第二范式：属性完全依赖于主键[消除部分子函数依赖]

 

第三范式：属性不依赖于其它非主属性[消除传递依赖]

 

1.2      明确系统中表行数的量级

l   建表的时候，就要估计表的行数，并让每个开发人员对表的行数都很清楚。

在sqlplus cmd里面用以下存储过程可以计算出大于1000行的表：

create   or   replace   procedure   p_rowcount_big 

as

v_count   number:=0;

cursor   c_user_tb   is   select   table_name   from   user_tables;

begin

for   v_cur   in   c_user_tb   loop

execute   immediate   'select   count(1)   from   '||v_cur.table_name   into   v_count;

if   v_count> 1000   then 

dbms_output.put_line( 'Table   Name, '||v_cur.table_name|| '   ,Rowcount, '||v_count);

end   if;

end   loop;

end   p_rowcount_big;

/

 

set serveroutput on 1000000

set   serveroutput on

exec p_rowcount_big ;

 

1.3      索引

l  任何超过千行的表都要建立索引，索引应该建立在正确的列上，要按需去建立索引，要求索引能过滤尽量多的数据，比如90%以上。

l  为了效率考虑，正确选用单列索引、组合索引、函数索引、bitmap索引、反向索引Reverse index

l   在建表的时候，就要考虑好索引创建。

1.4      数据字段使用

l  明确字段的类型，不要滥用varchar2，导致update效率低下，对应列上索引占用空间巨大

l  varchar2 字段长度不要都用4000，导致联合索引无法创建

l  同一个字段、在两种表中存储相同类型

l  慎用Clob、blob字段

1.5      分区使用

l  超过2G的大表建议都分区，设计时定好分区策略。

l  分区提升查询速度的前提是查询中带有分区条件

l  跨分区查询会导致更慢

l  多表关联查询时有可能导致分区表更慢

1.6      慎重使用纵表

l  纵表会导致数据量成倍增加，对控制和后期维护都是个问题

2      Java代码对数据库的访问

2.1      能不访问数据库的尽量不要访问数据库。

数据库与各种缓存的速度对比

数据库访问（10ms） > hibernate 查询缓存（1ms）>ehcache对象缓存（0.1ms）>ConcurrentHashMap对象缓存（10us）

2.2      对访问频繁的小表，要做缓存。

2.3      对大表的访问，要审视每次数据库访问是否是必须，要注意sql的写法，保证sql高效。

2.4      大表要减少select，在系统上下文多传递变量，而不是每次都只传递一个id，每次要用就地查询。

2.5      大表要减少update次数，统一在一个地方update

3      sql写法

3.1      系统中所有的视图一定要高效

l  保持视图的业务简单

l  尽量不要用UNION 和UNION ALL

l  禁止大数据量的order by和group by

3.2      让每个开发人员养成在PL/SQL中按F5，查看执行计划的习惯

3.3      数据入口（where）

l  让条件过滤尽量多的数据。

l  条件要写全，不要遗漏。

l  让where子句中的列命中索引。

l  以下会导致索引失效

–      Like

–      <>

–      is NULL, is not null

–      所有函数：需要用函数，说明我们的表设计的可能有问题，需要重新审视

看到比较多的是：

Substr、replace

需要用此函数说明我们的表很可能违反了第一范式

to_char、to_number

审视表字段类型是否匹配、或者在输入变量的时候转变类型。

CASE THEN

审视业务是否过于复杂

实在不行，用函数索引，下策

create index I_WORKLIST_ALL_SUB on TBL_WO_WORKLIST_COMMON (SUBSTR(FME_ID,6),DECODE(ACTUAL_START_TIME,NULL,PLAN_START_TIME,ACTUAL_START_TIME),DECODE(ACTUAL_COMPLETE_TIME,NULL,PLAN_COMPLETE_TIME,ACTUAL_COMPLETE_TIME))  tablespace WORKFORCE_INDEX;

 

l     会引起大性能消耗，必要时才采用，在提供对外的视图里面禁止使用

order by

group by

   对应字段需要建立索引

 

l  采用绑定变量

l  结果分页，对于结果集比较大的查询，需要分页

l  分区表的索引有可能因为字段不

 

3.4      执行过程的中间数据（from，与子查询）

l  避免连接太多的表。

非必要，尽量不要连接大表。如果需要连接很多，请审视表设计和业务。

过多的小表连接也可能导致恶化，可以考虑子查询。

l  避免笛卡尔，如有笛卡尔积，请审视where语句是否缺少条件

l  合理设计嵌套查询，让最里面的语句过滤尽量多的数据。

3.5      结果（select 部分）：

l  只获取刚刚好的数据。不需要的数据不要获取。

l  禁止在内存中统计结果集条数，采用sql的Count

l  尽量少做运算，需要大量运算要审视表设计和业务是否可以简化

l  一般情况下不要用Distinct，要用distinct请审视where语句是否缺少条件，表设计是否符合三范式。

4      Java代码

4.1      hashmap的使用不当

HashMap多线程并发会导致CPU 100%的问题，在系统中发现多起。要用ConcurrentHashMap代替。建议除了明确不会并发的局部变量，尽量不要用hashmap。

1、 建议禁止static的hashmap

2、 建议禁止单例形式的spring bean中hashmap

3、  类中的hashmap，需要明确没有并发场景

 

4.2      同步使用不当

l  尽量不要用同步。

l  同步块代码效率，一定要是高效的。

l  尽量不要访问同步块。

l  锁确保在finally中施放

4.3      线程使用不当

l  尽量不要用原生态线程

l  合理设计线程池参数

l  Run（）函数里面要catch住所有的异常

l 

4.4      系统资源泄漏问题

l  所有输入输出流在finally中关闭

数据库session、文件、socket、http，jms等流。

l  在内存中的存在比较长的对象，如：静态对象、Spring bean中的list，map，缓存中对象要有进有出。

l  过大的数据块，通常是sql结果未分页导致的

4.5      算法

重点审视

l  循环的跳出条件

l  循环的效率

l  算法的时间复杂度和空间复杂度