• B树索引和位图索引的区别!


    B树索引
    主键和唯一性约束字段的B树索引,效率几乎和海量数据没有关系。

    键值重复率低的字段比较适合使用B树索引。

    位图索引
    键值重复率高的字段比较适合使用位图索引。
    count、and、or、in这些特定的操作更适合位图索引。

    DML操作比较多的表不适合使用位图索引。

    复合索引
    在where条件中必须带驱动列,复合索引才会使用。

    键值重复率低(DISTINCT数量多)的字段放在前面。

    用实验说明为什么位图索引不适合OLTP,比较适合OLAP。即:DML操作比较多的表不适合使用位图索引。

    首先创建测试表:

    1. SQL> create table t1(id int,name varchar(10),value varchar(10));  
    2.   
    3. 表已创建。  
    4.   
    5. SQL> create bitmap index ind_t1_id on t1(id);  
    6.   
    7. 索引已创建。  
    8.   
    9. SQL> insert into t1 values(1,'a','aa');  
    10.   
    11. 已创建 1 行。  
    12.   
    13. SQL> insert into t1 values(1,'b','bb');  
    14.   
    15. 已创建 1 行。  
    16.   
    17. SQL> commit;  
    18.   
    19. 提交完成。  
    20.   
    21. SQL> select * from t1;  
    22.   
    23.         ID NAME       VALUE  
    24. ---------- ---------- ----------  
    25.          1 a          aa  
    26.          1 b          bb  


    session1:

    1. SQL> select distinct sid from v$mystat;  
    2.   
    3.        SID  
    4. ----------  
    5.        140  
    6.   
    7. SQL> update t1 set id = 2 where name = 'a';  
    8.   
    9. 已更新 1 行。  


    session2:

    1. SQL> select distinct sid from v$mystat;  
    2.   
    3.        SID  
    4. ----------  
    5.        147  
    6.   
    7. SQL> update t1 set id = 2 where name = 'b';  


    阻塞信息:

    1. SQL> select * from v$lock where sid in(140,147) order by type;  
    2.   
    3. ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK  
    4. -------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------  
    5. 288F60DC 288F60F4        147 TM      55628          0          3          0        111          0  
    6. 288F6030 288F6048        140 TM      55628          0          3          0        270          0  
    7. 28945B40 28945B64        147 TX     655404        533          6          0        111          0  
    8. 28939F60 28939F84        140 TX     589829        616          6          0        270          1  
    9. 294344A8 294344BC        147 TX     589829        616          0          4        111          0  
    10.   
    11. SQL> select sid,status,last_call_et,blocking_session from v$session where sid in(140,147);  
    12.   
    13.        SID STATUS   LAST_CALL_ET BLOCKING_SESSION  
    14. ---------- -------- ------------ ----------------  
    15.        140 INACTIVE          285  
    16.        147 ACTIVE            126              140  

    可以看见140阻塞了147。尽管他们修改的不是同一列。

    注意:这里不仅仅是根据name='a'去修改会阻塞其他会话,如果根据value = 'aa'或者name = 'a' and value = 'aa'来修改操作,也是同样会阻塞的!!! 因为都是改的id的值,而Index就是建在id上面的。但是如果不是改id列,而是改name或者value列就不存在阻塞的情况!!!

    如果使用B树索引,就不存在阻塞情况了。创建同样的t2表,只是索引不一样

    1. SQL> create table t2 as select * from t1;  
    2.   
    3. 表已创建。  
    4.   
    5. SQL> select * from t2;  
    6.   
    7.         ID NAME       VALUE  
    8. ---------- ---------- ----------  
    9.          2 a          aa  
    10.          2 b          bb  
    11.   
    12. SQL> create index ind_t2_id on t2(id);  
    13.   
    14. 索引已创建。  


    session1:

    1. SQL> select distinct sid from v$mystat;  
    2.   
    3.        SID  
    4. ----------  
    5.        140  
    6.   
    7. SQL> update t2 set id = 1 where name = 'a';  
    8.   
    9. 已更新 1 行。  


    session2:

    1. SQL> select distinct sid from v$mystat;  
    2.   
    3.        SID  
    4. ----------  
    5.        147  
    6.   
    7. SQL> update t2 set id = 1 where name = 'b';  
    8.   
    9. 已更新 1 行。  

    可以看见,各自都可以修改,不存在阻塞现象!

  • 相关阅读:
    Idea中将项目支持groovy语法
    Python驱动SAP GUI完成自动化(四)
    山东一男孩疑被假警察掳走
    关系型数据库,查看表列表,及字段列表
    my.cnf配置
    MySQL 密码策略
    Docker UnicodeEncodeError: 'ascii' codec can't encode characters in position
    三星S20开启120Hz高刷新率
    三星S20关闭5G消息状态图标
    Centos 7挂载本地ISO光盘
  • 原文地址:https://www.cnblogs.com/hllnj2008/p/4796238.html
Copyright © 2020-2023  润新知