[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)條件。
昨天優化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)條件。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-1062126/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [20201210]sql語句優化.txtSQL優化
- [20200320]SQL語句優化的困惑.txtSQL優化
- [20181114]一條sql語句的優化.txtSQL優化
- [20200324]SQL語句優化的困惑2.txtSQL優化
- SQL語句優化SQL優化
- MYSQL SQL語句優化MySql優化
- sql語句效能優化SQL優化
- [20211229]toad下優化sql語句注意的問題.txt優化SQL
- MySQL之SQL語句優化MySql優化
- [20210205]警惕toad下優化直方圖相關sql語句.txt優化直方圖SQL
- 優化 SQL 語句的步驟優化SQL
- [20211224]vim外掛格式化sql語句.txtSQL
- [20211231]vim自動格式化sql語句.txtSQL
- [20201105]再分析sql語句.txtSQL
- [20220117]超長sql語句.txtSQL
- [20210205]警惕toad下優化直方圖相關sql語句3.txt優化直方圖SQL
- [20220331]如何調整sql語句.txtSQL
- SQL優化案例-單表分頁語句的優化(八)SQL優化
- 《MySQL慢查詢優化》之SQL語句及索引優化MySql優化索引
- Java中如何解析SQL語句、格式化SQL語句、生成SQL語句?JavaSQL
- MySQL 52個SQL效能優化策略SQL語句彙總MySql優化
- [20221012]修改統計資訊最佳化sql語句.txtSQL
- [20240607]PL/SQL中sql語句的註解.txtSQL
- Sql語句本身的優化-定位慢查詢SQL優化
- SQL語句優化的原則與方法QOSQL優化
- [20240320]空格與sqlpus的sql語句.txtSQL
- [20201224]sql優化困惑.txtSQL優化
- SQL語句最佳化SQL
- sql語句執行順序與效能優化(1)SQL優化
- MySql常用30種SQL查詢語句優化方法MySql優化
- Mysql 52條SQL語句效能優化策略彙總MySql優化
- [20181119]sql語句執行緩慢分析.txtSQL
- [20211221]分析sql語句遇到的問題.txtSQL
- [20220329]是否開發寫錯sql語句.txtSQL
- [20210923]sql語句佔用Sharable Memory分析.txtSQL
- [20211009]使用bash計算sql語句的sql_id.txtSQL
- soar-PHP - SQL 語句優化器和重寫器的 PHP 擴充套件包、 方便框架中 SQL 語句調優PHPSQL優化套件框架
- [20220119]超長sql語句補充3.txtSQL
- [20220329]19c sql語句打補丁.txtSQL