精华内容
下载资源
问答
  • 背景: 为了提高数据库效率,建索引是家常便饭;那么...

    背景:
    为了提高数据库效率,建索引是家常便饭;那么当查询条件为2个及以上时,我们是创建多个单列索引还是创建一个联合索引好呢?他们之间的区别是什么?哪个效率高呢?我在这里详细测试分析下。


    一、联合索引测试

    注:Mysql版本为 5.7.20

    创建测试表(表记录数为63188):

    CREATE TABLE `t_mobilesms_11` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT,
      `userId` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT '用户id,创建任务时的userid',
      `mobile` varchar(24) NOT NULL DEFAULT '' COMMENT '手机号码',
      `billMonth` varchar(32) DEFAULT NULL COMMENT '账单月',
      `time` varchar(32) DEFAULT NULL COMMENT '收/发短信时间',
      `peerNumber` varchar(64) NOT NULL COMMENT '对方号码',
      `location` varchar(64) DEFAULT NULL COMMENT '通信地(自己的)',
      `sendType` varchar(16) DEFAULT NULL COMMENT 'SEND-发送; RECEIVE-收取',
      `msgType` varchar(8) DEFAULT NULL COMMENT 'SMS-短信; MSS-彩信',
      `serviceName` varchar(256) DEFAULT NULL COMMENT '业务名称. e.g. 点对点(网内)',
      `fee` int(11) DEFAULT NULL COMMENT '通信费(单位分)',
      `createTime` datetime DEFAULT NULL COMMENT '创建时间',
      `lastModifyTime` datetime DEFAULT NULL COMMENT '最后修改时间',
      PRIMARY KEY (`id`),
      KEY `联合索引` (`userId`,`mobile`,`billMonth`)
    ) ENGINE=InnoDB AUTO_INCREMENT=71185 DEFAULT CHARSET=utf8 COMMENT='手机短信详情'
    
       
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17

    我们为userId, mobile, billMonth三个字段添加上联合索引!

    我们选择 explain 查看执行计划来观察索引利用情况:


    1.查询条件为 userid

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE userid='2222'
    
       
    • 1

    这里写图片描述

    可以通过key看到,联合索引有效


    2.查询条件为 mobile

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE mobile='13281899972'
    
       
    • 1

    这里写图片描述
    可以看到联合索引无效


    3.查询条件为 billMonth

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE billMonth='2018-04'
    
       
    • 1

    这里写图片描述
    联合索引无效


    4.查询条件为 userid and mobile

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE userid='2222' AND mobile='13281899972'
    
       
    • 1

    这里写图片描述
    联合索引有效


    5.查询条件为 mobile and userid

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE  mobile='13281899972' AND userid='2222' 
    
       
    • 1

    这里写图片描述
    在4的基础上调换了查询条件的顺序,发现联合索引依旧有效


    6.查询条件为 userid or mobile

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE userid='2222' OR mobile='13281899972'
    
       
    • 1

    这里写图片描述
    and 换成 or,发现联合所索引无效


    7.查询条件为 userid and billMonth

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE userid='2222' AND billMonth='2018-04'
    
       
    • 1

    这里写图片描述
    这两个条件分别位于联合索引位置的第一和第三,测试联合索引依旧有效


    8.查询条件为 mobile and billMonth

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE mobile='13281899972' AND billMonth='2018-04'
    
       
    • 1

    这里写图片描述
    这两个条件分别位于联合索引位置的第二和第三,发现联合索引无效


    9.查询条件为 userid and mobile and billMonth

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE  userid='2222' AND mobile='13281899972' AND billMonth='2018-04'
    
       
    • 1

    这里写图片描述
    所有条件一起查询,联合索引有效!(当然,这才是最正统的用法啊!)


    二、单列索引测试

    创建三个单列索引:
    这里写图片描述

    1.查询条件为 userid and mobile and billMonth

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE  userid='2222' AND mobile='13281899972' AND billMonth='2018-04'
    
       
    • 1

    这里写图片描述
    我们发现三个单列索引只有 userid 有效(位置为查询条件第一个),其他两个都没有用上。

    那么为什么没有用上呢?按照我们的理解,三个字段都加索引了,无论怎么排列组合查询,应该都能利用到这三个索引才对!

    其实这里其实涉及到了mysql优化器的优化策略!当多条件联合查询时,优化器会评估用哪个条件的索引效率最高!它会选择最佳的索引去使用,也就是说,此处userid 、mobile 、billMonth这三个索引列都能用,只不过优化器判断只需要使用userid这一个索引就能完成本次查询,故最终explain展示的key为userid。

    当然,如果优化器判断本次查询非要全使用三个索引才能效率最高,那么explain的key就会是userid 、mobile 、billMonth,都会生效!


    2.查询条件为 mobile and billMonth

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE mobile='13281899972' AND billMonth='2018-04'
    
       
    • 1

    这里写图片描述
    我们发现此处两个查询条件只有 mobile 生效(位置也为查询条件第一个)


    3.查询条件为 userid or mobile

    EXPLAIN SELECT * FROM `t_mobilesms_11` WHERE  userid='2222' OR mobile='13281899972' 
    
       
    • 1

    这里写图片描述
    这次把 and 换成 or,发现两个查询条件都用上索引了!

    我们在网上可能常常看到有人说or会导致索引失效,其实这并不准确。而且我们首先需要判断用的是哪个数据库哪个版本,什么引擎?

    比如我用的是mysql5.7版本,innodb引擎,在这个环境下我们再去讨论索引的具体问题。

    关于or查询的真相是:
    所谓的索引失效指的是:假如or连接的俩个查询条件字段中有一个没有索引的话,引擎会放弃索引而产生全表扫描。我们从or的基本含义出发应该能理解并认可这种说法,没啥问题。

    此刻需要注意type类型为index_merge
    我查资料说mysql 5.0 版本之前 使用or只会用到一个索引(即使如上我给userid和mobile都建立的单列索引),但自从5.0版本开始引入了index_merge索引合并优化!也就是说,我们现在可以利用上多个索引去优化or查询了。

    index_merge作用:
    1、索引合并是把几个索引的范围扫描合并成一个索引。
    2、索引合并的时候,会对索引进行并集,交集或者先交集再并集操作,以便合并成一个索引。
    3、这些需要合并的索引只能是一个表的。不能对多表进行索引合并。

    index_merge应用场景:

    1.对OR语句求并集,如查询SELECT * FROM TB1 WHERE c1="xxx" OR c2=""xxx"时,如果c1和c2列上分别有索引,可以按照c1和c2条件进行查询,再将查询结果合并(union)操作,得到最终结果

    2.对AND语句求交集,如查询SELECT * FROM TB1 WHERE c1="xxx" AND c2=""xxx"时,如果c1和c2列上分别有索引,可以按照c1和c2条件进行查询,再将查询结果取交集(intersect)操作,得到最终结果

    3.对AND和OR组合语句求结果


    三、结论

    通俗理解:
    利用索引中的附加列,您可以缩小搜索的范围,但使用一个具有两列的索引 不同于使用两个单独的索引。复合索引的结构与电话簿类似,人名由姓和名构成,电话簿首先按姓氏对进行排序,然后按名字对有相同姓氏的人进行排序。如果您知道姓,电话簿将非常有用;如果您知道姓和名,电话簿则更为有用,但如果您只知道名不姓,电话簿将没有用处

    所以说创建复合索引时,应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时,复合索引非常有用仅对后面的任意列执行搜索时,复合索引则没有用处。


    重点:

    多个单列索引多条件查询时优化器会选择最优索引策略可能只用一个索引,也可能将多个索引全用上! 但多个单列索引底层会建立多个B+索引树,比较占用空间,也会浪费一定搜索效率,故如果只有多条件联合查询时最好建联合索引!


    最左前缀原则:

    顾名思义是最左优先,以最左边的为起点任何连续的索引都能匹配上,
    注:如果第一个字段是范围查询需要单独建一个索引
    注:在创建联合索引时,要根据业务需求,where子句中使用最频繁的一列放在最左边。这样的话扩展性较好,比如 userid 经常需要作为查询条件,而 mobile 不常常用,则需要把 userid 放在联合索引的第一位置,即最左边


    同时存在联合索引和单列索引(字段有重复的),这个时候查询mysql会怎么用索引呢?

    这个涉及到mysql本身的查询优化器策略了,当一个表有多条索引可走时, Mysql 根据查询语句的成本来选择走哪条索引;


    有人说where查询是按照从左到右的顺序,所以筛选力度大的条件尽量放前面。网上百度过,很多都是这种说法,但是据我研究,mysql执行优化器会对其进行优化当不考虑索引时,where条件顺序对效率没有影响真正有影响的是是否用到了索引


    联合索引本质:

    当创建**(a,b,c)联合索引时,相当于创建了(a)单列索引**,(a,b)联合索引以及**(a,b,c)联合索引**
    想要索引生效的话,只能使用 a和a,b和a,b,c三种组合;当然,我们上面测试过,a,c组合也可以,但实际上只用到了a的索引,c并没有用到!
    注:这个可以结合上边的 通俗理解 来思考!


    其他知识点:

    1、需要加索引的字段,要在where条件中
    2、数据量少的字段不需要加索引;因为建索引有一定开销,如果数据量小则没必要建索引(速度反而慢)
    3、避免在where子句中使用or来连接条件,因为如果俩个字段中有一个没有索引的话,引擎会放弃索引而产生全表扫描
    4、联合索引比对每个列分别建索引更有优势,因为索引建立得越多就越占磁盘空间,在更新数据的时候速度会更慢。另外建立多列索引时,顺序也是需要注意的,应该将严格的索引放在前面,这样筛选的力度会更大,效率更高


    最后的说明:

    网上关于索引优化等文章太多了,针对各个数据库各个版本各种引擎都可能存在不一样的说法

    我们的SQL引擎自带的优化也越来越强大,说不定你的某个SQL优化认知,其SQL引擎在某次升级中早就自优化了。

    所以要么跟进官方文档,要么关注数据库大牛的最新文章,要么在现有数据库环境下自己去亲手测试!

    数据库领域的水很深。。大家加油。。共勉 ~

                                    </div><div data-report-view="{&quot;mod&quot;:&quot;1585297308_001&quot;,&quot;dest&quot;:&quot;https://blog.csdn.net/Abysscarry/article/details/80792876&quot;,&quot;extend1&quot;:&quot;pc&quot;,&quot;ab&quot;:&quot;new&quot;}"><div></div></div>
                <link href="https://csdnimg.cn/release/phoenix/mdeditor/markdown_views-60ecaf1f42.css" rel="stylesheet">
                                    <div data-report-view="{&quot;mod&quot;:&quot;popu_387&quot;,&quot;dest&quot;:&quot;https://blog.csdn.net/Abysscarry/article/details/80792876&quot;,&quot;extend1&quot;:&quot;pc&quot;,&quot;ab&quot;:&quot;new&quot;}"></div>
                        
            <div class="person-messagebox">
                <div class="left-message"><a href="https://blog.csdn.net/Abysscarry">
                    <img src="https://profile.csdnimg.cn/7/E/C/3_abysscarry" class="avatar_pic" username="Abysscarry">
                </a></div>
                <div class="middle-message">
                                        <div class="title"><span class="tit "><a href="https://blog.csdn.net/Abysscarry" data-report-click="{&quot;mod&quot;:&quot;popu_379&quot;,&quot;ab&quot;:&quot;new&quot;}" target="_blank">深寒丶</a></span>
                        <!-- 等级,level -->
                                                <img class="identity-icon" src="https://csdnimg.cn/identity/blog5.png">                                            </div>
                    <div class="text"><span>原创文章 73</span><span>获赞 408</span><span>访问量 47万+</span></div>
                </div>
                                <div class="right-message">
                                            <a class="btn btn-sm  bt-button personal-watch" data-report-click="{&quot;mod&quot;:&quot;popu_379&quot;,&quot;ab&quot;:&quot;new&quot;}">关注</a>
                                                                <a href="https://im.csdn.net/im/main.html?userName=Abysscarry" target="_blank" class="btn btn-sm bt-button personal-letter">私信
                        </a>
                                    </div>
                            </div>
                        
        </div>
    
    展开全文
  • Oracle增加索引

    千次阅读 2020-10-05 15:03:24
    Oracle表加索引–加快数据查询的利器 什么是索引 索引是对表中一列或列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息。 通俗一点地讲,索引对数据库中的表而言就相当于一本书的目录。 索引的...

    Oracle表加索引–加快数据查询的利器

    什么是索引

    索引是对表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息。
    通俗一点地讲,索引对数据库中的表而言就相当于一本书的目录。
    

    索引的类型

    1. 普通索引,仅加速查询
    2. 全文索引,用来对大表的文本域(char,varchar,text)进行索引。对文本的内容进行分词,进行搜索
     3. 唯一索引,加速查询 + 列值唯一(可以有null)
    4. 主键索引,加速查询 + 列值唯一(不可以有null)+ 表中只有一个
    5. 组合索引,多列值组成一个索引,专门用于组合搜索,其效率大于索引合并
    

    使用索引时的注意事项

    1. 索引不会包含有NULL值的列
    只要列中包含有NULL值都将不会被包含在索引中,复合索引中只要有一列含有NULL值,那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
    2. 使用短索引
    对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个CHAR(255)的列,如果在前10个或20个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
    3. 索引列排序
    查询只使用一个索引,因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序,如果需要最好给这些列创建复合索引。
    4. like语句操作
    一般情况下不鼓励使用like操作,如果非使用不可,如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
    

    如何查看和添加索引(PLSQL)

    1. 查看索引
     打开PLSQL,找到需要查询的表,右键编辑,即可看到已添加的索引
    2. 添加索引
    

    在这里插入图片描述

    展开全文
  • oracle 全文检索 oracle全文索引 列字段检索,匹配列字段搜索功能。
  • 在网上看到oracle全文索引都是对一张表一个字段进行全文检索,我想对多个多个字段按照关键字的匹配度排序,sql语句如下 select score(1) ,score(2), CDA.AREANAME,CDS.STREETNAME from C_DICT_STREET cds

    http://blog.csdn.net/linfssay/article/details/7679353

    在网上看到oracle全文索引都是对一张表一个字段进行全文检索,我想对多个表多个字段按照关键字的匹配度排序,sql语句如下

    select score(1)  ,score(2), CDA.AREANAME,CDS.STREETNAME from  C_DICT_STREET cds  left join C_DICT_ADMINAREA cda on CDA.C_DICT_ADMINAREA_ID = CDS.C_DICT_ADMINAREA_ID
     where CONTAINS (CDA.AREANAME, p_split_chinese('苏州沧浪胥江北区'),2) > 0   or
     CONTAINS (CDS.STREETNAME, p_split_chinese('苏州沧浪胥江北区'),1) > 0
    order by score(1) desc ,score(2) desc;

    这里的score是oracle全文检索对关键字的匹配程度所计算的数,contains里的最后一个参数“1”和“2”就是对这个数的一个标识。

    展开全文
  • oracle 索引修复 Oracle索引重建

    千次阅读 2018-08-15 21:34:26
    不过在修复前,我们需要确认这坏块确实来自于某索引。 因此,这里我们会介绍一些块定位方法: 1. 如何在ORA-1578/RMAN/DBVERIFY的日志记录中确认讹误受损对象 首先需要确认绝对文件号(Absolute File Number: ...

    当数据库出现坏块而坏块所涉及对象为索引时,我们一般进行修复索引的方法是重建索引。
    相对其它坏块,索引坏块修复起来最容易的。不过在修复前,我们需要确认这个坏块确实来自于某索引。

    因此,这里我们会介绍一些块定位方法:

    1. 如何在ORA-1578/RMAN/DBVERIFY的日志记录中确认讹误受损对象

    首先需要确认绝对文件号(Absolute File Number: AFN)和块号(Block Number: BL)
     
    绝对文件号(AFN)和相对文件号(RFN)经常相同,但也有时候不同。特别当:

    • 数据库是从Oracle7迁移而来
    • 或是使用了可传输表空间(Transportable/Plugged Tablespace)时
    • 或是配置的12c多租户
    • 或使用的bigfile表空间

    提示的编号总是相对文件号(RFN)。

    因此获取正确的AFN和RFN并分清含义可以节约你判断问题和定位的时间。


    从ORA-1578报错中找到AFN

    这里AFN是由ORA-1110报错提供的,并紧跟在ORA-1578之后。在下面例子中AFN为5,BL为34。

    SQL> select * from scott.dept_view;
    select * from scott.dept_view
    *
    ERROR at line 1:
    ORA-01578: ORACLE data block corrupted (file # 11, block # 34)
    ORA-01110: data file 5: '/home/oracle/oradata/users.dbf'

    从DBVERIFY输出中找到AFN
    在dbverify中坏块的定位描述会有些不同。DBVERIFY一般提供受到影响的RDBA地址。其中可以提取RFN并用于从dba_data_files表中查询到AFN。

    • 看下面例子(RFN=11 BL=34):
    Page 34 is marked corrupt
    Corrupt block relative dba: 0x02c00022 (file 11, block 34)
    Bad check value found during dbv:
    Data in bad block:
       type: 6 format: 2 rdba: 0x02c00022
       last change scn: 0x0771.4eebe71c seq: 0x2 flg: 0x04
       spare1: 0x0 spare2: 0x0 spare3: 0x0
       consistency value in tail: 0xe71c0602
       check value in block header: 0xd3ce
       computed block checksum: 0x2

    Dbverify会在输出中显示相对数据块地址(rdba/dba)。上例从“Corrupt block relative dba: 0x02c00022 (file 11, block 34)”中可知rdba HEX值为0x02c00022。
    这个实际上就提供了RFN和BL。当然这里之后也直接告诉你了“(file 11, block 34)”。
    我们就可以从dba_data_files表中查到AFN。

    • 再看另一个例子(RFN=11 BL=35):
    Dbv output:
    
    DBV-200: Block, dba 46137379, already marked corrupted"

    需要使用查询来先获取RFN和块号:

    select dbms_utility.data_block_address_file(&&rdba) RFN,
           dbms_utility.data_block_address_block(&&rdba) BL
    from dual;

    可知:

    SQL> select dbms_utility.data_block_address_file(&&rdba) RFN,
       2 dbms_utility.data_block_address_block(&&rdba) BL
       3 from dual;
    Enter value for rdba: 46137379
    
    
    RFN        BL
    ---------- ----------
    11         35

    通过RFN从dba_data_files获知AFN:

    select file_id AFN, relative_fno, tablespace_name
    from dba_data_files
    where relative_fno=&RFN;

    可知:

    SQL> select file_id AFN, relative_fno, tablespace_name
       2 from dba_data_files
       3 where relative_fno=&RFN;
    Enter value for rfn: 11
    
    AFN        RELATIVE_FNO TABLESPACE_NAME
    ---------- ------------ ------------------------------
    5          11           USERS

    AFN是5。

    从RMAN中获取AFN

    在v$database_block_corruption中我们可以看到RMAN报告的讹误块信息。

    FILE#列给出了AFN. BLOCK#列则是BL.


    定位讹误对象
    一旦我们取得了AFN,就可以用以下查询来定位讹误对象了:

    select * 
    from dba_extents
    where file_id = &AFN
    and &BL between block_id AND block_id + blocks - 1;

    如:

    SQL> select *
    2 from dba_extents
    3 where file_id = &AFN
    4 and &BL between block_id AND block_id + blocks - 1;
    Enter value for afn: 5
    Enter value for bl: 34
    
    OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES      BLOCKS RELATIVE_FNO
    ----- ------------ -------------- ------------ --------------- --------- ------- -------- ---------- ------ ------------
    SCOTT DEPT                        TABLE        USERS           0         5       33       65536      8      11

    如果出现上面的查询未返回行,那么可能坏块出现在本地表空间管理(Locally Managed Tablespace:LMT)下的段头上。
    坏块出现在段头上,那么上面的查询不会返回结果,但是其会在alert日志中生产坏块报错信息。在这种情况下,你可以执行以下查询:

    select owner, segment_name, segment_type, partition_name 
    from   dba_segments
    where  header_file = &AFN
      and  header_block = &BL;

    如果坏块在空的EXTENT上(和某个对象无关),或者是在临时表上,上面的查询也会无返回。
    对于临时表,Segment Type应该是TEMPORARY。

    如果坏块在空的EXTENT上,那信息应该在DBA_FREE_SPACE上:

    select * 
    from  dba_free_space
    where file_id = &AFN
      and &BL between block_id AND block_id + blocks - 1;

    可以注意到在Oracle 10g和更高版本中的ORA-1578报错,alert日志中已经有指出讹误对象的相关信息了。如:

    Corrupt Block Found
    TSN = 5, TSNAME = USERS
    RFN = 11, BLK = 34, RDBA = 46137378
    OBJN = 46107, OBJD = 36440, OBJECT = DEPT, SUBOBJECT =
    SEGMENT OWNER = SCOTT, SEGMENT TYPE = Table Segment

     

    2. 如何在ORA-600 [6200] 报错中定位讹误的索引

    描述:
    在访问某张表时,你遇到ORA-600 [6200]报错,这个报错意味着相关索引被探测到存在讹误。
    标准的解决方法是drop掉索引并为这张表重建所有相关索引。
    不过,我们可以从trace文件当时生成的报错中定位哪个索引出的问题。
     
    例如:

    例子中显示的是从trace文件中看到的索引报错信息。

    • trace file报错信息:
      ksedmp: internal or fatal error
      ORA-00600: internal error code, arguments: [6200], [260], [262], [], [], [], [], []
    
      Block header dump: dba: 0x7b404757
       Object id on Block? Y
       seg/obj: 0x6190 csc: 0x00.4e537b5  itc: 2  flg: -typ: 2 - INDEX
           fsl: 0  fnx: 0x0 
    • 注意这里seg/obj指出的Hex值,我们可以将其转为十进制值,这个值就是对象id号。

        0x6190 也就是24976   Hex = 00006190  Octal = 00000060620

    • 这样我们就能在DBA_OBJECTS视图中找到索引对象了.
    SVRMGR> SELECT OBJECT_ID, OBJECT_NAME FROM DBA_OBJECTS
              WHERE DATA_OBJECT_ID  = '24976';
    
    DATA_OBJEC OBJECT_NAME                                                                 
    ---------- ------------------------------------------------------
         24976 tab1_index5

     这个索引就是我们应该去重建的那个。

     

    重建索引语法

    ALTER INDEX [schema.]index REBUILD  
         [PARAMETERS ('rebuild_params [physical_storage_params]' ) ] 
         [{ NOPARALLEL | PARALLEL [ integer ] }] ;
    或
    
    ALTER INDEX [schema.]index REBUILD ONLINE 
         [PARAMETERS ('rebuild_params [physical_storage_params]' ) ] 
         [{ NOPARALLEL | PARALLEL [ integer ] }] ;
    或
    
    ALTER INDEX [schema.]index REBUILD PARTITION partition  
         [PARAMETERS ('rebuild_params [physical_storage_params]' ) ];

    需要注意的部分参数使用     
    rebuild_params:

    • index_status=cleanup
      在进行online rebuild操作(ALTER INDEX REBUILD ONLINE)后,对相关表的旧版本索引(用户查询已经结束)进行清理。 

    如:

    ALTER INDEX [schema.]index REBUILD ONLINE PARAMETERS ('index_status=cleanup');

    physical_storage_params:

    • tablespace
      指定索引建立在哪个表空间下。语法上和CREATE TABLE 所使用的指定TABLESPACE的STORAGE语法相同。
    • { NOPARALLEL | PARALLEL [ integer ] }
      默认为NOPARALLEL

    如:

    ALTER INDEX oldindex REBUILD PARAMETERS('tablespace=TBS_3');

    展开全文
  • oracle多个字段组成唯一索引约束

    千次阅读 2018-11-26 18:59:02
    --原来EXPENSE_ITEM_CODE, EXPENSE_TYPE_CODE, EXP_REPORT_TYPE_CODE这三为唯一索引约束,现在添加company_id到这三中, 四组成唯一索引约束。(思路,需要先删除该索引约束名,在=再创建) 注意事项(报错...
  • 我有一个表AV01, ...能用上PK_AV01这个索引 假如我的索引是只有AV1字段的, PK_AV02 primary key (AV1) 那么我用PK_AV01 做索引的效率 高还是 PK_AV02 做索引的效率高,还是说是一样的?
  • Oracle索引

    千次阅读 2015-11-26 11:57:13
    PS:因为在某些大表中,包含的数据非常,如果按照顺序遍历的方式来进行查询,速度非常慢,这样的话我们就可以给表上面加上一个索引来提高查询速度。但是对于一张频繁进行CUD操作的表,建立过多索引会导致这些操作...
  • oracle 指定索引

    千次阅读 2019-02-24 17:20:21
    表中如果创建多个索引, 测试发现使用不同索,查询效率有较大差别。 我们希望使用某个更快的索引, 这个时候需要指定索引,以明确告诉oracle使用更快的索引。 oracle指定索引语法: /*+index(t ind_name)*/ “t”...
  • Oracle--使用索引

    千次阅读 2019-05-28 14:07:24
    使用索引 索引用于加快数据定位速度。通过使用索引,可以大大降低I/O次数,从而提高SQL语句...注意,在同一张表上可以建立多个索引,但要求列的组合必须不同,使用以下语句建立的两个索引是合法的: CREATE INDEX em...
  • Oracle 分区索引

    千次阅读 2014-07-08 12:12:06
    就是简单地把一个索引分成多个片断,在获取所需数据时,只需要访问更小的索引片断(块)即可实现。同时把分区放在不同的表空间可以提高分区的可用性和可靠性。本文主要描述了分区索引的相关特性并给出演示示例。1、...
  • Oracle索引原理

    千次阅读 2017-10-23 17:17:18
    其中聚集索引只能有一oracle索引的主要分为根,茎,叶子三部分。索引列值都是存放在叶子节点上,茎只是存放了叶子节点的相关信息。 oracle中的索引反应的是逻辑结构,不是物理结构。索引创建的时候,是先创建...
  • Oracle-index索引解读

    万次阅读 2016-10-27 21:25:05
    概述Oracle-OLAP和OLTP解读Oracle-index索引解读Oracle-分区表解读Oracle-锁解读Oracle-等待事件解读Oracle-procedure/cursor解读 索引是数据库对象之一,用于加快数据的检索 索引是建立在表上的可选对象;索引的...
  • ORACLE 全局索引和本地索引

    千次阅读 2018-10-11 17:57:12
    全局索引以整个表的数据为对象建立索引索引分区中的索引条目既可能是基于相同的键值但是来自不同的分区,也可能是多个不同键值的组合。   全局索引既允许索引分区的键值和表分区键值相同,也可以不相同。全局...
  • 当然Oracle官方也有自己的观点,我们很DBA也是遵循这一准则来重建索引,那就是Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引。近来Oracle也提出了...
  • Oracle数据库索引

    万次阅读 2013-06-14 16:54:22
    1 索引基本概念 索引是用于加速数据存取的数据对象,合理的使用索引可以大幅降低I/O次数,从而提高数据访问性能。...在同一张表上可以有多个索引,但是这些索引所包含的列的组合必须不完全相同。如: create index
  • oracle索引

    千次阅读 2009-12-25 14:03:00
    索引的类型: B-树索引 位图索引 HASH索引 索引编排表 反转键索引 基于函数的索引 分区索引 本地和全局索引 限制索引(索引失效)容易引起oracle索引失效的原因很:(需要具体分析。你可以根据执行计划来判断...
  • ORACLE索引

    千次阅读 2012-10-08 16:09:19
    经常一起使用多个字段检索记录,组合索引比单索引更有效把最常用的列放在最前面,例:dx_groupid_serv_id(groupid,serv_id),在where条件中使用groupid或groupid,serv_id,查询将使用索引,若仅用到serv_id字段,则...
  • oracle复合索引介绍(字段索引)

    千次阅读 2012-12-10 19:35:06
    oracle普通索引介绍(单字段索引) : http://ysj5125094.iteye.com/blog/1745354 ...如果分别按纳税人识别号,税务机关代码,月份3字段查询,每字段在该表中的可选性或约束性都不强,如一纳税人识别号有很...
  • Oracle如何创建条件索引

    千次阅读 2018-07-23 17:39:26
    首先讲述一业务场景: 数据库商品表中有goods_id,goods_name,goods_price,status四字段,goods_id是自增主键,status是状态,只有0,1两种可能,默认为1,goods_name是商品名称。要求状态为1 的商品名称不...
  • Oracle强制索引

    2008-10-06 20:43:28
    Oracle强制索引的说明及应用,处理大型数据库必备。
  • oracle null值和索引

    千次阅读 2018-09-05 11:03:50
    NULL值是关系数据库系统布尔型(true,false,unknown)中比较特殊类型的一种值,通常称为...正是基于这样一特性,对于NULL值列上的B树索引导致了is null/is not null不走索引的情形,下面描述了NULL值与索引以及索...
  • oracle-数据库的索引-index-详解

    千次阅读 2017-06-09 16:11:17
    Oracle-index索引解读 Oracle-分区表解读 Oracle-锁解读 Oracle-等待事件解读 Oracle-procedure/cursor解读 索引是数据库对象之一,用于加快数据的检索 索引是建立在表上的可选对象;索引的关键在于通过一组...
  • oracle表强制走索引的方法

    万次阅读 2019-04-13 17:07:38
    在某些时候,即使查询条件有索引字段依然不走索引, 这种情况下可以采取添加/*+index(表别名索引名)*/ 的方式,让查询强制走索引。 没走索引的情况下,查了全表: 强制走索引IDX_LOGIN_LOG_1112_TIME后,...
  • Oracle 索引监控与外键索引

    千次阅读 2013-03-29 10:49:56
    Oracle 监控索引特性为我们提供了一大致判断索引是否被使用的情形。之所以这么说,是因为在Oracle 10g 中收集统计信息时会导致索引被监控,此并非sql语句而产生。而在11g则不会出现类型的情形。其次对于存在子表...
  • oracle 用户 全部 索引 all index sql
  • Oracle 复合索引

    万次阅读 2016-04-25 17:05:35
    用户可以在多个列上建立索引,这种索引叫做复合索引(组合索引)。复合索引的创建方法与创建单一索引的方法完全一样。但复合索引在数据库操作期间所需的开销更小,可以代替多个单一索引。当表的行数远远大于索引键的...
  • Oracle分析表和索引

    千次阅读 2013-07-12 23:11:24
    对于使用CBO很有好处,可以使用更可靠的table信息,从而执行计划也可以更准确一些,在10g会自动analyze,之前的版本需要手动定期生成统计信息,,选择合理的执行计划..Oracle的online document这样描述

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 171,970
精华内容 68,788
关键字:

oracle增加多个索引