潜在的性能问题

今天看了下XX软件的一些问题，特别记录下来。

 

现象：某些字段是varchar2类型，但是该字段可能全部是数字，也有可能数字中含有字母。
因此在写sql语句匹配这些字段的时候需要在这些字段上加上函数upper,以保证精确匹配。
分析调整建议：字段的大小写，直接在应用修改与控制，不能增加数据库负担，应用修改是一劳永逸。而数据库会再次修改。
如果在数据库端加入约束，那么肯定是影响了数据库的性能。

 

现象：在大量并发的情况下,latch free出现在top5等待事件中。
分析调整建议：latch free等待严重，cpu出现严重等待,是因为并发大量的逻辑读，出现缓冲区的内存锁等待。
此外sql没有使用绑定变量，也会导致cpu的过度使用。
另外，因为并发量大，可能有同时多个事务对一个表进行dml操作，修改表的inittrans参数，这样并发的时候，
初始的事务值高点，减低部分这方面的竞争。

 

现象：索引的命名不是很规范，很多普通的索引以及主键都是以pk_开头。
需要规范索引的命名，应该保证看见索引的名字就能够识别出该索引的类型，以及该索引想关联的表，主键、唯一索引、普通索引。

 

现象：大量的模糊查询，查询条件没有限制必须输入
建议：建议应用去控制必须输入的条件比如主键条件，或者通过后台dbms_rls去过滤一部分数据。

 

此外在书写SQL没有充分考虑到不同场合下性能的异同。比如是使用嵌套循环快还是哈希连接快，这值得考究的。一般情况下，如果有一个小表，而与其等值关联的表中的相关字段中含有索引，那么嵌套循环是比较快的。如果两张都是大表，或者是等值关联的关键字段没有索引，那么使用哈希连接会快点。