189 8069 5689
· 通过全表扫描的方式访问数据；
成都创新互联公司是一家专业的成都网站建设公司，我们专注网站制作、网站设计、网络营销、企业网站建设，外链，1元广告为企业客户提供一站式建站解决方案，能带给客户新的互联网理念。从网站结构的规划UI设计到用户体验提高，创新互联力求做到尽善尽美。
· 通过ROWID访问数据；
· 通过索引的方式访问数据；
· Oracle顺序读取表中所有的行，并逐条匹配WHERE限定条件。
· 采用多块读的方式进行全表扫描，可以有效提高系统的吞吐量，降低I/O次数。
· 即使创建索引，Oracle也会根据CBO的计算结果，决定是否使用索引。
注意事项：
· 只有全表扫描时才可以使用多块读。该方式下，单个数据块仅访问一次。
· 对于数据量较大的表，不建议使用全表扫描进行访问。
· 当访问表中的数据量超过数据总量的5%—10%时，通常Oracle会采用全表扫描的方式进行访问。
· 并行查询可能会导致优化器选择全表扫描的方式。1.2ROWID访问表
· Rowid是数据存放在数据库中的物理地址，能够唯一标识表中的一条数据。
· Rowid指出了一条记录所在的数据文件、块号以及行号的位置，因此通过ROWID定位单行数据是最快的方法。
注意事项：
· Rowid作为一个伪列，其数值并不存储在数据库中，当查询时才进行计算。
· Rowid除了在同一集簇中可能不唯一外，每条记录的Rowid唯一。1.3 INDEX访问表
· 通过索引查找相应数据行的Rowid，再根据Rowid查找表中实际数据的方式称为“索引查找”或者“索引扫描”。
· 一个Rowid对应一条数据行（根据Rowid查找结果，仅需要对Rowid相应数据的数据块进行一次I/O操作），因此该方式属于“单块读”。
· 对于索引，除了存储索引的数据外，还保存有该数据对应的Rowid信息。
· 索引扫描分为两步：1）扫描索引确定相应的Rowid信息。 2）根据Rowid从表中获得对应的数据。
注意事项：
· 对于选择性高的数据行，索引的使用会提升查询的性能。但对于DML操作，尤其是批量数据的操作，可能会导致性能的降低。
· 全表扫描的效率不一定比索引扫描差，关键看数据在数据块上的具体分布。
索引是关系数据库中用于存放每一条记录的一种对象，主要目的是加快数据的读取速度和完整性检查。建立索引是一项技术性要求高的工作。一般在数据库设计阶段的与数据库结构一道考虑。应用系统的性能直接与索引的合理直接有关。
(1) 单列索引
单列索引是基于单个列所建立的索引。
(2) 复合索引
复合索引是基于两列或是多列的索引，在同一张表上可以有多个索引，但是要求列的组合必须不同。
(1) 重命名索引
(2) 合并索引
（表使用一段时间后在索引中会产生碎片，此时索引效率会降低，可以选择重建索引或者合并索引,合并索引方式更好些，无需额外存储空间，代价较低）
(3) 重建索引
方式一：删除原来的索引，重新建立索引
当不需要时可以将索引删除以释放出硬盘空间。命令如下：
例如：
注：当表结构被删除时，有其相关的所有索引也随之被删除。
方式二： Alter index 索引名称 rebuild;
· 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
· 索引可以大大加快数据的检索速度，这是创建索引的最主要的原因。
· 可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
· 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
· 通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
· 索引的层次不要超过4层。
· 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
· 除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
· 当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
· 更新数据的时候，系统必须要有额外的时间来同时对索引进行更新，以维持数据和索引的一致性。
1) 不恰当的索引不但于事无补，反而会降低系统性能。因为大量的索引在进行插入、修改和删除操作时比没有索引花费更多的系统时间。
1) 应该建索引的列
· 在经常需要搜索的列上，可以加快搜索的速度；
· 在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
· 在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
· 在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
· 在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
· 在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
2) 不应该建索引的列
· 在大表上建立索引才有意义，小表无意义。
· 对于那些在查询中很少使用或者参考的列不应该创建索引。
· 对于那些只有很少数据值的列也不应该增加索引。比如性别，在查询的结果中，结果集的数据行占了表中数据行的很大比例，。增加索引，并不能明显加快检索速度。
· 对于那些定义为blob数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
· 当修改性能远远大于检索性能时，不应该创建索引。
一个表中有几百万条数据，对某个字段加了索引，但是查询时性能并没有什么提高，这主要可能是oracle的索引限制造成的。Oracle的索引有一些索引限制，在这些索引限制发生的情况下，即使已经加了索引，oracle还是会执行一次全表扫描，查询的性能不会比不加索引有所提高，反而可能由于数据库维护索引的系统开销造成性能更差。
下面的查询即使在djlx列有索引，查询语句仍然执行一次全表扫描。
把上面的语句改成如下的查询语句，这样，在采用基于规则的优化器而不是基于代价的优化器（更智能）时，将会使用索引。
特别注意：通过把不等于操作符改成OR条件，就可以使用索引，避免全表扫描。
使用IS NULL或IS NOT NULL同样会限制索引的使用。因此在建表时，把需要索引的列设成NOT NULL。如果被索引的列在某些行中存在NULL值，就不会使用这个索引（除非索引是一个位图索引）。
如果不使用基于函数的索引，那么在SQL语句的WHERE子句中对存在索引的列使用函数时，会使优化器忽略掉这些索引。 下面的查询不会使用索引（只要它不是基于函数的索引）
也是比较难于发现的性能问题之一。比如：bdcs_qlr_xz中的zjh是NVARCHAR2类型,在zjh字段上有索引。如果使用下面的语句将执行全表扫描。
因为Oracle会自动把查询语句改为
特别注意：不匹配的数据类型之间比较会让Oracle自动限制索引的使用,即便对这个查询执行Explain Plan也不能让您明白为什么做了一次“全表扫描”。
(1) 索引无效
(2) 索引有效
Normal 0 7.8 pt 0 2 false false false MicrosoftInternetExplorer4
oracle 索引什么时候重建和重建方法讨论
分类：数据库技术 字号： 大大中中小小 索引什么时候需要重建和重建的方法
一提到索引，大家都知道，但是怎样建索引，什么时候重建索引，重建索引用什么方法，可能有的就不太清楚了，我根据一些资料简单的整理一点，如果哪里不对或是不妥请大家指点，希望大家有更好经验也share出来。
索引的目的是为了加快寻找数据的速度，但是如果对表经常做改动，则索引也会相应改动，时间长了，查询速度的效率就会降低，就有可能要重建索引，那么什么时候需要重建索引和用什么方法重建索引可能是大家关心的。
一. 索引在内部进行自身的管理以确保对数据行的快速访问。但是数据表中大量的活动会导致oracle索引动态地对自身的进行重新配置，这些配置包括三个方面：
1．索引分割
当新数据行产生的索引节点要建立在现有级别上时，出现此动作。
2．索引生成
在某些位置，索引达到此级索引的最大容量的时候，就会生成更深一级的索引结构。
3．索引节点的删除
你可能了解到，删除表中的数据行后，索引中相应的节点不会从物理意义上删除，也没有从索引中删除此项目。而是从逻辑上删除此索引项目，并在索引树中留下了一个“死“节点，当索引删除了叶节点或是生成了过深的的级别层次后，就需要进行重建。
二 索引的种类：
a.B-tree（B树）索引
b.压缩B树索引
c.Bitmap（位图）索引
d.函数索引
e.Reverse Key Index（反向键索引）
f.Index Organized Table（索引组织表）
三 下面分别对各种索引进行说明
在进行介绍前先说明几个术语：
高基数：简单理解就是表中列的不同值多
低基数：建单理解就是表中的列的不同值少
以删除的叶节点数量：指得是数据行的delete操作从逻辑上删除的索引节点的数量，要记住oracle在删除数据行后，将“死“节点保留在索引中，这样做可以加快sql删除操作的速度，因此oracle删除数据行后可以不必重新平衡索引。
索引高度：索引高度是指由于数据行的插入操作而产生的索引层数，当表中添加大量数据时，oracle将生成索引的新层次以适应加入的数据行，因此， oracle索引可能有4层，但是这只会出现在索引数中产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目，而具备4层或是更多层的需要重建。
每次索引访问的读取数：是指利用索引读取一数据行时所需要的逻辑I/O操作数，逻辑读取不必是物理读取，因为索引的许多内容已经保存在数据缓冲区，然而，任何数据大于10的索引都需要重建。
1. B-tree（B树）索引
是现代关系型数据库中最常用的索引。除了存储索引数据外，还存储一个行ID，用来指出该行其余数据存储在这个被索引表中的什么地方。该索引以一种数结构格式存储这些值。
Oracle建议如果表经过排序，当返回40%一下的数据时使用索引，如果高于40%则使用全表扫描，如果没有经过排序，则当返回7%以下时，使用索引。看表是否排序，可以看dba_indexes字典中的CLUSTERING_FACTOR列，如果与表占用的数据块数相近，则经过了排序，如果与行数相近，则没有排序。那么什么时候重建呢？我们可以利用analyze index …….. compute statistics 对表进行分析。然后察看dba_indexes中的blevel。这列是说明索引从根块到叶快的级别，或是深度。如果级别大于等于4。则需要重建，如下：
Select index_name,blevel from dba_indexeswhere blevel=4.
另一个从重建中受益的指标显然是当该索引中的被删除项占总的项数的百分比。如果在20%以上时，也应当重建，如下
SQLanlyze index ------ validatestructure
SQLselect(del_lf_rows_len/lf_rows_len)*100 from index_stats where 删除并从头开始建立索引。
b. 使用alter index -------- rebuild 命令重建索引
c. 使用alter index -------- coalesce命令重建索引。
下面讨论一下这三种方法的优缺点：
1).删除并从头开始建索引：方法是最慢的，最耗时的。一般不建议。
2).Alter index ---- rebuild 快速重建索引的一种有效的办法，因为使用现有索引项来重建新索引，如果客户操作时有其他用户在对这个表操作，尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题，alter index ------- rebuild online.但是,由于新旧索引在建立时同时存在，因此，使用这种技巧则需要有额外的磁盘空间可临时使用，当索引建完后把老索引删除，如果没有成功，也不会影响原来的索引。利用这种办法可以用来将一个索引以到新的表空间。
Alter index ------ rebuild tablespace -----。
这个命令的执行步骤如下：
首先，逐一读取现有索引，以获取索引的关键字。
其次，按新的结构填写临时数据段。
最后，一旦操作成功，删除原有索引树，降临时数据段重命名为新的索引。
需要注意的是alterindex ---rebuild 命令中必须使用tablespace字句，以保证重建工作是在现有索引相同的表空间进行。
3).alter index ----- coalesce 使用带有coalesce参数时重建期间不需要额外空间，它只是在重建索引时将处于同一个索引分支内的叶块拼合起来，这最大限度的减少了与查询过程中相关的潜在的加锁问题，但是，coalesce选项不能用来讲一个索引转移到其他表空间。
2．压缩B树索引
当B树索引基于大表时，尤其是当基于数据仓库或决策支持系统中的大表时，这些索引会耗费大量的存储空间，压缩（compressed）B树索引用来最大限度的减少某些类型的B树索引使用的空间。当一个B树索引得到压缩时，被索引的猎的重复出现就被消除掉，进而减少了存储索引的总的存储空间。例如：
压缩前：smith每次出现还要存储它的相关的rowid.
姓 关联rowid
smith AAABSOAAEAAAABTAAB
smith AAABSOAAEAAAABTAAC
smith AAABSOAAEAAAABTAAD
压缩后:smith项和rowid指存储一次。
smith AAABSOAAEAAAABTAAB,AAABSOAAEAAAABTAAB, AAABSOAAEAAAABTAAB
创建方法：
SQLcreate index index_name ontable_name(column_name)
tablespace tablespace_name
compress;
另一种方法：
SQLalter index index_name rebuildcompress;
3． itmap(位图)索引。
B树索引在数据具有高基数的列工作的最好，对于低基数的列，位图索引可能是更有效的选择。位图索引创建表行的一个二进制映像，并把映像存储在索引块中，这种类型的索引的DML操作少，长度大并且含有极少不同的值得列特别有用。位图索引不应当用在频繁发生insert,update,delete操作的表上，这些dml操作在性能方面的代价很高，因为，他们会引起位图级的加锁发生，而且要求动态的重建所有可能值的位图。为图索引最适合数据仓库和决策支持系统。
4．基于函数的索引
当把一个函数运用于被索引的列上时，该列德索引都变得无效，基于函数的索引就是为了解决这个问题。
5．反向键索引
是一种特殊类型的B树索引，在索引基于含有序数的列时使非常有用的，如果一个传统的B树索引基于一个含有这种数据的列，往往会产生许多级，由于B树索引有 4级以上的深度会降低性能，因此反向键索引更适合这种类型，反向键索引通过简单的烦象被索引的列中的数据来解决问题，他首先反向每个列键值的字节，然后在反向后的新数据上进行索引，而新数据在值的范围上的分布通常比原来的有序数更均匀。
6．索引组织表
由于B树、位图、反向键索引的使用而引起的性能将会导致这样的事实，这些索引中的项目直接指向索引基表中对应数据的行ID,这是从表行没有按任何特定的顺序来物理地存储表中检索表行的一种有效方法，这种表叫做堆表，oracle大多数表中以一种堆叠方式存储行数据，因为行以一种或多或少的随机方式被分配给表内的块，之所以出现这种随机性，是因为oracle在决定把一个行存储在何处时并不考虑改行的内容，oracle只是把该行存储在它从该表的freelist 上所发现的第一个块中。
如果希望按一种指定顺序来存储一个表的数据，就不能使用堆表，为此oracle提供了索引组织表，索引组织表不是存储一个指向行数据的其余部分存储在了何处的行的ID指针，而是把行数据全部存储在索引本身内，这产生了两个性能好处：
n 表行按索引顺序来存储。
n 使用B树索引时引起的先读取索引后读取表锁使用的额外I/O操作得到消除。
例如：
sqlcreate table emp
(last_name varchar2(9) primary key,
first_name varchar2(9),
hire_date date)
organization index tablespace users
pctthreshold 25
including first name
overflow tablespace qyl
mapping table;
所有索引组织表在将要作为索引基础的那一列上都必须有一个主键约束，索引组织表不能含有唯一性约束或是被聚簇。
下面说明各个参数的含义：
organization index：说明该表是索引组织表
pctthreshold :指定整个数据块的什么百分比要保持打开，以便存储一个与主键值相关联的行数据，其中主键值必须在0到50之间（50是默认值）
including : 指定在行长度超过pctthershold中所设置的大小时按那一列 把行分解成两段
overflow tablespace ：指定在行长度超过pctthreshold中设置的大小时行数的的另一部分存储到的表空间。
Mapping table:致使在创建索引组织表的位图索引时所必需的一个关联映像表的创建。
以上是我根据一些资料对索引的一个简单阐述，大家可能有不同的见解，希望对大家有帮助，那些不妥的地方还希望大家提出来。
参考资料：ocp困惑racle9i性能调整
oracle statspack 高性能调整技术
[@more@]
analyze index t_id_ind validate structure
select (del_lf_rows_len/lf_rows_len)*100 from index_stats
20%
b. 使用alter index t_id_ind rebuild 命令重建索引
c. 使用alter index t_id_ind coalesce命令重建索引。
alter indext_id_ind rebuild online.
但是,由于新旧索引在建立时同时存在，因此，使用这种技巧则需要有额外的磁盘空间可临时使用，当索引建完后把老索引删除，如果没有成功，也不会影响原来的索引。利用这种办法可以用来将一个索引以到新的表空间。
Alter index ------ rebuild tablespace -----。
这个命令的执行步骤如下：
首先，逐一读取现有索引，以获取索引的关键字。
其次，按新的结构填写临时数据段。
最后，一旦操作成功，删除原有索引树，降临时数据段重命名为新的索引。
需要注意的是alter index ---rebuild 命令中必须使用tablespace字句，以保证重建工作是在现有索引相同的表空间进行
alter index ----- coalesce 使用带有coalesce参数时重建期间不需要额外空间，它只是在重建索引时将处于同一个索引分支内的叶块拼合起来，这最大限度的减少了与查询过程中相关的潜在的加锁问题，但是，coalesce选项不能用来讲一个索引转移到其他表空间
你说的慢一半，是在你插入了50万数据的时候，估计是查询慢了吧。因为按你说的还没到删除的时候呢。查询慢要看看你的查询的语句的执行计划，是否使用了合适的索引。如果索引错了，那么慢是正常的。可以用hint指定索引，从而保证执行计划稳定。
对于你这样的周期性维护的大表，可以做31个分区，每天一个，一个月内循环使用。不需要保留的数据可以以天为单位truncate掉一个或多个分区的数据，索引采用分区索引，truncate分区不影响索引的使用。
有一种猜测，是你的索引建的不对。
你的查询语句的查询条件是什么？是单列查询吗？如果pwd指password，至少我觉得不会有按password单列查询的语句吧。
A. oracle 提供了收集数据库统计信息的系统包，例如统计scott用户信息只需要执行:
exec dbms_stats.gather_schema_stats(
ownname = 'SCOTT',
options = 'GATHER AUTO',
estimate_percent = dbms_stats.auto_sample_size,
method_opt = 'for all columns size repeat',
degree = 15
);
dbms_stat.gather_schema_stats 的参数说请查相关资料，这里就不详述了。
B. 要定期执行用户统计信息很简单，只要在 oracle job 中调用这个过程就可以了，设置好初次调用时间和调用时间间隔即可。
以上的操作都能在plsql中操作。
------索引名不能重复，如果要重新建同名索引，必须把以前的索引删掉在建索引
-----删除索引
drop index 索引名;
-----创建索引
create index 索引名 on 表名 (表中的字段,表中的字段)
tablespace 指定的表空间
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
当索引的碎片过多时，会影响执行查询的速度，从而影响到我们的工作效率。这时候采取的最有利的措施莫过于重建索引了。本文主要介绍了Oracle数据库中检查索引碎片并重建索引的过程，接下来我们就开始介绍这一过程。 重建索引的步骤如下： 1. 确认基本信息 登入数据库，找到专门存放index 的tablespace，并且这个tablespace下所有index的owner都是tax.将index专门存放在一个独立的tablespace, 与数据表的tablespace分离，是常用的数据库设计方法。 2. 查找哪些index需要重建 通过anlyze index .... validate structure命令可以分析单个指定的index，并且将单个index 分析的结果存放到 index_stats试图下。一般判断的依据是： height 4 pct_used 50% del_lf_rows / lf_rows +0.001 0.03 g ) 3. google上下载了遍历所有index脚本 发现anlyze index .... validate structure只能填充单个index分析信息，于是google了下，从网上下了个Loop 脚本，遍历索引空间下所有的索引名字，并且可以把所有index的分析信息存放到自己建立的一个用户表中。 4. anlyze index 锁定index 发现下载的脚本不好用，应为anlyze index在分析索引前要争取独占锁，锁住index，很明显有些index正在被应用系统的使用，所以运行anlyze失败。这里吸取的教训是，尽量晚上做这种事。但是本人比较喜欢准时回家，所以在语句中添加Exception Handler，抛出anlyze index执行失败的那些index 名称，使脚本正常运行完毕。并且根据打印到前台的index name手动执行那些index分析。 5. 总结 虽然发现522个index中有160个符合上面的判断的依据。但是发现索引都不大，而那些拥有百万leaf的索引又没有符合上面的判断条件，所以结论是无需index rebuild online. 没有啥碎片。 6.什么时候可以rebuild index呢? rebuild index online，对那些有大量DML操作的大索引是有益的。可以每个月季度做一次针对较大索引的rebuild。