oracle怎么加快索引 oracle加快创建索引的办法
Oracle新手入门:如何提高索引创建速度?
默认情况下,数据库系统是不允许DML操作与创建索引的操作同时进行的。也就是说,在创建索引的过程中,是不允许其他用户对其所涉及的表进行任何的DML操作。这主要是因为对基础表进行DML操作时,会对基础表进行加锁。所以在基础表上的DDL事务没有递交之前,即没有对基础表进行解锁之前,是无法对这基础表创建索引的。反之亦然。显然此时数据库没有采用这个ONLIE选项,继之DML操作与创建索引操作同时进行,主要是从创建索引的效率出发的。防止因为两个作业相互冲突,从而延长某个作业的运行时间。 但是有时会我们必须允许他们进行同时操作。如用户可能一刻都不能够离开数据库系统,需要时时刻刻对数据库基础表进行DML操作。而此时由于某些原因,数据库管理员又需要重新建立索引时,那么不得不在创建索引的语句中加入这个ONLINE选项。让他们同时运行。此时虽然可能会延长索引创建作业的时间,但是可以保障用户DML操作能够正常进行。有时候牺牲这个代价是值得的。用户是不能够等的,而我们数据库管理员则可以勉强的等一会儿。 当然,如果用户对于这个DML操作及时性没有这么高。如数据库管理员在晚上员工没有使用数据库时创建索引时,则可以不带这个选项。在限制用户对基础表进行DML操作的同时,提高数据库创建索引的效率。 可选项五:PARALLEL,多服务进程创建索引 默认情况下,Oracle数据库系统不采用这个选项。这并不是说这个选项不可用,而是因为大多数情况下企业部署Oracle数据库时所采用的数据库服务器往往只有单个CPU。此时数据库系统是用一个服务进程来创建索引的。 如果企业的服务器有多个CPU的话,则可以在创建索引时采用这个选项。因为只要采用了这个选项,则数据库就会使用多个服务进程来并行的创建索引,以提高索引创建的速度。为此,在同等条件下,多服务并行创建进索引并单服务创建索引速度要快的多。所以如果服务器中有多个CPU,而且需要创建的索引比较多或者基础表中记录比较多的话,则采用这个选项能够大幅度的提高索引的创建效率。 故笔者建议,如果采用多CPU的服务器时,最好在创建索引时使用这个选项。不能够浪费了服务器的CPU呀。不然的话,多CPU服务器的优势就体现不出来了。为此采用这个选项,也是物尽其用。希望本文讲到的内容对大家能有所帮助。
创新互联建站是专业的拱墅网站建设公司,拱墅接单;提供成都网站建设、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行拱墅网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
Oracle数据访问和索引的使用
· 通过全表扫描的方式访问数据;
· 通过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) 索引有效
oracle 如何使用索引,更快
索引不是一句两句能讲清楚的
select * from test1 t where a in (select a from test2);
test1 大 ,test2 小,用in快
本文名称:oracle怎么加快索引 oracle加快创建索引的办法
当前网址:http://azwzsj.com/article/hghgdh.html