oracle区分度公式,区分度越大的列，作为主导列，索引效果越好？
本帖最后由 happywangkui 于 2014-11-10 22:16 编辑
直接上之前遇到的问题：
1、三个组合索引如下：
CREATE INDEX IDX_TRAD_SK_HKDAILY_STM ON TRAD_SK_HKDAILY
(SECUCODE,TDATE, MARKET)
CREATE INDEX IDX_TRAD_SK_HKDAILY_TSM ON TRAD_SK_HKDAILY
(TDATE, SECUCODE, MARKET)
CREATE INDEX IDX_TRAD_SK_HKDAILY_SMT ON TRAD_SK_HKDAILY
(SECUCODE, MARKE,TTDATE)
2、说明一下列的区分度：
TDATE：8000多个不同值
SECUCODE：1000多个不同值
MARKET：1个唯一值
区分度大小：TDATE>SECUCODE>MARKET
3、下面做三种测试：分别走上面不同索引：
第一种走：IDX_TRAD_SK_HKDAILY_STM索引
SELECT COUNT(ID)
FROM
(
SELECT /*+ index(E IDX_TRAD_SK_HKDAILY_STM)*/
rownum ID,
A.CDSY_SECUCODE_EID ,
A.SPTM_MARKETRELATION_EID ,
B.HK_SHORTTD_LIST_EID ,
case when C.PUBLISHCODE like '402%' then C.CUST_PUBLISHSTOCKRELATION_EID else null end CUST_PUBLISHSTOCKRELATION_EID,
case when C.PUBLISHCODE like '402%' then C.CUST_PUBLISHRELATION_EID else null end CUST_PUBLISHRELATION_EID,
E.TRAD_SK_HKDAILY_EID ,
A.MSECUCODE ,
A.SECURITYSHORTNAME ,
B.TDATE DAT_TDATE ,
B.TIMEFRAME ,
B.CURRENCY ,
B.TVOL ,
B.TVAL ,
E.TNUM ,
E.TAMT ,
case when C.PUBLISHCODE like '402%' then C.PUBLISHNAME else null end STR_GICS,
case when C.PUBLISHCODE like '403%' then C.PUBLISHNAME else null end STR_GJSHY,
A.SECURITYTYPE ,
A.TRADEMARKET ,
A.TRADEMARKETCODE
FROM
(
SELECT A.EID CDSY_SECUCODE_EID ,
B.EID SPTM_MARKETRELATION_EID,
SECURITYCODE ,
A.SECURITYCODE
||
B.MARKETRELEATION MSECUCODE,
SECURITYSHORTNAME ,
SECURITYTYPE ,
TRADEMARKET ,
COMPANYCODE ,
SECURITYVARIETYCODE ,
TRADEMARKETCODE
FROM CDSY_SECUCODE A
JOIN SPTM_MARKETRELATION B
ON A.TRADEMARKETCODE=B.MARKETCODE
WHERE SECURITYTYPECODE LIKE'058001003%'
AND USESTATE ='1'
AND LISTINGSTATE<>'2'
)
A
JOIN
(
SELECT EID HK_SHORTTD_LIST_EID ,
HKCODE ,
SECURITYCODE ,
TO_DATE(TDATE,'YYYY/MM/DD') TDATE,
CURRENCY ,
TIMEFRAME ,
TVOL ,
TVAL
FROM HK_SHORTTD_LIST
)
B
ON A.SECURITYVARIETYCODE=B.HKCODE
AND A.SECURITYCODE =B.SECURITYCODE
LEFT JOIN
(
SELECT A.EID CUST_PUBLISHSTOCKRELATION_EID,
B.EID CUST_PUBLISHRELATION_EID ,
COMPANYCODE ,
SECURITYCODE ,
PUBLISHNAME,
a.PUBLISHCODE
FROM
(
SELECT EID ,
COMPANYCODE ,
SECURITYCODE,
PUBLISHCODE
FROM CUST_PUBLISHSTOCKRELATION
WHERE PUBLISHCODE LIKE'402%' or PUBLISHCODE LIKE'403%'
)
A
LEFT JOIN
(
SELECT EID ,
PUBLISHCODE,
PUBLISHNAME
FROM CUST_PUBLISHRELATION
WHERE PUBLISHCODE LIKE'402%' or PUBLISHCODE LIKE'403%'
)
B
ON A.PUBLISHCODE=B.PUBLISHCODE
)
C ON A.COMPANYCODE=C.COMPANYCODE
AND A.SECURITYCODE=C.SECURITYCODE
LEFT JOIN
(
SELECT EID TRAD_SK_HKDAILY_EID,
SECUCODE ,
TDATE ,
TNUM ,
TAMT
FROM TRAD_SK_HKDAILY
)
E
ON B.SECURITYCODE=E.SECUCODE
AND B.TDATE =E.TDATE
)
统计信息如下：
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.05 0.05 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 2.62 2.63 1 61565 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 2.68 2.69 1 61565 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 157
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 SORT AGGREGATE (cr=61565 pr=1 pw=0 time=2632915 us)
176130 176130 176130 VIEW (cr=61565 pr=1 pw=0 time=3204960 us cost=4094 size=13 card=1)
176130 176130 176130 COUNT (cr=61565 pr=1 pw=0 time=2908975 us)
176130 176130 176130 NESTED LOOPS OUTER (cr=61565 pr=1 pw=0 time=2653411 us cost=4094 size=189 card=1)
176130 176130 176130 HASH JOIN OUTER (cr=22567 pr=0 pw=0 time=1103999 us cost=4092 size=170 card=1)
89999 89999 89999 NESTED LOOPS (cr=2588 pr=0 pw=0 time=1000620 us cost=637 size=128 card=1)
89999 89999 89999 HASH JOIN (cr=2585 pr=0 pw=0 time=235999 us cost=637 size=112 card=1)
2302 2302 2302 TABLE ACCESS BY INDEX ROWID CDSY_SECUCODE (cr=817 pr=0 pw=0 time=15547 us cost=350 size=222998 card=2593)
2326 2326 2326 INDEX SKIP SCAN IDX_CDSY_SECUCODE_LS (cr=35 pr=0 pw=0 time=6057 us cost=74 size=0 card=2598)(object id 345164)
90234 90234 90234 TABLE ACCESS FULL HK_SHORTTD_LIST (cr=1768 pr=0 pw=0 time=97702 us cost=287 size=2164968 card=83268)
89999 89999 89999 INDEX RANGE SCAN SPTM_MARKETRELATION_MARKETCODE (cr=3 pr=0 pw=0 time=380949 us cost=0 size=16 card=1)(object id 96435)
3487 3487 3487 VIEW (cr=19979 pr=0 pw=0 time=28541 us cost=3455 size=136080 card=3240)
3487 3487 3487 HASH JOIN RIGHT OUTER (cr=19979 pr=0 pw=0 time=22913 us cost=3455 size=139320 card=3240)
385 385 385 INDEX FAST FULL SCAN IDX_CUST_PUBLISHRELATION1 (cr=126 pr=0 pw=0 time=3246 us cost=12 size=4440 card=370)(object id 140038)
3487 3487 3487 TABLE ACCESS FULL CUST_PUBLISHSTOCKRELATION (cr=19853 pr=0 pw=0 time=8106 us cost=3443 size=100440 card=3240)
171831 171831 171831 INDEX RANGE SCAN IDX_TRAD_SK_HKDAILY_STM (cr=38998 pr=1 pw=0 time=879908 us cost=2 size=19 card=1)(object id 402666)
第二种走：IDX_TRAD_SK_HKDAILY_TSM索引
SELECT COUNT(ID)
FROM
(
SELECT /*+ index(E IDX_TRAD_SK_HKDAILY_TSM)*/
rownum ID,
A.CDSY_SECUCODE_EID ,
A.SPTM_MARKETRELATION_EID ,
B.HK_SHORTTD_LIST_EID ,
case when C.PUBLISHCODE like '402%' then C.CUST_PUBLISHSTOCKRELATION_EID else null end CUST_PUBLISHSTOCKRELATION_EID,
case when C.PUBLISHCODE like '402%' then C.CUST_PUBLISHRELATION_EID else null end CUST_PUBLISHRELATION_EID,
E.TRAD_SK_HKDAILY_EID ,
A.MSECUCODE ,
A.SECURITYSHORTNAME ,
B.TDATE DAT_TDATE ,
B.TIMEFRAME ,
B.CURRENCY ,
B.TVOL ,
B.TVAL ,
E.TNUM ,
E.TAMT ,
case when C.PUBLISHCODE like '402%' then C.PUBLISHNAME else null end STR_GICS,
case when C.PUBLISHCODE like '403%' then C.PUBLISHNAME else null end STR_GJSHY,
A.SECURITYTYPE ,
A.TRADEMARKET ,
A.TRADEMARKETCODE
FROM
(
SELECT A.EID CDSY_SECUCODE_EID ,
B.EID SPTM_MARKETRELATION_EID,
SECURITYCODE ,
A.SECURITYCODE
||
B.MARKETRELEATION MSECUCODE,
SECURITYSHORTNAME ,
SECURITYTYPE ,
TRADEMARKET ,
COMPANYCODE ,
SECURITYVARIETYCODE ,
TRADEMARKETCODE
FROM CDSY_SECUCODE A
JOIN SPTM_MARKETRELATION B
ON A.TRADEMARKETCODE=B.MARKETCODE
WHERE SECURITYTYPECODE LIKE'058001003%'
AND USESTATE ='1'
AND LISTINGSTATE<>'2'
)
A
JOIN
(
SELECT EID HK_SHORTTD_LIST_EID ,
HKCODE ,
SECURITYCODE ,
TO_DATE(TDATE,'YYYY/MM/DD') TDATE,
CURRENCY ,
TIMEFRAME ,
TVOL ,
TVAL
FROM HK_SHORTTD_LIST
)
B
ON A.SECURITYVARIETYCODE=B.HKCODE
AND A.SECURITYCODE =B.SECURITYCODE
LEFT JOIN
(
SELECT A.EID CUST_PUBLISHSTOCKRELATION_EID,
B.EID CUST_PUBLISHRELATION_EID ,
COMPANYCODE ,
SECURITYCODE ,
PUBLISHNAME,
a.PUBLISHCODE
FROM
(
SELECT EID ,
COMPANYCODE ,
SECURITYCODE,
PUBLISHCODE
FROM CUST_PUBLISHSTOCKRELATION
WHERE PUBLISHCODE LIKE'402%' or PUBLISHCODE LIKE'403%'
)
A
LEFT JOIN
(
SELECT EID ,
PUBLISHCODE,
PUBLISHNAME
FROM CUST_PUBLISHRELATION
WHERE PUBLISHCODE LIKE'402%' or PUBLISHCODE LIKE'403%'
)
B
ON A.PUBLISHCODE=B.PUBLISHCODE
)
C ON A.COMPANYCODE=C.COMPANYCODE
AND A.SECURITYCODE=C.SECURITYCODE
LEFT JOIN
(
SELECT EID TRAD_SK_HKDAILY_EID,
SECUCODE ,
TDATE ,
TNUM ,
TAMT
FROM TRAD_SK_HKDAILY
)
E
ON B.SECURITYCODE=E.SECUCODE
AND B.TDATE =E.TDATE
)
统计信息如下：
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 6.84 6.84 0 751972 0 2
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 6 6.84 6.84 0 751972 0 2
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 157
Number of plan statistics captured: 2
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 SORT AGGREGATE (cr=375986 pr=0 pw=0 time=3422318 us)
176130 176130 176130 VIEW (cr=375986 pr=0 pw=0 time=3980666 us cost=4094 size=13 card=1)
176130 176130 176130 COUNT (cr=375986 pr=0 pw=0 time=3664535 us)
176130 176130 176130 NESTED LOOPS OUTER (cr=375986 pr=0 pw=0 time=3384154 us cost=4094 size=189 card=1)
176130 176130 176130 HASH JOIN OUTER (cr=22567 pr=0 pw=0 time=1208307 us cost=4092 size=170 card=1)
89999 89999 89999 NESTED LOOPS (cr=2588 pr=0 pw=0 time=1026279 us cost=637 size=128 card=1)
89999 89999 89999 HASH JOIN (cr=2585 pr=0 pw=0 time=248928 us cost=637 size=112 card=1)
2302 2302 2302 TABLE ACCESS BY INDEX ROWID CDSY_SECUCODE (cr=817 pr=0 pw=0 time=20036 us cost=350 size=222998 card=2593)
2326 2326 2326 INDEX SKIP SCAN IDX_CDSY_SECUCODE_LS (cr=35 pr=0 pw=0 time=6840 us cost=74 size=0 card=2598)(object id 345164)
90234 90234 90234 TABLE ACCESS FULL HK_SHORTTD_LIST (cr=1768 pr=0 pw=0 time=111762 us cost=287 size=2164968 card=83268)
89999 89999 89999 INDEX RANGE SCAN SPTM_MARKETRELATION_MARKETCODE (cr=3 pr=0 pw=0 time=384732 us cost=0 size=16 card=1)(object id 96435)
3487 3487 3487 VIEW (cr=19979 pr=0 pw=0 time=30230 us cost=3455 size=136080 card=3240)
3487 3487 3487 HASH JOIN RIGHT OUTER (cr=19979 pr=0 pw=0 time=25166 us cost=3455 size=139320 card=3240)
385 385 385 INDEX FAST FULL SCAN IDX_CUST_PUBLISHRELATION1 (cr=126 pr=0 pw=0 time=3522 us cost=12 size=4440 card=370)(object id 140038)
3487 3487 3487 TABLE ACCESS FULL CUST_PUBLISHSTOCKRELATION (cr=19853 pr=0 pw=0 time=8789 us cost=3443 size=100440 card=3240)
171831 171831 171831 INDEX RANGE SCAN IDX_TRAD_SK_HKDAILY_TSM (cr=353419 pr=0 pw=0 time=1474190 us cost=2 size=19 card=1)(object id 402680)
第三种走：IDX_TRAD_SK_HKDAILY_SMT索引
SELECT COUNT(ID)
FROM
(
SELECT /*+ index(E IDX_TRAD_SK_HKDAILY_SMT)*/
rownum ID,
A.CDSY_SECUCODE_EID ,
A.SPTM_MARKETRELATION_EID ,
B.HK_SHORTTD_LIST_EID ,
case when C.PUBLISHCODE like '402%' then C.CUST_PUBLISHSTOCKRELATION_EID else null end CUST_PUBLISHSTOCKRELATION_EID,
case when C.PUBLISHCODE like '402%' then C.CUST_PUBLISHRELATION_EID else null end CUST_PUBLISHRELATION_EID,
E.TRAD_SK_HKDAILY_EID ,
A.MSECUCODE ,
A.SECURITYSHORTNAME ,
B.TDATE DAT_TDATE ,
B.TIMEFRAME ,
B.CURRENCY ,
B.TVOL ,
B.TVAL ,
E.TNUM ,
E.TAMT ,
case when C.PUBLISHCODE like '402%' then C.PUBLISHNAME else null end STR_GICS,
case when C.PUBLISHCODE like '403%' then C.PUBLISHNAME else null end STR_GJSHY,
A.SECURITYTYPE ,
A.TRADEMARKET ,
A.TRADEMARKETCODE
FROM
(
SELECT A.EID CDSY_SECUCODE_EID ,
B.EID SPTM_MARKETRELATION_EID,
SECURITYCODE ,
A.SECURITYCODE
||
B.MARKETRELEATION MSECUCODE,
SECURITYSHORTNAME ,
SECURITYTYPE ,
TRADEMARKET ,
COMPANYCODE ,
SECURITYVARIETYCODE ,
TRADEMARKETCODE
FROM CDSY_SECUCODE A
JOIN SPTM_MARKETRELATION B
ON A.TRADEMARKETCODE=B.MARKETCODE
WHERE SECURITYTYPECODE LIKE'058001003%'
AND USESTATE ='1'
AND LISTINGSTATE<>'2'
)
A
JOIN
(
SELECT EID HK_SHORTTD_LIST_EID ,
HKCODE ,
SECURITYCODE ,
TO_DATE(TDATE,'YYYY/MM/DD') TDATE,
CURRENCY ,
TIMEFRAME ,
TVOL ,
TVAL
FROM HK_SHORTTD_LIST
)
B
ON A.SECURITYVARIETYCODE=B.HKCODE
AND A.SECURITYCODE =B.SECURITYCODE
LEFT JOIN
(
SELECT A.EID CUST_PUBLISHSTOCKRELATION_EID,
B.EID CUST_PUBLISHRELATION_EID ,
COMPANYCODE ,
SECURITYCODE ,
PUBLISHNAME,
a.PUBLISHCODE
FROM
(
SELECT EID ,
COMPANYCODE ,
SECURITYCODE,
PUBLISHCODE
FROM CUST_PUBLISHSTOCKRELATION
WHERE PUBLISHCODE LIKE'402%' or PUBLISHCODE LIKE'403%'
)
A
LEFT JOIN
(
SELECT EID ,
PUBLISHCODE,
PUBLISHNAME
FROM CUST_PUBLISHRELATION
WHERE PUBLISHCODE LIKE'402%' or PUBLISHCODE LIKE'403%'
)
B
ON A.PUBLISHCODE=B.PUBLISHCODE
)
C ON A.COMPANYCODE=C.COMPANYCODE
AND A.SECURITYCODE=C.SECURITYCODE
LEFT JOIN
(
SELECT EID TRAD_SK_HKDAILY_EID,
SECUCODE ,
TDATE ,
TNUM ,
TAMT
FROM TRAD_SK_HKDAILY
)
E
ON B.SECURITYCODE=E.SECUCODE
AND B.TDATE =E.TDATE
)
统计信息如下：
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.04 0.04 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 497.77 513.55 22608 3729688 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 497.82 513.60 22608 3729688 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 157
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1 1 1 SORT AGGREGATE (cr=3729688 pr=22608 pw=0 time=513556021 us)
177954 177954 177954 VIEW (cr=3729688 pr=22608 pw=0 time=509401174 us cost=4113 size=13 card=1)
177954 177954 177954 COUNT (cr=3729688 pr=22608 pw=0 time=508990000 us)
177954 177954 177954 NESTED LOOPS OUTER (cr=3729688 pr=22608 pw=0 time=508677448 us cost=4113 size=189 card=1)
177954 177954 177954 HASH JOIN OUTER (cr=24391 pr=1933 pw=0 time=2690219 us cost=4092 size=170 card=1)
90929 90929 90929 NESTED LOOPS (cr=4190 pr=1760 pw=0 time=1079324 us cost=637 size=128 card=1)
90929 90929 90929 HASH JOIN (cr=4187 pr=1760 pw=0 time=302237 us cost=637 size=112 card=1)
2302 2302 2302 TABLE ACCESS BY INDEX ROWID CDSY_SECUCODE (cr=811 pr=1 pw=0 time=28829 us cost=350 size=222998 card=2593)
2326 2326 2326 INDEX SKIP SCAN IDX_CDSY_SECUCODE_LS (cr=34 pr=1 pw=0 time=6623 us cost=74 size=0 card=2598)(object id 345164)
91164 91164 91164 TABLE ACCESS FULL HK_SHORTTD_LIST (cr=3376 pr=1759 pw=0 time=146284 us cost=287 size=2164968 card=83268)
90929 90929 90929 INDEX RANGE SCAN SPTM_MARKETRELATION_MARKETCODE (cr=3 pr=0 pw=0 time=406676 us cost=0 size=16 card=1)(object id 96435)
3483 3483 3483 VIEW (cr=20201 pr=173 pw=0 time=92198 us cost=3455 size=136080 card=3240)
3483 3483 3483 HASH JOIN RIGHT OUTER (cr=20201 pr=173 pw=0 time=86335 us cost=3455 size=139320 card=3240)
385 385 385 INDEX FAST FULL SCAN IDX_CUST_PUBLISHRELATION1 (cr=158 pr=119 pw=0 time=38012 us cost=12 size=4440 card=370)(object id 140038)
3483 3483 3483 TABLE ACCESS FULL CUST_PUBLISHSTOCKRELATION (cr=20043 pr=54 pw=0 time=23255 us cost=3443 size=100440 card=3240)
173601 173601 173601 INDEX RANGE SCAN IDX_TRAD_SK_HKDAILY_SMT (cr=3705297 pr=20675 pw=0 time=510094009 us cost=21 size=19 card=1)(object id 368255)
4、下面分析上面执行情况
首先看三种索引的统计信息：
SQL> select index_name,
2 blevel,
3 leaf_blocks,
4 distinct_keys,
5 clustering_factor,
6 num_rows
from dba_indexes t
7 8 where t.index_name in
9 ('IDX_TRAD_SK_HKDAILY_STM', 'IDX_TRAD_SK_HKDAILY_TSM', 'IDX_TRAD_SK_HKDAILY_SMT');
INDEX_NAME BLEVEL LEAF_BLOCKS DISTINCT_KEYSCLUSTERING_FACTOR NUM_ROWS
------------------------------ ---------- ----------- ------------- ----------------- ----------
IDX_TRAD_SK_HKDAILY_SMT 2 36579 5340489 4686724 5340489
IDX_TRAD_SK_HKDAILY_TSM 2 36488 5403645 3938252 5403645
IDX_TRAD_SK_HKDAILY_STM 2 36423 5304582 4654493 5304582
注意到blevel都是2,即每找一个数据，搜索的代价应该是一样的，集簇因子也都差不多
根据大牛lewis书中cbo说的索引的代价如下：
cost =blevel +ceiling(leaf_blocks * effective index selectivity) +ceiling(clustering_factor * effective table selectivity)
那计算结果应该上面三个索引相差不大
可是问题来了：
问题1：按理说走索引的速度应该是:
IDX_TRAD_SK_HKDAILY_TSM>IDX_TRAD_SK_HKDAILY_STM>IDX_TRAD_SK_HKDAILY_SMT(按列的区分度)，可实际情况是：
IDX_TRAD_SK_HKDAILY_STM>IDX_TRAD_SK_HKDAILY_TSM>IDX_TRAD_SK_HKDAILY_SMT ?
问题2:根据lewis公式的说法，三种代价应该差不多？
5、问题剖析
因为三种索引的叶块是相同的，数量上没有多大差别，存储的索引建，也都基本相同(不考虑索引建的存储顺序)
下面主要看一下分支块的区别：
首先查看索引段的id号，便于dump分支块结构
SQL> select object_name,object_id from dba_objects where object_name in ('IDX_TRAD_SK_HKDAILY_STM',
2 'IDX_TRAD_SK_HKDAILY_TSM','IDX_TRAD_SK_HKDAILY_SMT');
OBJECT_NAME OBJECT_ID
-------------------------------------------------------------------------------------------------------------------------------- ----------
IDX_TRAD_SK_HKDAILY_STM 402666
IDX_TRAD_SK_HKDAILY_TSM 402680
IDX_TRAD_SK_HKDAILY_SMT 368255
dump IDX_TRAD_SK_HKDAILY_STM 索引结构：
alter session set events 'immediate trace name treedump level 402666';
结构如下：
branch: 0x926fc84 153549956 (0: nrow: 105, level: 2) --root分支块
branch: 0x7f66c68 133590120 (-1: nrow: 350, level: 1) ---分支块
leaf: 0x926fc85 153549957 (-1: nrow: 146 rrow: 146) ----叶子块
下面查询该分支块的文件号和块号：
SQL> select dbms_utility.data_block_address_file(153549956) "file",
2 dbms_utility.data_block_address_block(153549956) "block"
3 from dual;
file block
---------- ----------
36 2555012
dump分支块内容：
alter system dump datafile 36 block 2555012;
内容如下：
Branch block dump
=================
row#0[8035] dba: 150702413=0x8fb894d
col 0; len 10; (10): 00 30 00 30 00 30 00 30 00 36
col 1; len 4; (4): 78 71 03 07
col 2; TERM
row#1[8014] dba: 153550258=0x926fdb2
col 0; len 10; (10): 00 30 00 30 00 30 00 31 00 34
col 1; len 4; (4): 78 68 08 11
col 2; TERM
row#2[7995] dba: 28638616=0x1b4fd98
col 0; len 10; (10): 00 30 00 30 00 30 00 32 00 31
col 1; len 2; (2): 78 66
col 2; TERM
row#3[7974] dba: 150702715=0x8fb8a7b
col 0; len 10; (10): 00 30 00 30 00 30 00 32 00 38
col 1; len 4; (4): 78 69 0c 13
col 2; TERM
row#4[7953] dba: 153550560=0x926fee0
col 0; len 10; (10): 00 30 00 30 00 30 00 33 00 36
col 1; len 4; (4): 78 64 02 09
col 2; TERM
row#5[7932] dba: 28638917=0x1b4fec5
col 0; len 10; (10): 00 30 00 30 00 30 00 34 00 34
col 1; len 4; (4): 77 c5 07 1d
col 2; TERM
row#6[7911] dba: 133590698=0x7f66eaa
col 0; len 10; (10): 00 30 00 30 00 30 00 35 00 33
col 1; len 4; (4): 78 6d 04 10
col 2; TERM
下面同样对其他两个索引结构进行分析：
alter session set events 'immediate trace name treedump level 402680';
branch: 0x8fbb784 150714244 (0: nrow: 115, level: 2)
branch: 0x1b52bcc 28650444 (-1: nrow: 322, level: 1)
leaf: 0x8fbb785 150714245 (-1: nrow: 149 rrow: 149)
SQL> select dbms_utility.data_block_address_file(150714244) "file",
2 dbms_utility.data_block_address_block(150714244) "block"
3 from dual;
file block
---------- ----------
35 3913604
alter system dump datafile 35 block 3913604;
Branch block dump
=================
row#0[8032] dba: 133705495=0x7f82f17
col 0; len 7; (7): 77 b6 0b 0f 01 01 01
col 1; len 10; (10): 00 30 00 30 00 30 00 30 00 35
col 2; TERM
row#1[8008] dba: 153562587=0x9272ddb
col 0; len 7; (7): 77 b9 0b 0e 01 01 01
col 1; len 10; (10): 00 30 00 30 00 30 00 30 00 35
col 2; TERM
row#2[7984] dba: 28650656=0x1b52ca0
col 0; len 7; (7): 77 bb 09 04 01 01 01
col 1; len 10; (10): 00 30 00 30 00 30 00 37 00 38
col 2; TERM
row#3[7960] dba: 150714722=0x8fbb962
col 0; len 7; (7): 77 bc 0c 09 01 01 01
col 1; len 10; (10): 00 30 00 30 00 31 00 34 00 37
col 2; TERM
row#4[7936] dba: 153562789=0x9272ea5
col 0; len 7; (7): 77 be 01 17 01 01 01
col 1; len 10; (10): 00 30 00 30 00 30 00 31 00 32
col 2; TERM
row#5[7912] dba: 133709671=0x7f83f67
col 0; len 7; (7): 77 bf 01 0f 01 01 01
col 1; len 10; (10): 00 30 00 30 00 31 00 34 00 35
col 2; TERM
row#6[7890] dba: 150714924=0x8fbba2c
col 0; len 7; (7): 77 bf 0b 13 01 01 01
col 1; len 8; (8): 00 30 00 30 00 30 00 31
col 2; TERM
row#7[7866] dba: 28651119=0x1b52e6f
col 0; len 7; (7): 77 c0 08 15 01 01 01
col 1; len 10; (10): 00 30 00 30 00 30 00 33 00 36
col 2; TERM
alter session set events 'immediate trace name treedump level 368255';
branch: 0x927bd84 153599364 (0: nrow: 191, level: 2)
branch: 0x7f92ac8 133769928 (-1: nrow: 192, level: 1)
leaf: 0x927bd85 153599365 (-1: nrow: 146 rrow: 146)
SQL> select dbms_utility.data_block_address_file(153599364) "file",
2 dbms_utility.data_block_address_block(153599364) "block"
3 from dual;
file block
---------- ----------
36 2604420
alter system dump datafile 36 block 2604420;
row#0[8016] dba: 153599501=0x927be0d
col 0; len 10; (10): 00 30 00 30 00 30 00 30 00 34
col 1; len 18; (18): 00 30 00 36 00 39 00 30 00 30 00 32 00 30 00 30 00 34
col 2; len 4; (4): 77 bd 04 18
col 3; TERM
row#1[7976] dba: 133770064=0x7f92b50
col 0; len 10; (10): 00 30 00 30 00 30 00 30 00 38
col 1; len 18; (18): 00 30 00 36 00 39 00 30 00 30 00 32 00 30 00 30 00 34
col 2; len 4; (4): 78 65 09 0b
col 3; TERM
row#2[7936] dba: 153599637=0x927be95
col 0; len 10; (10): 00 30 00 30 00 30 00 31 00 32
col 1; len 18; (18): 00 30 00 36 00 39 00 30 00 30 00 32 00 30 00 30 00 34
col 2; len 4; (4): 77 c7 05 1a
col 3; TERM
row#3[7896] dba: 133770200=0x7f92bd8
col 0; len 10; (10): 00 30 00 30 00 30 00 31 00 36
col 1; len 18; (18): 00 30 00 36 00 39 00 30 00 30 00 32 00 30 00 30 00 34
col 2; len 4; (4): 77 c4 01 05
col 3; TERM
row#4[7857] dba: 153599773=0x927bf1d
col 0; len 10; (10): 00 30 00 30 00 30 00 31 00 39
col 1; len 18; (18): 00 30 00 36 00 39 00 30 00 30 00 32 00 30 00 30 00 34
col 2; len 3; (3): 78 70 09
col 3; TERM
row#5[7817] dba: 133770336=0x7f92c60
col 0; len 10; (10): 00 30 00 30 00 30 00 32 00 33
col 1; len 18; (18): 00 30 00 36 00 39 00 30 00 30 00 32 00 30 00 30 00 34
col 2; len 4; (4): 78 66 0a 0b
col 3; TERM
6、结论猜想
IDX_TRAD_SK_HKDAILY_STM 索引块的分支块由两列构成，第一列长度为10，即SECUCODE列的全部，因为通过该列，
没法判断索引搜索路线，区分度不高，需要借助第二列加以区分，第二列长度不固定，只要索引能知道向左走，还是向右走，
就可以了，没必要存储第二列的全部，这样每次访问分支块的代价，用分支块中存储列的长度来比作：10+4=14
IDX_TRAD_SK_HKDAILY_TSM 索引块的分支块由两列构成，第一列长度为7，即TDATE列的全部，该列依旧区分度不高，
并且大部分需要借助第二列全部(SECUCODE列)，即长度为10，这样代价就比第一高点，这样每次访问分支块的代价，用分支块中存储列的长度来比作：10+7=17
IDX_TRAD_SK_HKDAILY_SMT 索引块的分支块由三列构成，第一列长度为10，即SECUCODE列的全部，因为通过该列，
没法判断索引搜索路线，需要借助第二列：MARKET，由于第二列的区分度为0，所以还需借助第三列TDATE的部分来进行区分，这样代价就是：10+18+4=32
似乎从这个可以知道上面的原因：
INDEX RANGE SCAN IDX_TRAD_SK_HKDAILY_STM (cr=38998
INDEX RANGE SCAN IDX_TRAD_SK_HKDAILY_TSM (cr=353419
INDEX RANGE SCAN IDX_TRAD_SK_HKDAILY_SMT (cr=3705297
逻辑读居然相差这么大，就是因为每次读取分支快的大小不同。。。。。
从上面可以看到，并不是区分度越大，作为主导列，效果就越好，
当然了，如果只需要该列，就可以区分了，那当然是该列作为主导列
是比较好的，不然，还要看跟后面几个列组合起来的区分度，
即相同的区分度，如果我组合所需要的字节比你少，即我的代价比你优
oracle区分度公式,区分度越大的列，作为主导列，索引效果越好？相关推荐
- 交叉熵损失函数的通用性（为什么深度学习DL普遍用它）：预测输出与 y 差得越多，L 的值越大，也就是说对当前模型的 “ 惩罚 ” 越大，而且是非线性增大是一种类似指数增长的级别，结论：它对结果有引导性
交叉熵损失函数的通用性(为什么深度学习DL普遍用它):预测输出与 y 差得越多,L 的值越大,也就是说对当前模型的 " 惩罚 " 越大,而且是非线性增大是一种类似指数增长的级别,结 ...
- 感量越大抑制频率约低_开关电源电磁兼容进级-EMI传导输入滤波器的设计理论（ED-TEST上海）...
在刚刚结束的EDTEST-上海站:开关电源电磁兼容进级优化设计:对于有开关电源的产品及控制系统:其输入EMI低通滤波器放置在输入端对系统的EMS设计也是非常关键的! 再补充详解一下:我讲的开关电源系统 ...
- 感量越大抑制频率约低_电子产品：开关电源系统EMI传导快速设计理论（讲义部分）...
研讨会针对工程师希望了解电子产品EMI-传导快速设计输入滤波器的设计细节:提供给大家参考!开关电源的输入EMI低通滤波器放置在输入端对系统的电快速脉冲群也是有帮助的! 我再补充一下:我讲的下面的开关电 ...
- 天线越大越好吗_中波天线尺寸越大接收信号越强么？
中波广播的远程接收 纵观百年无线电广播史,中波广播可谓渊远流长,时至今日,仍然 长盛不衰,尽管短波广播可以跨地域,调频广播有着良好的音质, 但中波广播仍有着不可替代的地位.玩(儿)腻了短波和FM的接收 ...
- 关于为什么频宽越大传输越快 、 频率越高传输距离越短
关于为什么频宽越大传输越快 . 频率越高传输距离越短 频宽可以理解为水管,通常网络传输中越快的意思是单位时间内数据的吞吐量越大表示越快,频宽越宽水管越大,在同等流速情况下,水管越大的在单位时间内流出的 ...
- 计算机显存影响什么,笔记本独立显存是什么意思（电脑误区：显存越大，性能就越好）...
说到显卡,A卡N卡.高档中档一类的,主要是根据显示芯片(GPU)划分的.那么除了GPU之外,影响显卡性能的因素还有什么呢?很多小伙伴肯定知道,没错,就是显存.不过显存是怎么影响性能,在选购时又该注意些 ...
- 音响喇叭尺寸越大，音质就越好吗？请大神指教？
1 音响喇叭尺寸越大,音质就越好吗?对这个问题要一分为二看. 对于小作坊音响产品,多使用几只彩灯,低廉大小喇叭做些廉价音响,外观花里胡哨,用低廉价格争抢音响市场.他们的喇叭虽大,但音箱内部无分频器或一 ...
- 大数据----数据仓库设计基础(实列演示)
文章目录 关系数据模型 关系数据模型中的结构 关系完整性 规范化 关系数据模型与数据仓库 维度数据模型 维度数据模型建模过程 维度规范化 维度数据模型的特点 星型模式 雪花模式 Data Vault模 ...
- 基金规模越大，未来收益越差？小基金竟能跑赢大基金2倍。【邢不行】
引言: 邢不行的系列帖子"量化小讲堂",通过实际案例教初学者使用python进行量化投Z,了解行业研究方向 这是邢不行第85期量化小课堂分享 作者 l 邢不行.密斯锌硒 2020年 ...
- ORACLE和MYSQL的九大区别
ORACLE和MYSQL的九大区别 1.组函数用法规则 mysql中组函数在select语句中可以随意使用,但在oracle中如果查询语句中有组函数,那其他列名必须是组函数处理过的,或者是group ...
最新文章
- 【2021】清华大学《高级机器学习》课件和专家特邀报告(附pdf下载)
- 大端和小端，字节对齐
- Linux下Bond技术怎样实现负载均衡的步骤
- 仿射密码介绍以及解题脚本
- 关于微信支付的退款那些事
- c语言 int和字母,[求助]从一个包含有字母和数字的文本文件读入INT型变量
- erlang csv
- switch off c语言,逆向工程 | C 语言之 switch-case 分支
- 在写新邮件时，在地址栏中敲入前几个字母，对于已熟悉的收件人，outlook会弹出列表...
- 用户输入和命令行参数
- bzoj 1263: [SCOI2006]整数划分
- Django项目实践4 - Django站点管理(后台管理员)
- 定时器应用-页面弹出广告
- JS/VUE 自定义效验 统一社会信用代码 营业执照注册号
- js 获得较浅的颜色_了解较少的颜色功能
- 货币银行学重点内容复习
- 标准盒模型与怪异盒模型的区别
- 在马克思手稿中有一道趣味的数学问题：一共有30个人，可能包括男人，女人和小孩。他们在一家饭馆吃饭共花了50先令，其中每个男人花3先令，每个女人花2先令，每个小孩花1先令。请问男人、女人和小孩各几人？
- Js验证身份证是否正确
- 数据库设计阶段和三个重要的设计模型