[20131204]sql语句优化.txt

[20131204]sql语句优化.txt

昨天优化sql语句,遇到一些细节问题,做一个记录:

SCOTT@test> @ver
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

create table t (id number,create_date date,pad varchar2(80));
create index i_t_create_date on t(create_date);

SCOTT@test> select /*+ index(t i_t_create_date) */ * from t where create_date>=trunc(sysdate) and  create_date>sysdate - 6/1440;
no rows selected

SCOTT@test> @dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  6tqcjs9bj623v, child number 0
-------------------------------------
select /*+ index(t i_t_create_date) */ * from t where
create_date>=trunc(sysdate) and  create_date>sysdate - 6/1440

Plan hash value: 2174186695

-----------------------------------------------------------------------------
| Id  | Operation                   | Name            | E-Rows | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |        |     1 (100)|
|   1 |  TABLE ACCESS BY INDEX ROWID| T               |      1 |     1   (0)|
|*  2 |   INDEX RANGE SCAN          | I_T_CREATE_DATE |      1 |     1   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("CREATE_DATE">=TRUNC(SYSDATE@!))
       filter("CREATE_DATE">SYSDATE@!-.004166666666666666666666666666666
              666666667)

SCOTT@test> select /*+ index(t i_t_create_date) */ * from t where create_date>sysdate - 6/1440 and create_date>=trunc(sysdate);
no rows selected

SCOTT@test> @dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID  fcc58jafh38ym, child number 0
-------------------------------------
select /*+ index(t i_t_create_date) */ * from t where
create_date>sysdate - 6/1440 and create_date>=trunc(sysdate)

Plan hash value: 2174186695

-----------------------------------------------------------------------------
| Id  | Operation                   | Name            | E-Rows | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |        |     1 (100)|
|   1 |  TABLE ACCESS BY INDEX ROWID| T               |      1 |     1   (0)|
|*  2 |   INDEX RANGE SCAN          | I_T_CREATE_DATE |      1 |     1   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("CREATE_DATE">SYSDATE@!-.004166666666666666666666666666666
              666666667)
       filter("CREATE_DATE">=TRUNC(SYSDATE@!))

-- 先是感觉奇怪的是两者写法,为什么access的条件不一样。开始感觉第2种写法应该快一些,正常的业务这样扫描的日期范围窄一些。
-- oracle优化器应该能作出正确的选择,后来想起来以前遇到的问题,我给它起一个名字叫"零点魔鬼",在凌晨切换日期时
-- 程序就有问题了。
SELECT trunc(to_date('2013-12-05 00:01:01','yyyy-mm-dd hh24:mi:ss')) a1,
       to_date('2013-12-05 00:01:01','yyyy-mm-dd hh24:mi:ss') a2,
       to_date('2013-12-05 00:01:01','yyyy-mm-dd hh24:mi:ss') -8/1440 a3
FROM dual ;

A1                  A2                  A3
------------------- ------------------- -------------------
2013-12-05 00:00:00 2013-12-05 00:01:01 2013-12-04 23:53:01

-- 很明显在凌晨执行时,日期范围越来越小,到0点6分后业务在正常。
-- 修改很简单,删除 create_date>=trunc(sysdate)条件。

时间: 2024-08-02 00:48:36

[20131204]sql语句优化.txt的相关文章

[20151221]sql语句优化.txt

[20151221]sql语句优化.txt --自从发现开发乱用distinct以后,链接http://blog.itpub.net/267265/viewspace-1871989/ --我看sql语句特别注意连接多个表,但是显示仅仅一个表的情况,上个星期五,发现一条: sql_id=dpdk3xfd6cvky SELECT EMR_DJMX.ZSFL     FROM MS_YJ01, L_LIS_SQDMX, EMR_DJMX    WHERE     MS_YJ01.YJXH IN (

[20150803]无法通过sql_id找到sql语句3.txt

[20150803]无法通过sql_id找到sql语句3.txt --前一阵子,在做优化时遇到1个无法通过sql_id找到sql语句的情况: http://blog.itpub.net/267265/viewspace-1749265/ --就是因为共享池太小,执行次数少,没到取样时间,已经从共享池清除. --今天自己google,想想看看还有那种情况会出现呢?如果1条语句执行错误,会记录sql_id,当时查询v$sql视图应该也不能找到. --自己直接那生产系统看看: 1.建立测试环境: --

sql语句优化,很着急,在线等,sql如下

问题描述 sql语句优化,很着急,在线等,sql如下 SELECT t1.user_id AS user_id, t1.user_name AS user_name, t1.serv_num AS serv_num, t1.create_date AS create_date, t1.connect_type AS connect_type, t1.login_device AS login_device, t1.login_time AS login_time, ( SELECT timest

sql优化-mysql数据库sql语句优化,求大神!!!!

问题描述 mysql数据库sql语句优化,求大神!!!! SELECT DISTINCT uid, level,username,ansnum FROM test WHERE level=100 GROUP BY uid ORDER BY ansnum DESC LIMIT 12; uid.ansnum均已建索引,主要是GROUP BY uid导致特别慢,如何提速??? 解决方案 MySQL数据库SQL语句优化原则 解决方案二: 根据你的查询需求,没有特别好的优化办法.注意group by 和o

秋色园QBlog技术原理解析:性能优化篇:打印页面SQL,全局的SQL语句优化(十三)

文章回顾: 1: 秋色园QBlog技术原理解析:开篇:整体认识(一) --介绍整体文件夹和文件的作用 2: 秋色园QBlog技术原理解析:认识整站处理流程(二) --介绍秋色园业务处理流程 3: 秋色园QBlog技术原理解析:UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL 4: 秋色园QBlog技术原理解析:UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序 5: 秋色园QBlog技术原理解析:Module之页面基类设计(五) --介绍创建

SQL语句优化

前一段时间一直在优化系统,看了一些关于SQL语句优化的东西,在这里分享一下. 1.统一SQL语句的写法 对于以下两句SQL语句,程序员认为是相同的,数据库查询优化器认为是不同的. select*from dual select*From dual 其实就是大小写不同,查询分析器就认为是两句不同的SQL语句,必须进行两次解析.生成2个执行计划.所以作为程序员,应该保证相同的查询语句在任何地方都一致,多一个空格都不行! 2.使用"临时表"暂存中间结果 简化SQL语句的重要方法就是采用临时表

信息-跪等大神——SQL语句优化

问题描述 跪等大神--SQL语句优化 这个语句如何优化跪等: select A0188,A0190,A0101,cast(dp.dept_code as int) as a01depcode,A0177,case when A0107='男' then 2 else 3 end as sex,A0117,A0159,A0148,MobileTel,A01069,A01071,GW_NAME,case when A0191='在职人员' then 9 else 7 end as a0191 fro

sql语句优化之SQL Server(详细整理)_MsSql

MS SQL Server查询优化方法 查询速度慢的原因很多,常见如下几种 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,

sql语句优化分享

sql语句优化分享 这是查询学生数据的逻辑,逻辑比较有点乱,这个查询跑30分钟也不会出结果,一执行CPU立马100%,虽然是个虚似机,但也不至于这种查询也对付不了,肯定有优化的地方.     SELECT  *        FROM 学生表 WITH(NOLOCK) WHERE          (FromSys IS NULL OR          (             (FromSys<>'A' AND FromSys<>'B' AND FromSys<>