[20130319]一條sql語句的優化.txt
[20130319]一條sql語句的優化.txt
生產系統,遇到這樣一條語句:
SELECT MAX (LENGTH (pe_id)) FROM pe_master_index WHERE SUBSTR (pe_id, 1, 2) = 'TJ';
--真不知道開發人員如何想的,寫出這樣的語句.欄位pe_id是主鍵.
--資料庫版本
--建立 SUBSTR (pe_id, 1, 2),LENGTH (pe_id),這樣的函式索引在這個版本下,會使用新建的索引,但是執行計劃還是INDEX FAST FULL
--SCAN.優化效果不明顯.好像10.2.0.4可以很好的使用這樣的索引,並且執行計劃走INDEX RANGE SCAN (MIN/MAX).
自己在11G下做一個測試:
--11G下可以使用這樣的索引走INDEX RANGE SCAN (MIN/MAX).
參看
http://space.itpub.net/267265/viewspace-715313
http://space.itpub.net/267265/viewspace-715314
http://space.itpub.net/267265/viewspace-715315
http://space.itpub.net/267265/viewspace-715390
生產系統,遇到這樣一條語句:
SELECT MAX (LENGTH (pe_id)) FROM pe_master_index WHERE SUBSTR (pe_id, 1, 2) = 'TJ';
--真不知道開發人員如何想的,寫出這樣的語句.欄位pe_id是主鍵.
--資料庫版本
SQL> select * from v$version where rownum<=1;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
1 row selected.
SQL> SELECT MAX (LENGTH (pe_id)) FROM pe_master_index WHERE SUBSTR (pe_id, 1, 2) = 'TJ';
MAX(LENGTH(PE_ID))
------------------
10
SQL> @dpc ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID awfcmwrca41fc, child number 0
-------------------------------------
SELECT MAX (LENGTH (pe_id)) FROM pe_master_index WHERE SUBSTR (pe_id,1, 2) = 'TJ'
Plan hash value: 2553983512
-------------------------------------------------------------
| Id | Operation | Name | E-Rows |
-------------------------------------------------------------
| 1 | SORT AGGREGATE | | 1 |
|* 2 | INDEX FAST FULL SCAN| PK_PE_MASTER_INDEX | 7053 |
-------------------------------------------------------------
Outline Data
-------------
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('10.2.0.3')
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX_FFS(@"SEL$1" "PE_MASTER_INDEX"@"SEL$1"
("PE_MASTER_INDEX"."PE_ID"))
END_OUTLINE_DATA
*/
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(SUBSTR("PE_ID",1,2)='TJ')
--建立 SUBSTR (pe_id, 1, 2),LENGTH (pe_id),這樣的函式索引在這個版本下,會使用新建的索引,但是執行計劃還是INDEX FAST FULL
--SCAN.優化效果不明顯.好像10.2.0.4可以很好的使用這樣的索引,並且執行計劃走INDEX RANGE SCAN (MIN/MAX).
自己在11G下做一個測試:
create table t1 as select 'tj'||lpad(rownum,8,'0') pe_id,lpad('x',100,'x') vc from dual connect by level<=10000;
create unique index scott.pk_t1 on t1(pe_id) ;
alter table t1 add constraint pk_t1 primary key (pe_id);
exec dbms_stats.gather_table_stats(USER,'T1',METHOD_OPT => 'FOR ALL COLUMNS SIZE 1 ',No_Invalidate => FALSE);
SQL> SELECT MAX (LENGTH (pe_id)) FROM t1 WHERE SUBSTR (pe_id, 1, 2) = 'tj';
MAX(LENGTH(PE_ID))
------------------
10
SQL> @dpc '' ''
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
SQL_ID 02mdzdry4jpt9, child number 0
-------------------------------------
SELECT MAX (LENGTH (pe_id)) FROM t1 WHERE SUBSTR (pe_id, 1, 2) = 'tj'
Plan hash value: 1953966236
-------------------------------------------------------------
| Id | Operation | Name | E-Rows | Cost (%CPU)|
-------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 11 (100)|
| 1 | SORT AGGREGATE | | 1 | |
|* 2 | INDEX FAST FULL SCAN| PK_T1 | 100 | 11 (10)|
-------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(SUBSTR("PE_ID",1,2)='tj')
SQL> create index if_t1_pe_id on t1(SUBSTR (pe_id, 1, 2),LENGTH (pe_id)) ;
SQL> SELECT MAX (LENGTH (pe_id)) FROM t1 WHERE SUBSTR (pe_id, 1, 2) = 'tj';
MAX(LENGTH(PE_ID))
------------------
10
SQL> @dpc '' ''
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID 02mdzdry4jpt9, child number 0
-------------------------------------
SELECT MAX (LENGTH (pe_id)) FROM t1 WHERE SUBSTR (pe_id, 1, 2) = 'tj'
Plan hash value: 2812640901
--------------------------------------------------------------------------
| Id | Operation | Name | E-Rows | Cost (%CPU)|
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 2 (100)|
| 1 | SORT AGGREGATE | | 1 | |
| 2 | FIRST ROW | | 1 | 2 (0)|
|* 3 | INDEX RANGE SCAN (MIN/MAX)| IF_T1_PE_ID | 1 | 2 (0)|
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("T1"."SYS_NC00003$"='tj')
--11G下可以使用這樣的索引走INDEX RANGE SCAN (MIN/MAX).
參看
http://space.itpub.net/267265/viewspace-715313
http://space.itpub.net/267265/viewspace-715314
http://space.itpub.net/267265/viewspace-715315
http://space.itpub.net/267265/viewspace-715390
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-756487/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [20181114]一條sql語句的優化.txtSQL優化
- [20201210]sql語句優化.txtSQL優化
- [20200320]SQL語句優化的困惑.txtSQL優化
- [20200324]SQL語句優化的困惑2.txtSQL優化
- SQL語句優化SQL優化
- [20211229]toad下優化sql語句注意的問題.txt優化SQL
- Mysql 52條SQL語句效能優化策略彙總MySql優化
- MYSQL SQL語句優化MySql優化
- sql語句效能優化SQL優化
- 優化 SQL 語句的步驟優化SQL
- [20231114]如何知道一條sql語句涉及到那些表.txtSQL
- MySQL之SQL語句優化MySql優化
- [20210205]警惕toad下優化直方圖相關sql語句.txt優化直方圖SQL
- 一條sql語句的執行過程SQL
- SQL優化案例-單表分頁語句的優化(八)SQL優化
- 第45期:一條 SQL 語句最佳化的基本思路SQL
- [20211224]vim外掛格式化sql語句.txtSQL
- [20211231]vim自動格式化sql語句.txtSQL
- 一條update SQL語句是如何執行的SQL
- 一條SQL更新語句是如何執行的SQL
- 一條SQL更新語句是如何執行的?SQL
- 優化 JS 條件語句的 5 個技巧優化JS
- [20201105]再分析sql語句.txtSQL
- [20220117]超長sql語句.txtSQL
- [20240607]PL/SQL中sql語句的註解.txtSQL
- Sql語句本身的優化-定位慢查詢SQL優化
- SQL語句優化的原則與方法QOSQL優化
- 一條更新的SQL語句是如何執行的?SQL
- [20240320]空格與sqlpus的sql語句.txtSQL
- [20210205]警惕toad下優化直方圖相關sql語句3.txt優化直方圖SQL
- PL/SQL 條件控制語句SQL
- 一條SQL語句在MySQL中如何執行的MySql
- 一條 SQL 查詢語句是如何執行的?SQL
- [20240409]為什麼一條sql語句在例項2執行要慢的分析.txtSQL
- [20220331]如何調整sql語句.txtSQL
- 《MySQL慢查詢優化》之SQL語句及索引優化MySql優化索引
- Java中如何解析SQL語句、格式化SQL語句、生成SQL語句?JavaSQL
- [20211221]分析sql語句遇到的問題.txtSQL
- MySQL 52個SQL效能優化策略SQL語句彙總MySql優化