sql简单优化点滴

select uppagent.agent_no AGENT_NO, ISNULL(countsubagent,0) REFERRAL_AGENT_NUM, ISNULL(countsubcustomer,0) CUSTOMER_NUM
from AGENT_CORRELATION uppagent
LEFT JOIN (select UPPER_AGENT_NO AGENT,count(AGENT_NO) countsubagent from AGENT_CORRELATION where UPPER_AGENT_NO is not NULL group by UPPER_AGENT_NO) subagent
on uppagent.AGENT_NO=subagent.AGENT
LEFT JOIN (select UPPER_AGENT_NO,count(id) countsubcustomer from CUSTOMER_INFO where UPPER_AGENT_NO is not NULL group by UPPER_AGENT_NO) customer
on customer.UPPER_AGENT_NO=uppagent.AGENT_NO

这种效率会高点

1,通过where UPPER_AGENT_NO is not NULL等条件使得大表转为小表

2.  使用单表统计后的数据进行关联效率比多表关联后的数据进行统计效率要高

时间: 2025-01-18 05:23:14

sql简单优化点滴的相关文章

Oracle SQL性能优化

转载自:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection ta

SQL语句优化技术分析

摘自  http://www.cnblogs.com/wxj1020/archive/2008/04/27/1173638.html 最近几周一直在进行数据库培训,老师精湛的技术和生动的讲解使我受益匪浅.为了让更多的新手受益,我抽空把SQL语句优化部分进行了整理,希望大家一起进步. 一.操作符优化 1.IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格.但是用IN的SQL性能总是比较低的,从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以

ORACLE性能优化之SQL语句优化

版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] 操作环境:AIX +11g+PLSQL 包含以下内容: 1.  SQL语句执行过程 2.  优化器及执行计划 3.  合理应用Hints 4.  索引及应用实例 5.   其他优化技术及应用 1.SQL语句执行过程 1.1 SQL语句的执行步骤 1)语法分析,分析语句的语法是否符合规范,衡量语句中各表达式的意义. 2)语义分析,检查语句中涉及的所有数据库对象是否存在,且用户有相应的权限. 3)视图转换,将涉及视图的查询语句转

MySQL之SQL语句优化

一 SQL语句优化的一般步骤: 1 通过show status命令了解各种SQL语句的执行频率 mysql> show status;                #show status:显示服务器状态信息 +-----------------------------------------------+-------------+ | Variable_name                                 | Value       | +---------------

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

转:sql语句优化

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL通用优化方案(where优化、索引优化、分页优化、事务优化、临时表优化)

SQL通用优化方案:1. 使用参数化查询:防止SQL注入,预编译SQL命令提高效率2. 去掉不必要的查询和搜索字段:其实在项目的实际应用中,很多查询条件是可有可无的,能从源头上避免的多余功能尽量砍掉,这是最简单粗暴的解决方案.3. 选择最有效率的表名顺序: 数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后.

关于Oracle程序块(主要为sql)优化方法小结

Oracle优化本身就是一件难度比较大的事情,所涉及的事情方方面面.下面说一下我的优化经验(仅限于初学者使用): 很多书上说的优化经验,都包括索引.表结构.标量子查询以及数据库层面的优化,但是80%的优化都可以是语句级的优化.优化的对象包括:procedure.function及Sql. 对于对Oracle数据库很熟悉的人来说,优化基本不需要借助任何工具就可以做到.但下面我说两个工具用来进行Sql优化:dbms_profile和advisor两个工具. 当然也可以通过执行计划进行优化. 最后会简