十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
· 通过全表扫描的方式访问数据;
创新互联专注于复兴企业网站建设,响应式网站设计,商城网站制作。复兴网站建设公司,为复兴等地区提供建站服务。全流程按需策划设计,专业设计,全程项目跟踪,创新互联专业和态度为您提供的服务
· 通过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) 索引有效
对三个字段建立索引:
create index Stuname on student(name);
create index Stusex on student(sex);
create index Stugrade on student(grade);
注意的问题,考虑是不是要建立唯一索引(unique),如果有学号的话,可以考虑建立唯一索引引。
再就是对经常查询,但又相对稳定的可以建立聚簇索引,提高查询效率
创建索引语法:
CREATE [UNIQUE] | [BITMAP] INDEX index_name
--unique表示唯一索引
ON table_name([column1 [ASC|DESC],column2
--bitmap,创建位图索引
[ASC|DESC],…] | [express])[TABLESPACE tablespace_name][PCTFREE n1]
--指定索引在数据块中空闲空间
[STORAGE (INITIAL n2)][NOLOGGING]
--表示创建和重建索引时允许对表做DML操作,默认情况下不应该使用
[NOLINE][NOSORT];
--表示创建索引时不进行排序,默认不适用,如果数据已经是按照该索引顺序排列的可以使用
扩展资料:
1、如果有两个或者以上的索引,其中有一个唯一性索引,而其他是非唯一,这种情况下oracle将使用唯一性索引而完全忽略非唯一性索引
2、至少要包含组合索引的第一列(即如果索引建立在多个列上,只有它的第一个列被where子句引用时,优化器才会使用该索引)
3、小表不要简历索引
4、对于基数大的列适合建立B树索引,对于基数小的列适合简历位图索引
5、列中有很多空值,但经常查询该列上非空记录时应该建立索引
6、经常进行连接查询的列应该创建索引
7、使用create index时要将最常查询的列放在最前面
8、LONG(可变长字符串数据,最长2G)和LONG RAW(可变长二进制数据,最长2G)列不能创建索引
9、限制表中索引的数量(创建索引耗费时间,并且随数据量的增大而增大;索引会占用物理空间;当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,降低了数据的维护速度)
1、速度因素 PARALLEL选项:当创建索引时,Oracle首先会进行全表扫描来收集符号键和ROWID对,而PARALLEL选项允许多处理器并行扫描表,这样就会加速索引的创建过程。一般推荐的PARALLEL值为CPU数减1。 NOLOGGING选项:NOLOGGING选项因为不写日志,所以大大提高了性能,比不使用NOLOGGING选项大约会节省70%的时间。使用NOLOGGING创建索引的唯一风险就是如果数据库需要做前滚恢复,你将不得不重建索引。 2、空间和结构因素 COMPRESS选项:COMPRESS选项用于在创建非唯一性索引时压缩重复值。对于连接索引(即索引包含多列)来说,COMPRESS选项会使索引的大小减少一半以上。COMPRESS选项也可以设置连接索引的前置长度。 使用大BLOCKSIZE的表空间:将索引建立在大BLOCKSIZE的表空间上,将大大降低索引树的层次。 在$ORACLE_HOME/network/admin/中创建protocol.ora文件﹐其內容如下﹕ tcp.validnode_checking=yes #下面两行取其一:
你说的慢一半,是在你插入了50万数据的时候,估计是查询慢了吧。因为按你说的还没到删除的时候呢。查询慢要看看你的查询的语句的执行计划,是否使用了合适的索引。如果索引错了,那么慢是正常的。可以用hint指定索引,从而保证执行计划稳定。
对于你这样的周期性维护的大表,可以做31个分区,每天一个,一个月内循环使用。不需要保留的数据可以以天为单位truncate掉一个或多个分区的数据,索引采用分区索引,truncate分区不影响索引的使用。
有一种猜测,是你的索引建的不对。
你的查询语句的查询条件是什么?是单列查询吗?如果pwd指password,至少我觉得不会有按password单列查询的语句吧。
不使用Oracle text功能,也有很多方法可以在Oracle数据库中搜索文本.可以使用标准的INSTR函数和LIKE操作符实现。
SELECT *FROM mytext WHERE INSTR (thetext, 'Oracle') 0;
SELECT * FROM mytext WHERE thetext LIKE '%Oracle%';
有很多时候,使用instr和like是很理想的, 特别是搜索仅跨越很小的表的时候.然而通过这些文本定位的方法将导致全表扫描,对资源来说消耗比较昂贵,而且实现的搜索功能也非常有限,因此对海量的文本数据进行搜索时,建议使用oralce提供的全文检索功能 建立全文检索的步骤步骤一 检查和设置数据库角色首先检查数据库中是否有CTXSYS用户和CTXAPP脚色。如果没有这个用户和角色,意味着你的数据库创建时未安装intermedia功能。你必须修改数据库以安装这项功能。 默认安装情况下,ctxsys用户是被锁定的,因此要先启用ctxsys的用户。 步骤二 赋权 在ctxsys用户下把ctx_ddl的执行权限赋于要使用全文索引的用户,例:
grant execute on ctx_ddl to pomoho;
步骤三 设置词法分析器(lexer)
Oracle实现全文检索,其机制其实很简单。即通过Oracle专利的词法分析器(lexer),将文章中所有的表意单元(Oracle 称为 term)找出来,记录在一组 以dr$开头的表中,同时记下该term出现的位置、次数、hash 值等信息。检索时,Oracle 从这组表中查找相应的term,并计算其出现频率,根据某个算法来计算每个文档的得分(score),即所谓的‘匹配率’。而lexer则是该机制的核心,它决定了全文检索的效率。Oracle 针对不同的语言提供了不同的 lexer, 而我们通常能用到其中的三个:
n basic_lexer: 针对英语。它能根据空格和标点来将英语单词从句子中分离,还能自动将一些出现频率过高已经失去检索意义的单词作为‘垃圾’处理,如if , is 等,具有较高的处理效率。但该lexer应用于汉语则有很多问题,由于它只认空格和标点,而汉语的一句话中通常不会有空格,因此,它会把整句话作为一个 term,事实上失去检索能力。以‘中国人民站起来了’这句话为例,basic_lexer 分析的结果只有一个term ,就是‘中国人民站起来了’。此时若检索‘中国’,将检索不到内容。
n chinese_vgram_lexer: 专门的汉语分析器,支持所有汉字字符集(ZHS16CGB231280 ZHS16GBK ZHT32EUC ZHT16BIG5 ZHT32TRIS ZHT16MSWIN950 ZHT16HKSCS UTF8 )。该分析器按字为单元来分析汉语句子。‘中国人民站起来了’这句话,会被它分析成如下几个term: ‘中’,‘中国’,‘国人’,‘人民’,‘民站’,‘站起’,起来’,‘来了’,‘了’。可以看出,这种分析方法,实现算法很简单,并且能实现‘一网打尽’,但效率则是差强人意。
n chinese_lexer: 这是一个新的汉语分析器,只支持utf8字符集。上面已经看到,chinese vgram lexer这个分析器由于不认识常用的汉语词汇,因此分析的单元非常机械,像上面的‘民站’,‘站起’在汉语中根本不会单独出现,因此这种term是没有意义的,反而影响效率。chinese_lexer的最大改进就是该分析器 能认识大部分常用汉语词汇,因此能更有效率地分析句子,像以上两个愚蠢的单元将不会再出现,极大 提高了效率。但是它只支持 utf8, 如果你的数据库是zhs16gbk字符集,则只能使用笨笨的那个Chinese vgram lexer.
如果不做任何设置,Oracle 缺省使用basic_lexer这个分析器。要指定使用哪一个lexer, 可以这样操作:
第一. 当前用户下下建立一个preference(例:在pomoho用户下执行以下语句)
exec ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer');
第二. 在建立全文索引索引时,指明所用的lexer:
CREATE INDEX myindex ON mytable(mycolumn) indextype is ctxsys.context
parameters('lexer my_lexer');
这样建立的全文检索索引,就会使用chinese_vgram_lexer作为分析器。
步骤四 建立索引
通过以下语法建立全文索引
CREATE INDEX [schema.]index on [schema.]table(column) INDEXTYPE IS ctxsys.context [ONLINE]
LOCAL [(PARTITION [partition] [PARAMETERS('paramstring')]
[, PARTITION [partition] [PARAMETERS('paramstring')]])]
[PARAMETERS(paramstring)] [PARALLEL n] [UNUSABLE];
例:
CREATE INDEX ctx_idx_menuname ON pubmenu(menuname)
indextype is ctxsys.context parameters('lexer my_lexer')
步骤五 使用索引
使用全文索引很简单,可以通过:
select * from pubmenu where contains(menuname,'上传图片')0
全文索引的种类
建立的Oracle Text索引被称为域索引(domain index),包括4种索引类型:
l CONTEXT
2 CTXCAT
3 CTXRULE
4 CTXXPATH
依据你的应用程序和文本数据类型你可以任意选择一种。
对多字段建立全文索引
很多时候需要从多个文本字段中查询满足条件的记录,这时就需要建立针对多个字段的全文索引,例如需要从pmhsubjects(专题表)的 subjectname(专题名称)和briefintro(简介)上进行全文检索,则需要按以下步骤进行操作:
Ø 建议多字段索引的preference
以ctxsys登录,并执行:
EXEC ctx_ddl.create_preference(' ctx_idx_subject_pref',
'MULTI_COLUMN_DATASTORE');
Ø 建立preference对应的字段值(以ctxsys登录)
EXEC ctx_ddl.set_attribute(' ctx_idx_subject_pref ','columns','subjectname,briefintro');
Ø 建立全文索引
CREATE INDEX ctx_idx_subject ON pmhsubjects(subjectname)
INDEXTYPE ISctxsys.CONTEXT PARAMETERS('DATASTORE ctxsys.ctx_idx_subject_pref lexer my_lexer')
Ø 使用索引
select * from pmhsubjects where contains(subjectname,'李宇春')0
全文索引的维护
对于CTXSYS.CONTEXT索引,当应用程序对基表进行DML操作后,对基表的索引维护是必须的。索引维护包括索引同步和索引优化。
在索引建好后,我们可以在该用户下查到Oracle自动产生了以下几个表:(假设索引名为myindex):
DR$myindex$I、DR$myindex$K、DR$myindex$R、DR$myindex$N其中以I表最重要,可以查询一下该表,看看有什么内容:
SELECT token_text, token_count FROM dr$i_rsk1$I WHERE ROWNUM = 20;
这里就不列出查询接过了。可以看到,该表中保存的其实就是Oracle 分析你的文档后,生成的term记录在这里,包括term出现的位置、次数、hash值等。当文档的内容改变后,可以想见这个I表的内容也应该相应改变,才能保证Oracle在做全文检索时正确检索到内容(因为所谓全文检索,其实核心就是查询这个表)。这就用到sync(同步) 和 optimize(优化)了。
同步(sync): 将新的term 保存到I表;
优化(optimize): 清除I表的垃圾,主要是将已经被删除的term从I表删除。
当基表中的被索引文档发生insert、update、delete操作的时候,基表的改变并不能马上影响到索引上直到同步索引。可以查询视图 CTX_USER_PENDING查看相应的改动。例如:
SELECT pnd_index_name, pnd_rowid,
TO_CHAR (pnd_timestamp, 'dd-mon-yyyy hh24:mi:ss') timestamp
FROM ctx_user_pending;
该语句的输出类似如下:
PND_INDEX_NAME PND_ROWID TIMESTAMP
------------------------------ ------------------ --------------------
MYINDEX AAADXnAABAAAS3SAAC 06-oct-1999 15:56:50
同步和优化方法: 可以使用Oracle提供的ctx_ddl包同步和优化索引
一. 对于CTXCAT类型的索引来说, 当对基表进行DML操作的时候,Oracle自动维护索引。对文档的改变马上反映到索引中。CTXCAT是事务形的索引。
索引的同步
在对基表插入,修改,删除之后同步索引。推荐使用sync同步索引。语法:
ctx_ddl.sync_index(
idx_name IN VARCHAR2 DEFAULT NULL
memory IN VARCHAR2 DEFAULT NULL,
part_name IN VARCHAR2 DEFAULT NULL
parallel_degree IN NUMBER DEFAULT 1);
idx_name 索引名称
memory 指定同步索引需要的内存。默认是系统参数DEFAULT_INDEX_MEMORY 。
指定一个大的内存时候可以加快索引效率和查询速度,且索引有较少的碎片
part_name 同步哪个分区索引。
parallel_degree 并行同步索引。设置并行度。
例如:
同步索引myindex:Exec ctx_ddl.sync_index ('myindex');
实施建议:建议通过oracle的job对索引进行同步
索引的优化
经常的索引同步将会导致你的CONTEXT索引产生碎片。索引碎片严重的影响了查询的反应速度。你可以定期优化索引来减少碎片,减少索引大小,提高查询效率。
当文本从表中删除的时候,Oracle Text标记删除的文档,但是并不马上修改索引。因此,就的文档信息占据了不必要的空间,导致了查询额外的开销。你必须以FULL模式优化索引,从索引中删除无效的旧的信息。这个过程叫做垃圾处理。当你经常的对表文本数据进行更新,删除操作的时候,垃圾处理是很必要的。
exec ctx_ddl.optimize_index ('myidx', 'full');
实施建议:每天在系统空闲的时候对全文索引进行相应的优化,以提高检索的效率
P.S.定时优化索引
3.定时优化同步域索引
创建定时任务,定期优化和同步域索引
SQL create or replace procedure hsp_sync_index as
2 begin
3 ctx_ddl.sync_index('id_cont_msg');
4 end;
5 /
Procedure created.
Elapsed: 00:00:00.08
SQL VARIABLE jobno number;
SQL BEGIN
2 DBMS_JOB.SUBMIT(:jobno,'hsp_sync_index();',
3 SYSDATE, 'SYSDATE + (1/24/4)');
4 commit;
5 END;
6 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.27
SQL create or replace procedure hsp_optimize_index as
2 begin
3 ctx_ddl.optimize_index('id_cont_msg','FULL');
4 end;
5 /
SQL VARIABLE jobno number;
SQL BEGIN
2 DBMS_JOB.SUBMIT(:jobno,'hsp_optimize_index();',
3 SYSDATE, 'SYSDATE + 1');
4 commit;
5 END;
6 /
Procedure created.
Elapsed: 00:00:00.03
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.02
SQL