- 浏览: 227219 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
yjz毕竟是云:
总结的不错!
字符流与字节流的区别 -
yiqing:
不错 有帮助
HTTP Basic Authentication认证 -
assertme:
a8350020 写道第一种方法的线程池其实是没有意义的Fut ...
线程返回值的方式介绍 -
a8350020:
第一种方法的线程池其实是没有意义的Future.get()会阻 ...
线程返回值的方式介绍 -
endual:
一个上午都无法配置好的我的eclipse使用svn 哎。。。
总结一下SVN的用法
Index Full Scan vs Index Fast Full Scan index full scan和index fast full scan是指同样的东西吗?答案是no。两者虽然从字面上看起来差不多, 但是实现的机制完全不同。我们一起来看看两者的区别在哪里? 首先来看一下IFS,FFS能用在哪里: 在一句sql中,如果我们想搜索的列都包含在索引里面的话,那么index full scan 和 index fast full scan 都可以被采用代替full table scan。比如以下语句: SQL> CREATE TABLE TEST AS SELECT * FROM dba_objects WHERE 0=1; SQL> CREATE INDEX ind_test_id ON TEST(object_id); SQL> INSERT INTO TEST SELECT * FROM dba_objects WHERE object_id IS NOT NULL AND object_id > 10000 ORDER BY object_id DESC; 17837 rows created. SQL> analyze table test compute statistics for table for all columns for all indexes; Table analyzed. SQL> set autotrace trace; SQL> select object_id from test; 17837 rows selected. Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=68 Card=17837 Bytes=71348) 1 0 TABLE ACCESS (FULL) OF 'TEST' (Cost=68 Card=17837 Bytes=71348) 这时候 Oracle会选择全表扫描,因为 object_id 列默认是可以为null的,来修改成 not null: SQL>alter table test modify(object_id not null); SQL> select object_id from test; 17837 rows selected. Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=17837 Bytes=71348) 1 0 INDEX (FAST FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost=11 Card=17837 Bytes=71348) 当然我们也可以使用index full scan: SQL> select/*+ index(test ind_TEST_ID)*/ object_id from test; 17837 rows selected. Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=41 Card=17837 Bytes=71348) 1 0 INDEX (FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost=101 Card=17837 Bytes=71348) 我们看到了两者都可以在这种情况下使用,那么他们有什么区别呢?有个地方可以看出两者的区别, 来看一下两者的输出结果,为了让大家看清楚一点,我们只取10行。 INDEX FAST FULL SCAN SQL> select object_id from test where rownum<11; OBJECT_ID ---------- 66266 66267 66268 66269 66270 66271 66272 66273 66274 66275 10 rows selected. INDEX FULL SCAN SQL> select/*+ index(test ind_TEST_ID)*/ object_id from test where rownum<11; OBJECT_ID ---------- 10616 12177 12178 12179 12301 13495 13536 13539 13923 16503 10 rows selected. 可以看到两者的结果完全不一样,这是为什么呢?这是因为当进行index full scan的时候 oracle定位到索引的root block,然后到branch block(如果有的话),再定位到第一个leaf block, 然后根据leaf block的双向链表顺序读取。它所读取的块都是有顺序的,也是经过排序的。 而index fast full scan则不同,它是从段头开始,读取包含位图块,root block,所有的branch block, leaf block,读取的顺序完全有物理存储位置决定,并采取多块读,没次读取db_file_multiblock_read_count个块。 这就是为什么两者的结果区别如此之大的原因,我们再仔细跟踪一下这两条语句。首先来看一下索引的结构 SQL> select object_id from dba_objects where object_name='IND_TEST_ID'; OBJECT_ID ---------- 70591 索引的object_id为70591,使用tree dump可以看到索引树的结构 SQL> ALTER SESSION SET EVENTS 'immediate trace name TREEDUMP level 70591'; ----- begin tree dump branch: 0x6809b8d 109091725 (0: nrow: 100, level: 1) leaf: 0x6809b96 109091734 (-1: nrow: 294 rrow: 0) leaf: 0x6c07ec1 113278657 (0: nrow: 262 rrow: 0) leaf: 0x6c07ebd 113278653 (1: nrow: 518 rrow: 0) leaf: 0x6c07eb1 113278641 (2: nrow: 524 rrow: 0) leaf: 0x6c07ead 113278637 (3: nrow: 524 rrow: 0) leaf: 0x6c07ea9 113278633 (4: nrow: 524 rrow: 0) leaf: 0x6c07ea5 113278629 (5: nrow: 524 rrow: 0) leaf: 0x6c07ea1 113278625 (6: nrow: 524 rrow: 0) leaf: 0x6c07e9d 113278621 (7: nrow: 524 rrow: 0) leaf: 0x6c07e99 113278617 (8: nrow: 524 rrow: 0) leaf: 0x6c07e95 113278613 (9: nrow: 532 rrow: 0) leaf: 0x6c07e91 113278609 (10: nrow: 524 rrow: 0) leaf: 0x6c07e8d 113278605 (11: nrow: 524 rrow: 0) leaf: 0x6c07ec8 113278664 (12: nrow: 524 rrow: 0) leaf: 0x6c07ec4 113278660 (13: nrow: 524 rrow: 0) leaf: 0x6c07ec0 113278656 (14: nrow: 524 rrow: 0) leaf: 0x6c07ebc 113278652 (15: nrow: 524 rrow: 0) leaf: 0x6809bb2 109091762 (16: nrow: 524 rrow: 0) leaf: 0x6c07eb8 113278648 (17: nrow: 524 rrow: 0) leaf: 0x6c07eb4 113278644 (18: nrow: 524 rrow: 0) leaf: 0x6c07eb0 113278640 (19: nrow: 524 rrow: 0) leaf: 0x6c07eac 113278636 (20: nrow: 524 rrow: 0) leaf: 0x6809bae 109091758 (21: nrow: 524 rrow: 0) leaf: 0x6c07ea8 113278632 (22: nrow: 524 rrow: 0) leaf: 0x6c07ea4 113278628 (23: nrow: 524 rrow: 0) leaf: 0x6c07ea0 113278624 (24: nrow: 105 rrow: 105) leaf: 0x6c07e9c 113278620 (25: nrow: 129 rrow: 129) leaf: 0x6c07eb9 113278649 (26: nrow: 123 rrow: 123) leaf: 0x6809baa 109091754 (27: nrow: 246 rrow: 246) leaf: 0x6c07e98 113278616 (28: nrow: 246 rrow: 246) leaf: 0x6c07e94 113278612 (29: nrow: 246 rrow: 246) leaf: 0x6809ba6 109091750 (30: nrow: 246 rrow: 246) leaf: 0x6809bce 109091790 (31: nrow: 246 rrow: 246) leaf: 0x6809bca 109091786 (32: nrow: 246 rrow: 246) leaf: 0x6809c05 109091845 (33: nrow: 248 rrow: 248) leaf: 0x6809c01 109091841 (34: nrow: 246 rrow: 246) leaf: 0x6809bfd 109091837 (35: nrow: 246 rrow: 246) leaf: 0x6809bf9 109091833 (36: nrow: 246 rrow: 246) leaf: 0x6809bf5 109091829 (37: nrow: 246 rrow: 246) leaf: 0x6809bf1 109091825 (38: nrow: 246 rrow: 246) leaf: 0x6809bed 109091821 (39: nrow: 246 rrow: 246) leaf: 0x6809be9 109091817 (40: nrow: 246 rrow: 246) leaf: 0x6809be5 109091813 (41: nrow: 246 rrow: 246) leaf: 0x6809be1 109091809 (42: nrow: 246 rrow: 246) leaf: 0x6809bdd 109091805 (43: nrow: 246 rrow: 246) leaf: 0x6809bd9 109091801 (44: nrow: 246 rrow: 246) leaf: 0x6809bd5 109091797 (45: nrow: 246 rrow: 246) leaf: 0x6809bd1 109091793 (46: nrow: 248 rrow: 248) leaf: 0x6809bcd 109091789 (47: nrow: 246 rrow: 246) leaf: 0x6809bc9 109091785 (48: nrow: 246 rrow: 246) leaf: 0x6809c08 109091848 (49: nrow: 246 rrow: 246) leaf: 0x6809c04 109091844 (50: nrow: 246 rrow: 246) leaf: 0x6809c00 109091840 (51: nrow: 246 rrow: 246) leaf: 0x6809bfc 109091836 (52: nrow: 246 rrow: 246) leaf: 0x6809bf8 109091832 (53: nrow: 246 rrow: 246) leaf: 0x6809bf4 109091828 (54: nrow: 246 rrow: 246) leaf: 0x6809bf0 109091824 (55: nrow: 246 rrow: 246) leaf: 0x6809bec 109091820 (56: nrow: 246 rrow: 246) leaf: 0x6809be8 109091816 (57: nrow: 246 rrow: 246) leaf: 0x6809be4 109091812 (58: nrow: 246 rrow: 246) leaf: 0x6809be0 109091808 (59: nrow: 248 rrow: 248) leaf: 0x6809bdc 109091804 (60: nrow: 246 rrow: 246) leaf: 0x6809bd8 109091800 (61: nrow: 246 rrow: 246) leaf: 0x6809bd4 109091796 (62: nrow: 246 rrow: 246) leaf: 0x6809bd0 109091792 (63: nrow: 246 rrow: 246) leaf: 0x6809bcc 109091788 (64: nrow: 246 rrow: 246) leaf: 0x6809c07 109091847 (65: nrow: 246 rrow: 246) leaf: 0x6809c03 109091843 (66: nrow: 246 rrow: 246) leaf: 0x6809bff 109091839 (67: nrow: 246 rrow: 246) leaf: 0x6809bfb 109091835 (68: nrow: 246 rrow: 246) leaf: 0x6809bf7 109091831 (69: nrow: 246 rrow: 246) leaf: 0x6809bf3 109091827 (70: nrow: 246 rrow: 246) leaf: 0x6809bef 109091823 (71: nrow: 246 rrow: 246) leaf: 0x6809beb 109091819 (72: nrow: 248 rrow: 248) leaf: 0x6809be7 109091815 (73: nrow: 246 rrow: 246) leaf: 0x6809be3 109091811 (74: nrow: 246 rrow: 246) leaf: 0x6809bdf 109091807 (75: nrow: 246 rrow: 246) leaf: 0x6809bdb 109091803 (76: nrow: 246 rrow: 246) leaf: 0x6809bd7 109091799 (77: nrow: 246 rrow: 246) leaf: 0x6809bd3 109091795 (78: nrow: 246 rrow: 246) leaf: 0x6809bcf 109091791 (79: nrow: 246 rrow: 246) leaf: 0x6809bcb 109091787 (80: nrow: 246 rrow: 246) leaf: 0x6809c06 109091846 (81: nrow: 246 rrow: 246) leaf: 0x6809c02 109091842 (82: nrow: 246 rrow: 246) leaf: 0x6809bfe 109091838 (83: nrow: 246 rrow: 246) leaf: 0x6809bfa 109091834 (84: nrow: 246 rrow: 246) leaf: 0x6809ba2 109091746 (85: nrow: 129 rrow: 129) leaf: 0x6c07eb5 113278645 (86: nrow: 123 rrow: 123) leaf: 0x6809bf6 109091830 (87: nrow: 246 rrow: 246) leaf: 0x6809bf2 109091826 (88: nrow: 246 rrow: 246) leaf: 0x6809bee 109091822 (89: nrow: 246 rrow: 246) leaf: 0x6809bea 109091818 (90: nrow: 246 rrow: 246) leaf: 0x6809b9e 109091742 (91: nrow: 246 rrow: 246) leaf: 0x6809be6 109091814 (92: nrow: 246 rrow: 246) leaf: 0x6809be2 109091810 (93: nrow: 246 rrow: 246) leaf: 0x6809bde 109091806 (94: nrow: 246 rrow: 246) leaf: 0x6809bda 109091802 (95: nrow: 246 rrow: 246) leaf: 0x6809b9a 109091738 (96: nrow: 246 rrow: 246) leaf: 0x6809bd6 109091798 (97: nrow: 246 rrow: 246) leaf: 0x6809bd2 109091794 (98: nrow: 246 rrow: 246) ----- end tree dump index full scan读取的是0x6c07ea0 这个块,而index fast full scan读取的是 0x6809b9a这个块也就是包含数据的物理存储位置最前的块。分别看一下这两个块的内容 0x6c07ea0 =十进制的113278624 0x6809b9a =十进制的109091738 SQL> select dbms_utility.data_block_address_file(113278624) "file",dbms_utility.data_block_address_block(113278624) "block" from dual; file block ---------- ---------- 27 32416 SQL> select dbms_utility.data_block_address_file(109091738) "file",dbms_utility.data_block_address_block(109091738)"block" from dual; file block ---------- ---------- 26 39834 SQL> alter system dump datafile 27 block 32416; SQL> alter system dump datafile 26 block 39834; block 32416的前10行 row#0[6564] flag: -----, lock: 2 col 0; len 4; (4): c3 02 07 11 col 1; len 6; (6): 07 00 7c 20 00 2b row#1[6578] flag: -----, lock: 2 col 0; len 4; (4): c3 02 16 4e col 1; len 6; (6): 07 00 7c 20 00 2a row#2[6592] flag: -----, lock: 2 col 0; len 4; (4): c3 02 16 4f col 1; len 6; (6): 07 00 7c 20 00 29 row#3[6606] flag: -----, lock: 2 col 0; len 4; (4): c3 02 16 50 col 1; len 6; (6): 07 00 7c 20 00 28 row#4[6620] flag: -----, lock: 2 col 0; len 4; (4): c3 02 18 02 col 1; len 6; (6): 07 00 7c 20 00 27 row#5[6634] flag: -----, lock: 2 col 0; len 4; (4): c3 02 23 60 col 1; len 6; (6): 07 00 7c 20 00 26 row#6[6648] flag: -----, lock: 2 col 0; len 4; (4): c3 02 24 25 col 1; len 6; (6): 07 00 7c 20 00 25 row#7[6662] flag: -----, lock: 2 col 0; len 4; (4): c3 02 24 28 col 1; len 6; (6): 07 00 7c 20 00 24 row#8[6676] flag: -----, lock: 2 col 0; len 4; (4): c3 02 28 18 col 1; len 6; (6): 07 00 7c 20 00 23 row#9[6690] flag: -----, lock: 2 col 0; len 4; (4): c3 02 42 04 col 1; len 6; (6): 07 00 7c 20 00 22 block 39834的前10行 row#0[4591] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 43 col 1; len 6; (6): 02 81 71 f6 00 36 row#1[4605] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 44 col 1; len 6; (6): 02 81 71 f6 00 35 row#2[4619] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 45 col 1; len 6; (6): 02 81 71 f6 00 34 row#3[4633] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 46 col 1; len 6; (6): 02 81 71 f6 00 33 row#4[4647] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 47 col 1; len 6; (6): 02 81 71 f6 00 32 row#5[4661] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 48 col 1; len 6; (6): 02 81 71 f6 00 31 row#6[4675] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 49 col 1; len 6; (6): 02 81 71 f6 00 30 row#7[4689] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 4a col 1; len 6; (6): 02 81 71 f6 00 2f row#8[4703] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 4b col 1; len 6; (6): 02 81 71 f6 00 2e row#9[4717] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 4c col 1; len 6; (6): 02 81 71 f6 00 2d 对照一下前面的结果集 block 32416的第一行为10616,数据内的存储格式应该为 SQL> select dump(10616,16) from dual; DUMP(10616,16) ---------------------- Typ=2 Len=4: c3,2,7,11 确实等于dump block所看到的 row#0[6564] flag: -----, lock: 2 col 0; len 4; (4): c3 02 07 11 col 1; len 6; (6): 07 00 7c 20 00 2b 再看block 39834的第1行 SQL> select dump(66266,16) from dual; DUMP(66266,16) ----------------------- Typ=2 Len=4: c3,7,3f,43 跟dump 的结果也一样 row#0[4591] flag: -----, lock: 2 col 0; len 4; (4): c3 07 3f 43 col 1; len 6; (6): 02 81 71 f6 00 36 这就证明了上面所说的index full scan和index fast full scan的不同。 我们也可以用10046事件去跟踪两者走的路径。 SQL> ALTER SESSION SET EVENTS 'immediate trace name flush_cache'; (清空buffer cache,以便观看'db file sequential read','db file scattered read'事件)。 SQL> alter session set events'10046 trace name context forever,level 12'; Session altered. SQL> select object_id from test where rownum<11; OBJECT_ID ---------- 66266 66267 66268 66269 66270 66271 66272 66273 66274 66275 10 rows selected. SQL> alter session set events'10046 trace name context off'; Session altered. [oracle@csdbc udump]$ grep read cs-dbc_ora_15596.trc Redo thread mounted by this instance: 1 WAIT #1: nam='db file sequential read' ela= 33 p1=26 p2=39820 p3=1 WAIT #1: nam='db file sequential read' ela= 21 p1=26 p2=39817 p3=1 WAIT #1: nam='db file sequential read' ela= 17 p1=26 p2=39819 p3=1 WAIT #1: nam='db file parallel read' ela= 53 p1=2 p2=2 p3=2 WAIT #1: nam='db file scattered read' ela= 466 p1=26 p2=39821 p3=16 最前面的'db file sequential read'是由于读段头等操作,我们来关注'db file scattered read'事件, 因为index fast full scan是采用多块读,从39821开始读取db_file_multiblock_read_count个块(本例里设置为16)。我们关心的39834块正位于其中。 再来看index full scan的10046 trace SQL> ALTER SESSION SET EVENTS 'immediate trace name flush_cache'; (清空buffer cache,以便观看'db file sequential read','db file scattered read'事件)。 SQL> alter session set events'10046 trace name context forever,level 12'; Session altered. SQL> OBJECT_ID ---------- 10616 12177 12178 12179 12301 13495 13536 13539 13923 16503 10 rows selected. SQL> alter session set events'10046 trace name context off'; Session altered. [oracle@csdbc udump]$ grep read cs-dbc_ora_15609.trc Redo thread mounted by this instance: 1 WAIT #1: nam='db file sequential read' ela= 49 p1=26 p2=39821 p3=1 root block,正是先前索引树dump里面的 0x6809b8d WAIT #1: nam='db file sequential read' ela= 32 p1=26 p2=39830 p3=1 WAIT #1: nam='db file sequential read' ela= 40 p1=27 p2=32449 p3=1 WAIT #1: nam='db file sequential read' ela= 35 p1=27 p2=32445 p3=1 WAIT #1: nam='db file sequential read' ela= 28 p1=27 p2=32433 p3=1 WAIT #1: nam='db file sequential read' ela= 19 p1=27 p2=32429 p3=1 WAIT #1: nam='db file sequential read' ela= 34 p1=27 p2=32425 p3=1 WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32421 p3=1 WAIT #1: nam='db file sequential read' ela= 33 p1=27 p2=32417 p3=1 WAIT #1: nam='db file sequential read' ela= 29 p1=27 p2=32413 p3=1 WAIT #1: nam='db file sequential read' ela= 37 p1=27 p2=32409 p3=1 WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32405 p3=1 WAIT #1: nam='db file sequential read' ela= 35 p1=27 p2=32401 p3=1 WAIT #1: nam='db file sequential read' ela= 34 p1=27 p2=32397 p3=1 WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32456 p3=1 WAIT #1: nam='db file sequential read' ela= 29 p1=27 p2=32452 p3=1 WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32448 p3=1 WAIT #1: nam='db file sequential read' ela= 30 p1=27 p2=32444 p3=1 WAIT #1: nam='db file sequential read' ela= 38 p1=26 p2=39858 p3=1 WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32440 p3=1 WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32436 p3=1 WAIT #1: nam='db file sequential read' ela= 35 p1=27 p2=32432 p3=1 WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32428 p3=1 WAIT #1: nam='db file sequential read' ela= 29 p1=26 p2=39854 p3=1 WAIT #1: nam='db file sequential read' ela= 36 p1=27 p2=32424 p3=1 WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32420 p3=1 WAIT #1: nam='db file sequential read' ela= 36 p1=27 p2=32416 p3=1 index full scan走的路径正是文章开始所提到的定位到root block,然后根据leaf block链表一路读取块。 看到这里大家应该比较了解index full scan 和index fast full scan的区别了,最后补充一下 index full scan 和 index fast full scan 在排序上的不同。 SQL> set autotrace trace; SQL> select object_id from test order by object_id; 17837 rows selected. Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=41 Card=17837 Bytes=71348) 1 0 INDEX (FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost=101 Card=17837 Bytes=71348) 由于有排序所以oracle自动选择了index full scan避免了排序。那么强制用index fast full scan呢? SQL> select/*+ index_ffs(test ind_test_id)*/object_id from test order by object_id; 17837 rows selected. Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=59 Card=17837 Bytes=71348) 1 0 SORT (ORDER BY) (Cost=59 Card=17837 Bytes=71348) 2 1 INDEX (FAST FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost=11 Card=17837 Bytes=71348) index fast full scan会多一步sort order by,相信仔细看过这篇文章的人能知道其中结果了吧,还不知道的人请在文章中自己找答案吧。
发表评论
-
转载 HashMap实现分析
2011-08-29 00:30 826** *@author annegu *@da ... -
oracle语句优化
2011-08-25 13:52 936Dear All 系统里有下面的语句,其中MDN是 ... -
转 读写分离
2011-08-23 23:51 1249随着一个网站的业务 ... -
拦截器与过滤器
2011-08-21 22:36 1010很多人都了解过滤器也听说过拦截器,但是要是区分它们的不同 ... -
sql写法的注意事项
2011-08-20 23:20 946基本的Sql编写注意事 ... -
字符流与字节流的区别
2011-08-20 22:50 12481 推荐 流是一个有序的字节序列,可作为一个输 ... -
SOCKET 与 HTTP
2011-08-20 22:32 11144.1 SOCKET与TCP/IP 关系 Sock ... -
tomcat中的几点配置说明
2011-08-19 22:20 9521. 如何加大tomcat连接数 在tomcat配置文 ... -
关于struts1和struts2及webork的单例和多实例
2011-08-18 23:31 844老是看到不会的问题就像转过来,记录下来,以后好看,一定 ... -
线程池的原理和连接池的原理
2011-08-18 23:18 808线程池的原理: ... -
非常好的Spring源码分析链接
2011-08-18 23:06 822http://www.ibm.com/developerwor ... -
oralce sql监控
2011-06-23 16:48 933emctl start dbconsole访问地址为:http ... -
Linux系统 学习
2011-05-31 15:33 866%mem 内存使用率 virt ... -
如何重新配置Oracle的EM Database Control
2011-05-30 17:59 886如何重新配置Oracle的 ... -
流控 demo
2011-05-05 23:05 829http://www.iteye.com/topic/19 ... -
基础VI命令学习
2011-04-21 14:13 793i编辑器是所有Unix及Linux系统下标准的编辑器,它 ... -
hibernate session统一管理的配置
2011-03-31 10:24 1062public class FlushedOpenSess ... -
查看连接池的配置
2011-03-30 16:51 1029<servlet> <serv ... -
保留一些 电信方面知识的链接
2011-03-21 14:46 806保留一些 电信方面知识的链接 写道 http://ww ... -
关于移动方面的基础业务知识(待续)
2011-03-21 14:19 933UA:用户代理(User Agent) ...
相关推荐
现在发现在12c版本的数据库中,有很多业务SQL执行计划应该选择index range scan,但是选择了index fast full scan,消耗了多余的IO。
sql学习 05.INDEX FAST FULL SCAN.sql
当需要快速获取大量数据且不需要保持特定顺序时,INDEX FAST FULL SCAN 是理想选择。它可以利用多处理器的优势,提高查询性能。 4. **INDEX RANGE SCAN** 当查询涉及一个范围(如 BETWEEN 或 >, 操作符)时,...
sql学习 04.INDEX FULL SCAN.sql
sql学习 06.INDEX FULL SCAN (MINMAX).sql
5.索引快速全扫描(INDEX FAST FULL SCAN) 索引唯一扫描(INDEX UNIQUE SCAN) 通过这种索引访问数据的特点是对于某个特定的值只返回一行数据,通常如果在查询谓语中使用UNIQE和PRIMARY KEY索引的列作为条件的时候会...
INDEX FAST FULL SCAN与INDEX FULL SCAN类似,但前者只适用于B树索引,且索引包含被选择列的数据。当查询列数据量大,且需要快速检索所有数据时,Oracle会优先考虑此模式。例如: ```sql SELECT object_type FROM ...
全扫描主要分为两种类型:全表扫描(Full Table Scan, FTS)和全索引扫描(Full Index Scan, FIS)。全表扫描是指数据库系统遍历整个表的所有数据块,逐行提取所需数据。这种操作在处理大量数据时可能效率较低,但对...
【标题】"Codelab_ScanKit_DefaultView_Full_Demo.zip" 提供的是一个完整的二维码扫描示例项目,适用于Android平台。这个压缩包包含了一个已经实现并优化过的扫码功能,用户可以直接下载并运行,无需进行任何代码...
- **B树索引扫描**:包括`INDEX UNIQUE SCAN`、`INDEX RANGE SCAN`、`INDEX FULL SCAN`、`INDEX FAST FULL SCAN`和`INDEX SKIP SCAN`。其中,`INDEX FULL SCAN (MIN/MAX)`是一种特殊的扫描方式,用于高效获取索引的...
传统的索引扫描,如全索引扫描(Full Index Scan)和索引唯一扫描(Index Only Scan),通常要求WHERE子句中的条件与索引的所有字段匹配。然而,松散的索引扫描允许查询仅基于索引的一部分字段进行,即使这些字段不覆盖...
1. 扫描方式差异:`REBUILD`通常使用`INDEX FAST FULL SCAN`或`TABLE FULL SCAN`,取决于统计信息的成本。`REBUILD ONLINE`则执行表扫描,两者均涉及排序操作。 2. `REBUILD`会阻塞DML操作,而`REBUILD ONLINE`不会...
- **全扫描**:包括表全扫描、全分区扫描和全索引扫描(如`index fast full scan`和`index full scan`)。 - **局部扫描**:涉及索引局部扫描(如`index unique scan`、`index range scan`和`index full scan(min/...
3. **INDEX FAST FULL SCAN**:快速全文扫描,可以并行访问索引,速度较快,但返回的数据不按索引顺序排列。 4. **INDEX RANGE SCAN**:针对特定范围的查询,如 BETWEEN 或者 IN 操作符,只扫描索引中的一部分。 5...
(4)索引快速扫描(index fast full scan): 三、表之间的连接 Oracle 连接方法有三种: 1. 排序 - 合并连接(Sort Merge Join, SMJ): 2. 嵌套循环(Nested Loops, NL): 3. 哈希连接(Hash Join, HJ)...
2. 索引扫描(Index Scan):索引唯一扫描(index unique scan)、索引范围扫描(index range scan)、索引全扫描(index full scan)、索引快速扫描(index fast full scan)。 3. 表访问方式:全表扫描、散列获取...
该文件主要是针对HP_LaserJet_MFP_M436_Print_Scan_Drivers的驱动,win10上安装该打印机,驱动可能无法安装,手动安装该驱动后再重新添加打印机 ,即可正常使用HP436 系列打印机
- **快速全索引扫描(Fast Full Index Scan)**:一次性读取所有索引块,效率高于Index Full Scan,适用于索引较小的情况。 7. **影响索引使用的注意事项**: - 选择性:索引列的选择性越高(即不同值越多),...
优化器在连接表的同时,还要选择访问单表的最佳方式,包括全表扫描、索引扫描(Index unique scan、index range scan、index full scan、index fast full scan、index skip scan)。选择哪种方式取决于数据分布、...