减少嵌套层次,一般来说不要超过2层;
 写Sql时要尽量少多关联表
 distinct和order by尽量避免使用;
 针对有嵌套的情况,条件全部放到内层去限制;
 减少不必要的步骤;能一次查询出来的数据不要写2个sql
 针对循环比较多但逻辑简单的insert步骤;优先使用insert select方法,如果有复杂处理,则使用bulk 数组方式
 重要查询条件和关联字段不能使用函数转换;  如果需要,则只能在最外层的select上进行转换;
  观察sql的执行计划,驱动表(执行计划最内层的表)一般要是能过滤最多数据的表;
   执行计划中针对大表(超过1000条记录)不能有全表扫描; (由于43环境数据量少,有时间看不出问题,可在UAT3环境查看一下执行计划;)
 部分情况下,建立索引是必需的;针对重要关联表可以建立一个组合索引,做到只查询索引就可以找到结果集
 不要迷信执行计划和COST值,最终执行时间才是唯一检验标准。 但测试时注意更换不同参数,避免数据库数据缓存带来的假象
 代码修改完成后,必须对修改点的相关功能(要想清楚哪些功能有关联影响)在本地进行性能测试;(要寻找数据量较大的项目和合同进行测试)
 针对循环次数比较多,但是内部逻辑复杂的代码,建议使用select bulk collect into  table变量方式,用数组来做循环
 针对循环次数比较多但是逻辑复杂的insert逻辑,建议使用数组批量写入方式;forall l_index1 in 1..l_index2
 针对循环次数比较多但是逻辑复杂的处理,从逻辑方案深入思考一下,看能否减少sql运行次数;减少sql运行次数的同时,要考虑sql的索引是否合适;
 sql中条件的左右两边的字段类型要一致;如果遇到不一致的情况,先考虑调整数据库结构,使保持一致;如果不能更改数据表中的类型,可需要在驱动方显式写出to_char或to number,避免数据库做隐式转换;
 定时的表统计分析,ERP使用fnd_stats
 直方图要慎重,不必要的直方图不要建立