<一>SQL优化1-4

第一条:去除在谓词列上编写的任何标量函数
        --->在select 显示列上使用标量函数是可以的。但在where语句后的过滤条件部分对列使用函数,需要考虑。因为执行sql的引擎会因为标量函数,放弃使用该列的索引。造成扫描全表,性能下降。
        --->DB V9可以使用表达式索引,但建议不要写这样的sql,索引维护代价大
        --->例子
        select count(id) from TBL_NMC_PAYMENTPROCESS p where  year(p.REQUESTDATE)=2015
        改写为:
        select count(id) from TBL_NMC_PAYMENTPROCESS p where  p.REQUESTDATE between ‘2015-01-01 00:00:00‘ and  ‘2015-12-31 23:59:59‘

第二条:去除在谓词列上编写的任何数学运算
        --->在select 显示列上使用数学运算是可以的。但在where语句后的谓词列上使用数学运算,会将该谓词列变成不可索引列。
        --->DB V9可以在列上创建索引可以使用数学运算。但不建议
        --->例子:
        select p.CONFIRMAMOUNT  from TBL_NMC_PAYMENTPROCESS p where  p.CONFIRMAMOUNT*100>1000
        改写为:
        select p.CONFIRMAMOUNT  from TBL_NMC_PAYMENTPROCESS p where  p.CONFIRMAMOUNT>1000/100

第三条:select 语句的显示列,只写必要的列,多余无用的列不需要,则不需要写。
        --->降低IO的开销,排序的成本

第四条:尽可能不用DISTINCT去掉重复
        --->DISTINCT很可能会使查询结果集完成一次排序,造成成本过大。其也为sql中成本最高的函数
        --->使用group by去掉重复,使用in 或Exists子查询重写查询。
        --->例子:
        select DISTINCT p.ID,pp.ID,pp.PAYMENTID from TBL_NMC_PAYMENT p join TBL_NMC_PAYMENTPROCESS pp on p.ID=pp.PAYMENTID where p.FINISHDATE>=‘2014-02-18 00:00:00‘ and p.FINISHDATE<‘2015-02-18 23:59:59‘
        改写为:
        select p.ID,count(pp.ID) from TBL_NMC_PAYMENT p join TBL_NMC_PAYMENTPROCESS pp on p.ID=pp.PAYMENTID where p.FINISHDATE>=‘2014-02-18 00:00:00‘ and p.FINISHDATE<‘2015-02-18 23:59:59‘ group by p.ID
        改写为:
        select p.ID from TBL_NMC_PAYMENT p where exists(select pp.PAYMENTID from TBL_NMC_PAYMENTPROCESS pp where p.ID=pp.PAYMENTID )
        改写为:
        select p.ID from TBL_NMC_PAYMENT p where p.ID in(select p.ID from TBL_NMC_PAYMENT p join TBL_NMC_PAYMENTPROCESS pp on p.ID=pp.PAYMENTID where p.FINISHDATE>=‘2014-02-18 00:00:00‘ and p.FINISHDATE<‘2015-02-18 23:59:59‘ )

时间: 2024-10-07 16:32:05

<一>SQL优化1-4的相关文章

sql优化

1.all: 全表扫描,遍历全表找到匹配的行 index:索引全扫描,遍历整个索引来查询匹配的行 range:索引范围扫描,常见于<,>,>=,between等操作符 ref: 使用非唯一索引扫描或唯一索引的前缀扫描,返回匹配某个单独值的记录行 eq_ref:类似ref,区别就是使用的索引是唯一索引,对于每个索引键值,表中只有一条记录匹配.简单来说,就是多表连接中使用primary key或者unique index 作为关联条件 const/system:单表中最多有一个匹配行,查询起

sql优化(oracle)- 第三部分 &#160;sql优化总结

第三部分  sql优化总结        1. 优化一般原则        2. 具体注意事项 1. SQL优化一般性原则 1)目标:减少服务器资源消耗(主要是磁盘IO) 2)设计: 1. 尽量依赖oracle优化器 2. 合适的索引(数据重复量大的列不要简历二叉树索引,可以使用位图索引: 对应数据操作频繁的表,索引需要定期重建,减少失效的索引和碎片) 3)编码: 1. 利用索引 2. 合理利用临时表 3. 避免写过于复杂的sql: 4. 尽量减小事务的粒度 2. 具体注意事项 1)查询时尽量使

SQL优化技巧

我们开发的大部分软件,其基本业务流程都是:采集数据→将数据存储到数据库中→根据业务需求查询相应数据→对数据进行处理→传给前台展示.对整个流程进行分析,可以发现软件大部分的操作时间消耗都花在了数据库相关的IO操作上.所以对我们的SQL语句进行优化,可以提高软件的响应性能,带来更好的用户体验. 在开始介绍SQL优化技巧之前,先推介一款数据库管理神器Navicat,官网:https://www.navicat.com.cn/whatisnavicat Navicat是一套快速.可靠和全面的数据库管理工

数据库SQL优化大总结之百万级数据库优化方案

网上关于SQL优化的教程很多,但是比较杂乱.近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充. 这篇文章我花费了大量的时间查找资料.修改.排版,希望大家阅读之后,感觉好的话推荐给更多的人,让更多的人看到.纠正以及补充. 1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id f

基于案例SQL优化第九课作业分享

默认统计信息收集: 1. 11g默认启动了统计信息收集的任务,默认运行时间是周一到周五晚上10点和周6,周天的早上6点 2. 你也可以关闭自动统计新收集任务,选择手工收集的方式,但是一般不建议这样操作. 动态统计信息: 1. 统计信息默认情况下是每天晚上10点半后收集,如果新建对象还没来得级收集统计信息,就采用动态采样的方式. 2. 具体在set autotrace 跟踪的执行计划中,可以看到类似:- dynamic sampling used for this statement (level

Sql优化和体系结构

01.SQL优化与体系结构 本章目标: 1.了解sql优化基本技巧 2.掌握使用索引提高查询效率 3.了解对表进行分区操作 4.了解常见数据库对象 1.sql优化技巧 1)一般优化技巧: 不要用*代替所有列名 删除所有数据用truncate代替delete 用not exists 代替 not in 用exists 代替 in 用exists代替distinct 注:后三点在11g之前有用,11g之后本身进行了优化 第5条的实例如下:查询出出现在教师表里的不同的部门编号 select disti

SQL优化经验

SQL 优化经验总结34条 我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习.摘录.并汇总部分资料与大家分享! (1) 选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection tabl

SQL的别名和SQL的执行顺序和SQL优化

SQL的别名 1.不可以在where子句中使用列名的别名,即select name t from emp where t>2999;是不允许的 2.使用别名的好处: 提高SQL的易读性 提高SQL的解析执行效率 语法检查 语义检查 共享池检查 生成执行树 执行 3.SQL的硬解析和软解析? SQL的执行顺序 1.from语句--where语句--group by语句--having语句--select语句--order by语句 rownum的使用 select * from emp rownu

MySQL 数据库性能优化之SQL优化

前言 有人反馈之前几篇文章过于理论缺少实际操作细节,这篇文章就多一些可操作性的内容吧. 注:这篇文章是以 MySQL 为背景,很多内容同时适用于其他关系型数据库,需要有一些索引知识为基础. 优化目标 1.减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段. 2.降低 CPU 计算 除了 IO 瓶颈之外,SQL优化中需要考虑的就

SQL 优化经验总结34条(转)

(1) 选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. (2) WHERE子句中的连接顺序.: ORACLE采用自下而上的顺序解析WHE