- 浏览: 105913 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (75)
- JVM (22)
- 数据结构 (11)
- java 基础 (16)
- gc (6)
- jmock (1)
- Google (2)
- MapReduce (1)
- Memory (2)
- 算法 (2)
- cglib (1)
- jdk (3)
- 虚拟机 (3)
- 安全 (2)
- 多线程 (1)
- 工作 (1)
- 生活 (1)
- MongoDB (2)
- Hadoop (4)
- HDFS (2)
- cms (2)
- Spring (1)
- 网络协议 (1)
- GitHub (1)
- MYSQL 调优和使用必读(转) (1)
- 分布式 (2)
- Big Data (0)
- 技术Blog (1)
- Hbase (2)
- Zookeeper (1)
- paper (0)
最新评论
-
lzc_java:
Java线程安全兼谈DCL -
select*from爱:
it's nice
IT业薪水大揭秘
5.3 重建 B 树索引对于查询性能的影响
最后我们来看一下重建索引对于性能的提高到底会有什么作用。假设我们有一个表,该表具有 1 百万条记录,占用了 100000 个数据块。而在该表上存在一个索引,在重建之前的 pct_used 为 50% ,高度为 3 ,分支节点块数为 40 个,再加一个根节点块,叶子节点数为 10000 个;重建该索引以后, pct_used 为 90% ,高度为 3 ,分支节点块数下降到 20 个,再加一个根节点块,而叶子节点数下降到 5000 个。那么从理论上说:
1) 如果通过索引获取单独 1 条记录来说:
重建之前的成本: 1 个根+ 1 个分支+ 1 个叶子+ 1 个表块= 4 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 1 个叶子+ 1 个表块= 4 个逻辑读
性能提高百分比: 0
2) 如果通过索引获取 100 条记录(占总记录数的 0.01% )来说,分两种情况:
最差的 clustering_factor (即该值等于表的数据行数):
重建之前的成本: 1 个根+ 1 个分支+ 0.0001*10000 ( 1 个叶子)+ 100 个表块= 103 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 0.0001*5000 ( 1 个叶子)+ 100 个表块= 102.5 个逻辑读
性能提高百分比: 0.5% (也就是减少了 0.5 个逻辑读)
最好 clustering_factor (即该值等于表的数据块):
重建之前的成本: 1 个根+ 1 个分支+ 0.0001*10000 ( 1 个叶子)+ 0.0001*100000 ( 10 个表块)= 13 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 0.0001*5000 ( 1 个叶子)+ 0.0001*100000 ( 10 个表块)= 12.5 个逻辑读
性能提高百分比: 3.8% (也就是减少了 0.5 个逻辑读)
3) 如果通过索引获取 10000 条记录(占总记录数的 1% )来说,分两种情况:
最差的 clustering_factor (即该值等于表的数据行数):
重建之前的成本: 1 个根+ 1 个分支+ 0.01*10000 ( 100 个叶子)+ 10000 个表块= 10102 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 0.01*5000 ( 50 个叶子)+ 10000 个表块= 10052 个逻辑读
性能提高百分比: 0.5% (也就是减少了 50 个逻辑读)
最好 clustering_factor (即该值等于表的数据块):
重建之前的成本: 1 个根+ 1 个分支+ 0.01*10000 ( 100 个叶子)+ 0.01*100000 ( 1000 个表块)= 1102 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 0.01*5000 ( 50 个叶子)+ 0.01*100000 ( 1000 个表块)= 1052 个逻辑读
性能提高百分比: 4.5% (也就是减少了 50 个逻辑读)
4) 如果通过索引获取 100000 条记录(占总记录数的 10% )来说,分两种情况:
最差的 clustering_factor (即该值等于表的数据行数):
重建之前的成本: 1 个根+ 1 个分支+ 0.1*10000 ( 1000 个叶子)+ 100000 个表块= 101002 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 0.1*5000 ( 500 个叶子)+ 100000 个表块= 100502 个逻辑读
性能提高百分比: 0.5% (也就是减少了 500 个逻辑读)
最好 clustering_factor (即该值等于表的数据块):
重建之前的成本: 1 个根+ 1 个分支+ 0.1*10000 ( 1000 个叶子)+ 0.1*100000 ( 10000 个表块)= 11002 个逻辑读
重建之后的成本: 1 个根+ 1 个分支+ 0.1*5000 ( 500 个叶子)+ 0.1*100000 ( 10000 个表块)= 10502 个逻辑读
性能提高百分比: 4.5% (也就是减少了 500 个逻辑读)
5) 对于快速全索引扫描来说,假设每次获取 8 个数据块:
重建之前的成本:( 1 个根+ 40 个分支+ 10000 个叶子) / 8 = 1256 个逻辑读
重建之后的成本:(
1
个根+
40
个分支+
5000
个叶子)
/ 8
=
631
个逻辑读
性能提高百分比:
49.8%
(也就是减少了
625
个逻辑读)
从上面有关性能提高的理论描述可以看出,对于通过索引获取的记录行数不大的情况下,索引碎片对于性能的影响非常小;当通过索引获取较大的记录行数时,索引碎片的增加可能导致对于索引逻辑读的增加,但是索引读与表读的比例保持不变;同时,我们从中可以看到, clustering_factor 对于索引读取的性能有很大的影响,并且对于索引碎片所带来的影响具有很大的作用;最后,看起来,索引碎片似乎对于快速全索引扫描具有最大的影响。
我们来看两个实际的例子,分别是 clustering_factor 为最好和最差的两个例子。测试环境为 8KB 的数据块,表空间采用 ASSM 的管理 方式。先做一个最好的 clustering_factor 的例子,创建测试表并填充 1 百万条数据。
- SQL> create table rebuild_test(id number, name varchar2(10));
- SQL> begin
- 2 for i in 1..1000000 loop
- 3 insert into rebuild_test values (i,to_char(i));
- 4 if mod(i,10000)=0 then
- 5 commit ;
- 6 end if;
- 7 end loop;
- 8 end ;
- 9 /
该表具有 1 百万条记录,分布在 2328 个数据块中。同时由于我们的数据都是按照顺序递增插入的,所以可以知道,在 id 列上创建的索引都是具有最好的 clustering_factor 值的。我们运行以下查询测试语句,分别返回 1 、 100 、 1000 、 10000 、 50000 、 100000 以及 1000000 条记录。
- select * from rebuild_test where id = 10;
- select * from rebuild_test where id between 100 and 199;
- select * from rebuild_test where id between 1000 and 1999;
- select * from rebuild_test where id between 10000 and 19999;
- select /*+ index (rebuild_test) */ * from rebuild_test where id between 50000 and 99999;
- select /*+ index (rebuild_test) */ * from rebuild_test where id between 100000 and 199999;
- select /*+ index (rebuild_test) */ * from rebuild_test where id between 1 and 1000000;
- select /*+ index_ffs(rebuild_test) */ id from rebuild_test where id between 1 and 1000000;
在运行这些测试语句前,先创建一个 pctfree 为 50% 的索引,来模拟索引碎片,分析并记录索引信息。
- SQL> create index idx_rebuild_test on rebuild_test(id) pctfree 50;
- SQL> exec dbms_stats.gather_table_stats( user , 'rebuild_test' , cascade => true );
然后运行测试语句,记录每条查询语句所需的时间;接下来以 pctfree 为 10% 重建索引,来模拟修复索引碎片,分析并记录索引信息。
- SQL> alter index idx_rebuild_test rebuild pctfree 10;
- SQL> exec dbms_stats.gather_table_stats( user , 'rebuild_test' , cascade => true );
接着再次运行这些测试语句,记录每条查询语句所需的时间。下表显示了两个索引信息的对比情况。
pctfree |
Height |
blocks |
br_blks |
lf_blks |
pct_used |
clustering_factor |
50% |
3 |
4224 |
8 |
4096 |
49% |
2326 |
10% |
3 |
2304 |
5 |
2226 |
90% |
2326 |
下表显示了不同的索引下,运行测试语句所需的时间对比情况。
记录数 |
占记录总数的百分比 |
pctused(50%) |
pctused(90 % ) |
性能提高百分比 |
1 条记录 |
0.0001% |
0.01 |
0.01 |
0.00% |
100 条记录 |
0.0100% |
0.01 |
0.01 |
0.00% |
1000 条记录 |
0.1000% |
0.01 |
0.01 |
0.00% |
10000 条记录 |
1.0000% |
0.02 |
0.02 |
0.00% |
50000 条记录 |
5.0000% |
0.06 |
0.06 |
0.00% |
100000 条记录 |
10.0000% |
1.01 |
1.00 |
0.99% |
1000000 条记录 |
100.0000% |
13.05 |
11.01 |
15.63% |
1000000 条记录 (FFS) |
100.0000% |
7.05 |
7.02 |
0.43% |
上面是对最好的 clustering_factor 所做的测试,那么对于最差的 clustering_factor 会怎么样呢?我们将 rebuild_test 中的 id 值反过来排列,也就是说,比如对于 id 为 3478 的记录,将 id 改为 8743 。这样的话,就将把原来按顺序排列的 id 值彻底打乱,从而使得 id 上的索引的 clustering_factor 变成最差的。为此,我写了一个函数用来反转 id 的值。
- create or replace function get_reverse_value(id in number) return varchar2 is
- ls_id varchar2(10);
- ls_last_item varchar2(10);
- ls_curr_item varchar2(10);
- ls_zero varchar2(10);
- li_len integer ;
- lb_stop boolean;
- begin
- ls_id := to_char(id);
- li_len := length(ls_id);
- ls_last_item := '' ;
- ls_zero := '' ;
- lb_stop := false ;
- while li_len>0 loop
- ls_curr_item := substr(ls_id,li_len,1);
- if ls_curr_item = '0' and lb_stop = false then
- ls_zero := ls_zero || ls_curr_item;
- else
- lb_stop := true ;
- ls_last_item:=ls_last_item||ls_curr_item;
- end if;
- ls_id := substr(ls_id,1,li_len-1);
- li_len := length(ls_id);
- end loop;
- return (ls_last_item||ls_zero);
- end get_reverse_value;
接下来,我们创建我们第二个测试的测试表。并按照与第一个测试案例相同的方式进行测试。注意,对于测试查询来说,要把表名(包括提示里的)改为 rebuild_test_cf 。
发表评论
-
哈希表
2013-05-03 11:03 1587转载自 ---- http://blog.java ... -
Java 链表
2013-01-18 15:27 935转载自 ---- http://359094247.iteye ... -
哈夫曼与压缩
2013-01-18 15:24 870转载自 ---- http://359094247.iteye ... -
排序算法java版(转载)
2011-08-10 14:06 853转载自 ---- http://yiyickf.iteye.c ... -
(转)B树、B-树、B+树、B*树都是什么
2011-08-03 16:55 664B 树 即二叉搜 ... -
(转)深入研究B树索引(五)
2011-08-03 16:53 8625. 重建 ... -
(转)深入研究B树索引(四)续
2011-08-03 16:52 7714.2 B 树索引的 ... -
(转)深入研究B树索引(三、四)
2011-08-03 16:51 7503. B 树索引的访问 ... -
(转)深入研究B树索引(二)
2011-08-03 16:51 8972. B 树索引的 ... -
(转)深入研究B树索引(一)
2011-08-03 16:50 1030摘要: 本文对B 树索引的结构、内部管理等方面做了一个 ...
相关推荐
深入研究B树索引 B树算法 B+树算法 经典算法 强烈推荐~
NULL 博文链接:https://aindf0128.iteye.com/blog/657524
原文转载自...本文对B树索引的结构、内部管理等方面做了一个全面的介绍。同时深入探讨了一些与B树索引有关的广为流传的说法,比如删除记录对索引的影响,定期重建索引能解决许多性能问题等。
B+树索引 B+树索引 B+树索引 B+树索引 B+树索引 B+树索引
Oracle 索引研究
当数据庞杂时,B 树索引在查找效率和空间利用率方面还存在不足。针对该问题提出一种改进的B 树结构,首先通过调整叶子节点与非叶子节点的数量关系,以降低树的深度;然后优化原插入算法,在分裂节点前进行平衡处理...
采用平衡二叉树索引关键字,可以体会数据结构用法,也可用于项目,完全开源
算法框架出自一本书,书名记不得了。对其进行了实现和调试,用100+规模的数据测试通过。内附文档。
B树索引实现歌曲管理系统,qt的界面。方便学弟学妹们软件设计。
为什么说B+树比B树更适合做文件索引
B+树索引的原理,详细的介绍了B+树在数据库方面的实现原理,全英文内容
Oracle数据库应用系统的性能优化是一项系统化的工程,涉及到数据库结构的各个方面。本文从B* 树索引入手, 分析了B* 树索引的结构及原理,阐明了如何正确合理地使用B* 树索引及其如何优化数据库系统的性能。
b+树索引所原理,包括组合索引下的最左匹配原理等。。
针对MapReduce数据块处理机制、高维数据分布特征和KNN查询需求,设计一种基于B 树的高维索引结构(iPartition),创新性提出基于主成分区分度的优化数据划分策略和邻接数据域分散存储等原则,将数据均匀划分到不同的...
有很多B和B+树的异同的比较,很多都是本人总结得到的,很辛苦
有关B*tree的简单实验,使用的环境和不适用的和环境。
B+树做数据库的索引,增加查询效率,代码下载之后可以运行
关于索引的介绍,以及b+树结构图,两种索引性能比较,索引优化建议
B树索引和自创Connect.rar 源码分享
64 深入研究索引之前,先来看看磁盘数据页的存储结构l.pdf