
1、按照索引列值的唯一性,索引可分为唯一索引和非唯一索引
非唯一索引:B树索引
create index 索引名 on 表名(列名) tablespace 表空间名;
唯一索引:建立主键或者唯一约束时会自动在对应的列上建立唯一索引
2、索引列的个数:单列索引和复合索引
3、按照索引列的物理组织方式
B树索引
create index 索引名 on 表名(列名) tablespace 表空间名;
位图索引
create bitmap index 索引名 on 表名(列名) tablespace 表空间名;
反向键索引
create index 索引名 on 表名(列名) reverse tablespace 表空间名;
函数索引
create index 索引名 on 表名(函数名(列名)) tablespace 表空间名;
删除索引
drop index 索引名
重建索引
alter index 索引名 rebuild
索引的创建格式:
CREATE UNIUQE | BITMAP INDEX <schema><index_name>
ON <schema><table_name>
(<column_name> | <expression> ASC | DESC,
<column_name> | <expression> ASC | DESC,)
TABLESPACE <tablespace_name>
STORAGE <storage_settings>
LOGGING | NOLOGGING
COMPUTE STATISTICS
NOCOMPRESS | COMPRESS<nn>
NOSORT | REVERSE
PARTITION | GLOBAL PARTITION<partition_setting>
UNIQUE | BITMAP:指定UNIQUE为唯一值索引,BITMAP为位图索引,省略为B-Tree索引。
<column_name> | <expression> ASC | DESC:可以对多列进行联合索引,当为expression时即“基于函数的索引”
TABLESPACE:指定存放索引的表空间(索引和原表不在一个表空间时效率更高)
STORAGE:可进一步设置表空间的存储参数
LOGGING | NOLOGGING:是否对索引产生重做日志(对大表尽量使用NOLOGGING来减少占用空间并提高效率)
COMPUTE STATISTICS:创建新索引时收集统计信息
NOCOMPRESS | COMPRESS<nn>:是否使用“键压缩”(使用键压缩可以删除一个键列中出现的重复值)
NOSORT | REVERSE:NOSORT表示与表中相同的顺序创建索引,REVERSE表示相反顺序存储索引值
PARTITION | NOPARTITION:可以在分区表和未分区表上对创建的索引进行分区
使用USER_IND_COLUMNS查询某个TABLE中的相应字段索引建立情况
使用DBA_INDEXES/USER_INDEXES查询所有索引的具体设置情况。
在Oracle中的索引可以分为:B树索引、位图索引、反向键索引、基于函数的索引、簇索引、全局索引、局部索引等,下面逐一讲解:
一、B树索引:
最常用的索引,各叶子节点中包括的数据有索引列的值和数据表中对应行的ROWID,简单的说,在B树索引中,是通过在索引中保存排过续的索引列值与相对应记录的ROWID来实现快速查询的目的。其逻辑结构如图:
可以保证无论用户要搜索哪个分支的叶子结点,都需要经过相同的索引层次,即都需要相同的I/O次数。
B树索引的创建示例:
create index ind_t on t1(id) ;
注1:索引的针对字段创建的,相同字段不能创建一个以上的索引;
注2:默认的索引是不唯一的,但是也可以加上unique,表示该索引的字段上没有重复值(定义unique约束时会自动创建);
注3:创建主键时,默认在主键上创建了B树索引,因此不能再在主键上创建索引。
二、位图索引:
有些字段中使用B树索引的效率仍然不高,例如性别的字段中,只有“男、女”两个值,则即便使用了B树索引,在进行检索时也将返回接近一半的记录。
所以当字段的基数很低时,需要使用位图索引。(“低”的标准是取值数量 < 行数1%)
位图索引的逻辑结构如上图所示:索引中不再记录rowid和键值,而是将每个值作为一列,用0和1表示该行是否等于该键值(0表示否;1表示是)。其中位图索引的行顺序与原表的行顺序一致,可以在查询数据的过程中对应计算出行的原始物理位置。
位图索引的创建示例:
create bitmap index ind_t on t1(type);
注:位图索引不可能是唯一索引,也不能进行键值压缩。
三、反向键索引:
考虑这个情况:某一字段的值是1-1000顺序排列,建立B树索引后依旧递增,到后来该B数索引不断在后面增加分支,会形成如下如的不对称树:
反向键索引是一种特殊的B树索引,在存储构造中与B树索引完全相同,但是针对数值时,反向键索引会先反向每个键值的字节,然后对反向后的新数据进行索引。例如输入2008则转换为8002,这样当数值一次增加时,其反向键在大小中的分布仍然是比较平均的。
反向键索引的创建示例:
create index ind_t on t1(id) reverse;
注:键的反转由系统自行完成。对于用户是透明的。
四、基于函数的索引:
有的时候,需要进行如下查询:select from t1 where to_char(date,'yyyy')>'2007';
但是即便在date字段上建立了索引,还是不得不进行全表扫描。在这种情况下,可以使用基于函数的索引。其创建语法如下:
create index ind_t on t1(to_char(date,'yyyy'));
注:简单来说,基于函数的索引,就是将查询要用到的表达式作为索引项。
五、全局索引和局部索引:
这个索引貌似很复杂,其实很简单。总得来说一句话,就是无论怎么分区,都是为了方便管理。
具体索引和表的关系有三种:
1、局部分区索引:分区索引和分区表1对1
2、全局分区索引:分区索引和分区表N对N
3、全局非分区索引:非分区索引和分区表1对N
创建示例:
首先创建一个分区表
create table student
(
stuno number(5),
sname vrvhar2(10),
deptno number(5)
)
partition by hash (deptno)
(
partition part_01 tablespace A1,
partition part_02 tablespace A2
);
创建局部分区索引(1v1):
create index ind_t on student(stuno)
local(
partition part_01 tablespace A2,
partition part_02 tablespace A1
); --local后面可以不加
创建全局分区索引(NvN):
create index ind_t on student(stuno)
global partition by range(stuno)
(
partition p1 values less than(1000) tablespace A1,
partition p2 values less than(maxvalue) tablespace A2
); --只可以进行range分区
创建全局非分区索引(1vN)
create index ind_t on student(stuno) GLOBAL;
聚集索引的好处就是可以让数据按照此索引的顺序进行物理位置存放,用blog_Comment表来说明,此表有comm_idcomm_logidcomm_authorcomm_posttime等字段比如说posttime between DATE1 and DATE2,OK这样的话聚集索引利用到了,因为这个区间段的数据是非常亲密地靠在一起的,可以用最少的I/O开销取得所需的结果集。可是我们知道,更多的时候我们是在显示一个article时然后读取它的所有comments,这时,过滤条件就成了comm_logid = ID了,如果聚集索引被comm_id心安理得地占用的话,那么很可能我们这批comments需要多个数据页才能得到,这样的话,就大大地增加了时间,因为I/O的开销比CPU在内存上的数据查找排序都是要高一个数据级的。但是聚集索引的改变同样会给其它的查询带来负面影响,比如说comm_id = ID的查询,在原来只需要在PK_blog_Comment_comm_id的聚集索引上查找记录,然后得到的指针指向就是实际数据块的存放位置了,但是现在,在此非聚集的唯一索引上查找得到的指针是指向IX_blog_Comment_comm_logid的的位置,所以需要多一次的Bookmark Lookup才能取得所需数据。其实使用的方法很简单,当你需要频繁地取得批量数据时,把聚集索引放在最有可能定位区间的字段上。另外blog_Article的聚集索引我放在posttime上了,因为经常要对此字段进行order by的查询,虽然logid和posttime的排序方向是一样的,但是我这样可能通过cluster index的lookup 节省一个order by的时间,不过到底孰优孰劣我还不敢下结论。其它的blog_Archive,blog_Category的聚集索引都在authorid上,因为这个都是对于authorid = ID的查询。也许随着数据量的增长,情况会有不同,这个以后再看情况调整了。
应该建索引的字段:1经常作为查询条件的字段2外键3经常需要排序的字段4分组排序的字段
应该少建或者不建索引的字段有:1表记录太少,2经常需要插入,删除,修改的表,3表中数据重复且分布平均的字段
一些SQL的写法会限制索引的使用:1where子句中如果使用in、or、like、!= >,均会导致索引不能正常使用,将">"换成">and=chr(0)";2使用函数时,该列就不能使用索引。3比较不匹配数据类型时,该索引将会被忽略。
一些SQL语句优化的写法:1如果from是双表的查询时,大表放在前面,小表放在后面(基础表)。最后面的表是基础表。(只在基于规则的优化器中有效)2如果三表查询时,选择交叉表(intersection table)作为基础表(只在基于规则的优化器中有效)3写where条件时,有索引字段的判断在前,其它字段的判断在后;如果where条件中用到复合索引,按照索引列在复合索引中出现的顺序来依次写where条件;4查询数量较大时,使用表连接代替IN,EXISTS,NOT IN,NOT EXISTS等。5ORACLE采用自下而上的顺序解析WHERE子句,那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾
索引用于快速找到特定一些值的记录。如果没有索引,MySQL就必须从第一行记录开始读取整个表来检索记录。表越大,资源消耗越大。如果在字段上有索引的话,MySQL就能很快决定该从数据文件的哪个位置开始搜索记录,而无须查找所有的数据。如果表中有1000条记录的话,那么这至少比顺序地读取数据快100倍。注意,如果需要存取几乎全部1000条记录的话,那么顺序读取就更快了,因为这样会使磁盘搜索最少。
大部分MySQL索引(PRIMARY KEY, UNIQUE,INDEX 和 FULLTEXT)都是以B树方式存储。只有空间类型的字段使用R树存储,MEMORY (HEAP)表支持哈希索引。
字符串默认都是自动压缩前缀和后缀中的空格。
通常,如下所述几种情况下可以使用索引。哈希索引(用于 MEMORY 表)的独特之处在后面会讨论到。
想要尽快找到匹配 WHERE 子句的记录。
根据条件排除记录。如果有多个索引可共选择的话,MySQL通常选择能找到最少记录的那个索引。
做表连接查询时从其他表中检索记录。
想要在指定的索引字段 key_col 上找到它的 MIN() 或 MAX() 值。优化程序会在检查索引的
key_col 字段前就先检查其他索引部分是否使用了 WHERE key_part_# = constant 子句。这样的话,
MySQL会为 MIN() 或 MAX() 表达式分别单独做一次索引查找,并且将它替换成常数。当所有的表达式都被替换成常数后,查询就立刻返回。如下:
SELECT MIN(key_part2),MAX(key_part2) FROM tbl_name WHERE key_part1=10;
对表作排序或分组,当在一个可用的最左前缀索引上做分组或排序时(如 ORDER
BY key_part1, key_part2)。如果所有的索引部分都按照 DESC 排序,索引就按倒序排序。
有些时候,查询可以优化使得无需计算数据就能直接取得结果。当查询使用表中的一个数字型字段,且这个字段是索引的最左部分,则可能从索引树中能很快就取得结果:
SELECTkey_part3FROMtbl_nameWHEREkey_part1=1
假设有如下 SELECT 语句:
如果在 col1 和 col2 上有一个多字段索引的话,就能直接取得对应的记录了。
数据库索引是一种专用数据结构,允许我们快速定位信息。它的组织方式类似于二叉树结构,左侧值较小,右侧值较大。索引可以比较树状结构中的行值,以更快地定位所需数据,而不是强制扫描整个表。
当我们在一个或多个列上创建索引时,我们将它们的值存储在新结构中,还存储指行的指针。这行为会重新组织并排序信息,但不会改变信息本身。可以将数据库索引视为书后面的索引。虽然它存储了一些实际信息,但它还包含指针,指针指向可以找到更多详细信息的位置。
按照我们的搜索条件对数据进行排序后,查找所需的记录会变得更加简单。想象一下按字母顺序排序的旧电话簿。知道某人的姓氏,名字和地址意味着您可以很快找到他们的电话号码。但是如果你只知道别人的地址和名字怎么办?没有姓氏,找到电话号码将非常困难。您可以使用反向电话簿做得更好,该目录列出了基于地址的电话号码。
在数据库中,更改搜索条件通常意味着为属性组合创建新索引。如前所述,添加这些索引需要额外的磁盘空间。添加,删除或更新值时,还会对索引进行更改。
以上就是关于数据库索引有哪几种,怎样建立索引全部的内容,包括:数据库索引有哪几种,怎样建立索引、如何设置聚集索引(Cluster Index)、请问数据库的索引创建后要怎么用啊等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)