根据以往优化实践， 引起SQL效率低下的问题 主要集中在如下几个方面：
（1）访问路径，主要集中在由于索引缺失或者数据迁移导致索引失效引起的SQL执行时无法使用索引扫描，而被迫使用全表扫描访问路径。此时的解决方法是建立缺失的索引或者重建索引。
（2）过度使用子查询，在某些情形下我们会连接多个大表，而此时由于业务逻辑的需要我们经常会使用到某些子查询，由于语句的逻辑太过复杂，致使oracle无法自动将子查询语句转换为多表连接操作，由此带来的结果是导致oracle选择错误的执行路径，带来语句执行性能的急剧下降。因此，我们需要尽可能使用连接查询代替子查询，这样可以帮助oracle查询优化器根据数据分区情况、索引设计情况，选择合理的连接顺序、连接技术以及表访问技术，即选择最高效的执行计划。
（3）使用绑定变量的好处是可以避免硬解析，好处在此不多谈，但带来的坏处是有可能选择错误的执行计划，而这有可能引起性能的急剧下降。目前oracle 10g中已经引入绑定变量分级机制来着手处理这个问题， 11g通过创建新的子游标而维护一个新的执行计划。在11g下我们可以大胆地使用绑定变量。
3.2.6负载均衡优化
负载均衡负责访问流量分发并提高系统横向扩展能力，避免系统单点故障。下面是某个项目组负载均衡问题分析和优化思路：
在阿里“救了八年火”的架构师，大话系统架构优化项目
负载均衡算法：
随机（Random）：即从pool地址里随机选择一台，好处：算法简单、性能高，请求耗时差别不大时能基本保持后端是均衡的；缺点：如果请求耗时差别较大那么后端机器容易不均衡。
Round-Robin：根据pool地址列表顺序选择，好处：算法简单、性能高，缺点：和随机一样如果请求耗时差别较大那么后端机器容易不均衡。
按权重：可以给pool中的主机分配权重，之后按照权重分配请求，好处：可以利旧特别是运行多年生产环境积累了不同配置的主机时需要此算法，但随着虚拟化该问题已经在IAAS层解决了。
Hash:即对请求信息做hash后分派到pool中的机器上（一般对静态资源的加载使用），好处：增加缓存命中率；缺点：因为需要读取请求信息并做hash，所以需要消耗更多的CPU资源。
按照响应时间：按照响应时间来分配，好处：可以将请求分配给性能好的主机；缺点：如果请求耗时差别较大那么后端机器容易不均衡。
按照最小连接数：根据主机连接数多少来分配，好处：均衡请求资源；缺点：新增服务器或重启某一台会因为瞬间请求量过大而出现性能问题。 |
