(1)、与索引相关视图
查询DBA_INDEXES
视图可得到表中所有索引的列表;访问USER_IND_COLUMNS
视图可得到一个给定表中被索引的特定列。
(2)、组合索引概念
当某个索引包含有多个已索引的列时,称这个索引为组合(concatented
)索引。
注意:只有在使用到索引的前导索引时才可以使用组合索引
(3)、B*Tree
索引
B*Tree
索引是最常见的索引结构,默认建立的索引就是这种类型的索引。B*Tree
索引在检索高基数数据列(高基数数据列是指该列有很多不同的值)时提供了最好的性能。
DML语句:
Create index indexname on
tablename(columnname[columnname...])
B-tree
特性:
适合与大量的增、删、改(OLTP);
不能用包含OR操作符的查询;
适合高基数的列(唯一值多);
典型的树状结构;
每个结点都是数据块;
大多都是物理上一层、两层或三层不定,逻辑上三层;
叶子块数据是排序的,从左向右递增;
在分支块和根块中放的是索引的范围。
(4)、Bitmap
索引
位图索引主要用于决策支持系统或静态数据,不支持行级锁定。位图索引最好用于低cardinality
列(即列的唯一值除以行数为一个很小的值,接近零)。
DML语句:
Create BITMAP index indexname on
tablename(columnname[columnname...])
Bitmap
特性:
适合与决策支持系统;
做UPDATE
代价非常高;
非常适合OR
操作符的查询;
基数比较少的时候才能建位图索引。
(5)、B*tree
和Bitmap
的不同
在一颗B*
树中,通常索引条目和行之间存在一种一对一的关系:一个索引条目就指向一行;而对于位图索引,一个索引条目则使用一个位图同时指向多行。
位图索引适用于高度重复而且通常只读的数据(高度重复是指相对于表中的总行数,数据只有很少的几个不同值)。B*tree
索引的话通常在访问小数据量的情况下比较适用,比如你访问不超过表中数据的5%
,适用于一般的情况;bitmap
的话在数据仓库中使用较多,用于低基数列,比如性别之类重复值很多的字段,基数越小越好。
(6)、导致索引失效的情况
使用不等于操作符(<>、!=)
通常把不等于操作符改成OR条件,就可以使用索引,以避免全表扫描
使用IS NULL
或IS NOT NULL
使用IS NULL
或IS NOT NULL
同样会限制索引的使用。因为NULL
值并没有被定义。在SQL语句中使用NULL
会有很多的麻烦。因此建议开发人员在建表时,把需要索引的列设成NOT NULL
。如果被索引的列在某些行中存在NULL
值,就不会使用这个索引(除非索引是一个位图索引)。
使用函数
如果不使用基于函数的索引,那么在SQL语句的WHERE
子句中对存在索引的列使用函数时,会使优化器忽略掉这些索引。
比较不匹配的数据类型
不匹配的数据类型之间比较会让Oracle自动限制索引的使用,即便对这个查询执行Explain Plan
也不能让您明白为什么做了一次”全表扫描”。
复合索引中的前导列没有被作为查询条件
复合索引中,一定要将前导列作为查询条件,索引才会被使用
CBO模式下选择的行数比例过大,优化器采取了全表扫描
这是基于代价的优化考虑
查询高基数字段 Querying a High Cardinality Field
问题详情
我正在为即将到来的Cassandra迁移订单设计数据模型。 订单具有orderId
(奥术UUID字段)和orderNumber
(用户友好号码)。 可以使用两者中的任何一个来完成getOrder
查询。
我的分区键是orderId
,因此getByOrderId
不是问题。 通过getByOrderNumber
- 在orderId
和orderNumber
(高基数字段)之间存在一对一的映射,因此在每个节点上创建本地二级索引会减慢我的查询速度。
我想知道的是,我可以创建一个新的表,其中orderNumber作为分区键,orderId作为唯一的列(一种二级索引,但由我维护)。 现在,可以在两次调用中解析getByOrderNumber查询。
如果上述解决方案出现严重错误,请耐心等待,我对卡桑德拉来说是个新手。 据我了解,对于这样一个列,如果我使用本地二级索引,Cassandra将不得不查询每个节点的单个订单。 所以我想为什么不创建另一个存储映射的表。
我自己管理这个索引会缺少什么? 有一点我可以看到,如果每次写入,我现在必须更新两个表。 还要别的吗?
答案
我想为什么不创建另一个存储映射的表。
没关系。 来自Cassandra文档:
在这些情况下不要使用索引 :
在高基数列上,因为您然后查询大量记录以获取少量结果。 请参阅下面的使用高基数列索引的问题。
使用高基数列索引的问题
如果您在具有许多不同值的高基数列上创建索引,则字段之间的查询会导致很多搜索结果很少。 在拥有十亿首歌曲的表格中,通过作者查找歌曲(每首歌曲通常是唯一的值)而非他们的录音艺术家可能效率非常低。
将表作为索引的形式手动维护而不是使用内置索引可能更有效。 对于包含唯一数据的列,只要具有索引列的表的查询量适中且不在恒定负载下,为方便起见,使用索引有时性能良好。
相反,在极低基数列(例如布尔列)上创建索引没有意义。 索引中的每个值都成为索引中的一行,例如,所有错误值都会产生一个巨大的行。 索引具有foo = true
和foo = false
的多个索引列是没有用的。
Cassandra
数据建模具有非规范化数据是正常的。