关于索引的范文

时间：2022-12-28 03:40:56 作者：海派甜心金有谦综合材料收藏本文下载本文

“海派甜心金有谦”通过精心收集，向本站投稿了16篇关于索引的范文，以下是小编帮大家整理后的关于索引的范文，仅供参考，欢迎大家阅读。

目录
第1篇：索引色第2篇：索引监控第3篇：证明材料索引第4篇：Oracle分区索引第5篇：分区索引（一）第6篇：索引优缺点分析第7篇：B+树索引第8篇：MySQL 索引详解第9篇：数据库索引的使用方法第10篇：分区索引（二）本地分区索引第11篇：SEO倒叙索引术语第12篇：oracle数据库索引失效第13篇：创建索引组织表第14篇：如何手动重建 Spotlight 索引第15篇：oraclebtreeindex索引块结构初探第16篇：mongodb学习(索引详解)

篇1：索引色

为节约存储，把图像中使用的颜色与一个颜色表对应起来，索引色常使用16色、32色、64色、128色或216色等，但最多不得超过256色，

索引色

，

篇2：索引监控

索引监控

在某个OLTP系统中某张表上建立了10个索引，由于不确定索引是否有在各程序中被使用，不能随意删除，因此，需要监控已有的索引是否在使用，

官方文档描述：

Monitoring Index Usage

Oracle Database provides a means of monitoring indexes to determine whether they are being used. If an index is not being used, then it can be dropped, eliminating unnecessary statement overhead.

To start monitoring the usage of an index, issue this statement:

ALTER INDEX index MONITORING USAGE; //开启索引监控

Later, issue the following statement to stop the monitoring:

ALTER INDEX index NOMONITORING USAGE; //关闭索引监控

The view V$OBJECT_USAGE can be queried for the index being monitored to see if the index has been used. The view contains a USED column whose value is YES or NO, depending upon if the index has been used within the time period being monitored. The view also contains the start and stop times of the monitoring period, and a MONITORING column (YES/NO) to indicate if usage monitoring is currently active.

Each time that you specify MONITORING USAGE, the V$OBJECT_USAGE view is reset for the specified index. The previous usage information is cleared or reset, and a new start time is recorded. When you specify NOMONITORING USAGE, no further monitoring is performed, and the end time is recorded for the monitoring period. Until the next ALTER INDEX...MONITORING USAGE statement is issued, the view information is left unchanged.

开启索引监控后，可以从v$object_usage中查询到数据（即使索引还没有被使用），START_MONITORING 字段会写入开始监控的时间；当某条SQL使用了相关的索引以后，其“USED”字段就会更新为’YES‘，监控索引结束后最好关闭监控，以提高效率。

注意：v$object_usage 要去每个USERS 中查询，即使用SYS权限开启的其他USER索引的监控，也无法从SYS用户的V$OBJECT_USAGE 中插到相关的记录。下面有验证

实验：测试一个索引

[oracle@tyger ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Mar 28 16:19:01 2014

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

SYS@ORCL>create user tyger identified by tyger; // 创建测试用户 tyger

User created.

SYS@ORCL>grant connect,resource to tyger; // 赋予tyger connect，resource 权限

Grant succeeded.

SYS@ORCL>grant select on dba_objects to tyger; // 授予 dba_objects 查询权限给 tyger

Grant succeeded.

SYS@ORCL>conn tyger/tyger

Connected.

TYGER@ORCL>create table test_monitor as select * from dba_objects; // 创建测试表

Table created.

TYGER@ORCL>select * from user_indexes; // 查看当前用户下的索引

no rows selected

TYGER@ORCL>create index test_monitor_idx on test_monitor(object_id); // 基于 object_id 字段创建索引

Index created.

TYGER@ORCL>col INDEX_NAME for a20

TYGER@ORCL>col TABLE_NAME for a20

TYGER@ORCL>col TABLE_OWNER for a20

TYGER@ORCL>l

1 select index_name,table_name,table_owner

2* from user_indexes

TYGER@ORCL>/ // 查看当前用户下的索引

INDEX_NAME TABLE_NAME TABLE_OWNER

-------------------- -------------------- --------------------

TEST_MONITOR_IDX TEST_MONITOR TYGER

TYGER@ORCL>

TYGER@ORCL>alter index TEST_MONITOR_IDX monitoring usage; // 开启索引监控

Index altered.

TYGER@ORCL>select * from v$object_usage; // 查看视图 object_usage 索引监控和使用情况

INDEX_NAME TABLE_NAME MON USE START_MONITORING

-------------------- -------------------- --- --- -------------------

END_MONITORING

-------------------

TEST_MONITOR_IDX TEST_MONITORYESNO03/28/2014 16:22:46 // MONITORING 为 'YES' 代表已经监控

// USAGE 为 ’NO‘ 代表索引未被使用

TYGER@ORCL>conn / as sysdba

Connected.

SYS@ORCL>

SYS@ORCL>select * from v$object_usage; // 无法从SYS用户的V$OBJECT_USAGE 中插到相关的记录

no rows selected

TYGER@ORCL>set autotrace on // 开启自动跟踪

SP2-0618: Cannot find the Session Identifier. Check PLUSTRACE role is enabled // 出现这个错误，暂时可以略过，不影响接下来的实验

SP2-0611: Error enabling STATISTICS report

TYGER@ORCL>select * from TEST_MONITOR where object_id=111;

OWNER

------------------------------

OBJECT_NAME

--------------------------------------------------------------------------------

SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE

------------------------------ ---------- -------------- -------------------

CREATED LAST_DDL_ TIMESTAMP STATUS T G S

--------- --------- ------------------- ------- - - -

SYS

I_ARGUMENT1

111 111 INDEX

30-JUN-05 30-JUN-05 2005-06-30:19:10:18 VALID N N N

Execution Plan

----------------------------------------------------------

Plan hash value: 2240611133

--------------------------------------------------------------------------------

----------------

CPU)| Time |

--------------------------------------------------------------------------------

----------------

| 0 | SELECT STATEMENT | | 1 | 177 | 2

(0)| 00:00:01 |

| 1 | TABLE ACCESS BY INDEX ROWID| TEST_MONITOR | 1 | 177 | 2

(0)| 00:00:01 |

(0)| 00:00:01 |

--------------------------------------------------------------------------------

----------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access(“OBJECT_ID”=111)

Note

-----

- dynamic sampling used for this statement

TYGER@ORCL>select * from v$object_usage;

INDEX_NAME TABLE_NAME MON USE START_MONITORING

-------------------- -------------------- --- --- -------------------

END_MONITORING

-------------------

TEST_MONITOR_IDX TEST_MONITORYESYES03/28/2014 16:22:46 // MONITORING 为 'YES' 代表已经监控

// USAGE 为 ’YES‘ 代表索引已经被使用

Execution Plan

----------------------------------------------------------

ERROR:

ORA-01039: insufficient privileges on underlying objects of the view

SP2-0612: Error generating AUTOTRACE EXPLAIN report

TYGER@ORCL>set autotrace off;

TYGER@ORCL>

篇3：证明材料索引

资质复查证明材料分类索引表

1.请按索引及页码顺序依次放置证明材料，单独装订成册。

2.证明材料打印件、复印件要求清晰可辨，逐页加盖企业公章。

篇4：Oracle分区索引

----------------------------------------------------------

Plan hash value: 2556877094

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 41 | 2 (0)| 00:00:01 | | |

| 1 | PARTITION RANGE SINGLE | | 1 | 41 | 2 (0)| 00:00:01 | 1 | 1 |

| 2 | TABLE ACCESS BY LOCAL INDEX ROWID| BIG_TABLE | 1 | 41 | 2 (0)| 00:00:01 | 1 | 1 |

|* 3 | INDEX RANGE SCAN | BITA_CREATED_DATE_I | 1 | | 1 (0)| 00:00:01 | 1 | 1 |

--------------------------------------------------------------------------------------------------------------------------

3、全局分区索引演示

--为表添加主键

SQL>ALTER TABLE big_table ADD (

2 CONSTRAINT big_table_pk PRIMARY KEY (id)

3 );

Table altered.

SQL>select index_name,index_type,tablespace_name,global_stats,partitioned

2 from user_indexes where index_name='BIG_TABLE_PK';

INDEX_NAME INDEX_TYPE TABLESPACE_NAME GLO PAR

------------------------------ --------------------------- ------------------------------ --- ---

BIG_TABLE_PK NORMAL TBS_TMP YES NO

SQL>set autot trace exp;

SQL>select * from big_table where id=1412;

Execution Plan

----------------------------------------------------------

Plan hash value: 2662411593

-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 62 | 2 (0)| 00:00:01 | | |

| 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| BIG_TABLE | 1 | 62 | 2 (0)| 00:00:01 | ROWID | ROWID |

|* 2 | INDEX UNIQUE SCAN | BIG_TABLE_PK | 1 | | 1 (0)| 00:00:01 | | |

-------------------------------------------------------------------------------------------------------------------

--如上，在其执行计划中，Pstart与Pstop都为ROWID

--出现了GLOBAL INDEX ROWID，我们添加主键时并未指定Global，但其执行计划表明执行了全局索引访问

--这个地方有待证实，对于分区表，非分区键上的主键或唯一索引是否一定是全局索引

SQL>drop index bita_created_date_i;

--下面创建全局索引，创建时需要指定分区键的范围和值

SQL>CREATE INDEX bita_created_date_i

ON big_table (created_date)

GLOBAL PARTITION BY RANGE (created_date)

(

PARTITION

idx_1 VALUES LESS THAN (TO_DATE ('01/01/2013', 'DD/MM/YYYY'))

TABLESPACE idx1,

PARTITION

idx_2 VALUES LESS THAN (TO_DATE ('01/01/2014', 'DD/MM/YYYY'))

TABLESPACE idx2,

PARTITION idx_3 VALUES LESS THAN (maxvalue) TABLESPACE idx3);

SQL>select index_name, partitioning_type, partition_count,locality from user_part_indexes;

INDEX_NAME PARTITI PARTITION_COUNT LOCALI

------------------------------ ------- --------------- ------

BITA_CREATED_DATE_I_G RANGE 3 GLOBAL

SQL>select partition_name, high_value, tablespace_name from user_ind_partitions;

PARTITION_NAME HIGH_VALUE TABLESPACE_NAME

------------------------------ --------------------- ------------------------------

IDX_1 TO_DATE(' 2013-01-01 IDX1

IDX_2 TO_DATE(' 2014-01-01 IDX2

IDX_3 MAXVALUE IDX3

--下面是其执行计划，可以看出支持分区消除

SQL>set autot trace exp;

SQL>select * from big_table where created_date=to_date('20130625','yyyymmdd');

Execution Plan

----------------------------------------------------------

Plan hash value: 1378264218

---------------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 41 | 2 (0)| 00:00:01 | | |

| 1 | PARTITION RANGE SINGLE | | 1 | 41 | 2 (0)| 00:00:01 | 2 | 2 |

| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID| BIG_TABLE | 1 | 41 | 2 (0)| 00:00:01 | 2 | 2 |

|* 3 | INDEX RANGE SCAN | BITA_CREATED_DATE_I | 1 | | 1 (0)| 00:00:01 | 2 | 2 |

---------------------------------------------------------------------------------------------------------------------------

--以下为范围查询，Pstart为1，Pstop为2，同样支持分区消除

SQL>select * from big_table

2 where created_date>=to_date('20120625','yyyymmdd') and created_date<=to_date('20130625','yyyymmdd');

Execution Plan

----------------------------------------------------------

Plan hash value: 213633793

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 3334 | 133K| 14 (0)| 00:00:01 | | |

| 1 | PARTITION RANGE ITERATOR| | 3334 | 133K| 14 (0)| 00:00:01 | 1 | 2 |

|* 2 | TABLE ACCESS FULL | BIG_TABLE | 3334 | 133K| 14 (0)| 00:00:01 | 1 | 2 |

------------------------------------------------------------------------------------------------------

篇5：分区索引（一）

分区索引（一）

1、分区索引

分区索引就是简单地把一个索引分成多个片断，通过把一个索引分成多个片断，可以访问更小的片断(也更快)，并且可以把这些片断分别存放在不同的磁盘驱动器上(避免I/O问题)。B树和位图索引都可以被分区，而HASH索引不可以被分区。可以有好几种分区方法：表被分区而索引未被分区；表未被分区而索引被分区；表和索引都被分区。不管采用哪种方法，都必须使用基于成本的优化器。分区能够提供更多可以提高性能和可维护性的可能性。

1、有两种类型的分区索引：本地分区索引和全局索引。

每个类型都有两个子类型，有前缀索引和无前缀索引。表各列上的索引可以有各种类型索引的组合。如果使用了位图索引，就必须是本地索引。把索引分区最主要的原因是可以减少所需读取的索引的大小，另外把分区放在不同的表空间中可以提高分区的可用性和可靠性。

在使用分区后的表和索引时，Oracle还支持并行查询和并行DML。这样就可以同时执行多个进程，从而加快处理这条语句。

（1）有前缀的分区索引指包含了分区键，并且将其作为引导列的索引。

如：

create index i_id_global on PDBA(id) global --引导列 2 partition by range(id) --分区键 3 (partition p1 values less than (200), 4 partition p2 values less than (maxvalue) 5 );

这里的ID 就是分区键，并且分区键id 也是索引的引导列。

（2）无前缀的分区索引的列不是以分区键开头，或者不包含分区键列。

如：

create index ix_custaddr_local_id_p on custaddr(id)local ( partition t_list556 tablespace icd_service, partition p_other tablespace icd_service)

这个分区是按照areacode来的。但是索引的引导列是ID。所以它就是非前缀分区索引。

（3）全局分区索引不支持非前缀的分区索引，如果创建，报错如下：

sql>create index i_time_global on PDBA(id) global --索引引导列 2 partition by range(time) --分区建 3 (partition p1 values less than (TO_DATE('2010-12-1', 'YYYY-MM-DD')), 4 partition p2 values less than (maxvalue) 5 );partition by range(time) *

第 2 行出现错误:

ORA-14038: GLOBAL 分区索引必须加上前缀

2、Local索引肯定是分区索引，Global索引可以选择是否分区，如果分区，只能是有前缀的分区索引。

2、类型

1）本地索引---局部分区索引 --局部索引比全局索引容易管理, 而全局索引比较快。

其分区形式与表的分区完全相同，依赖列相同，存储属性也相同。对于本地索引，其索引分区的维护自动进行，就是说你add/drop/split/truncate表的分区时，本地索引会自动维护其索引分区。

在表分区后，对每个表分区建立一个索引，对表的索引进行均匀分区称为局部分区。

局部分区索引广泛的应用在大型OLAP的数据仓库中。支持更高的高可用性，某个分区表的数据出现问题，只影响该分区表对应的局部索引，单独重构局部索引就行，而且恢复起来更方便，如果知道表进行MOVE后,ROWID变化了,所以索引也需要REBUILD，分区表也可以对单个分区进行MOVE，因为局部分区索引是跟表分区一致的，所以只要是对单个表分区进行MOVE,我们也只需要REBUILD单个局部索引分区，分区表技术可以实现将某一个分区恢复到某个时间点，而局部分区索引同步到该时间点，而数据仓库大量的IO容易造成部分磁盘或IO损坏，如果用局部分区索引影响非常小

2）全局索引: -----Oracle只支持2中类型的全局分区索引：range partitioned 和 Hash Partitioned.

即可以分区，也可以不分区。即可以建range分区，也可以建hash分区，即可建于分区表，又可创建于非分区表上，就是说，全局索引是完全独立的，因此它也需要我们更多的维护操作，

全局索引分区数据指向任何一个表分区的分区索引，9I全局索引只有范围全局索引，10G有HASH全局索引。

全局索引以前常用在OLTP。维护麻烦，影响到所有的全局分区索引，OLTP中最重要的是数据的完整性和准确性，而全局分区索引的及时重构将使得可靠性得到保证。

3、与分区索引有关的视图

dba_part_indexes 分区索引的概要统计信息，可以得知每个表上有哪些分区索引，分区索引的类型(local/global) dba_ind_partitions 每个分区索引的分区级统计信息 dba_indexes minus dba_part_indexes （minus操作）可以得到每个表上有哪些非分区索引create index i_id_global on PDBA(id) globalpartition by range(id)(partition p1 values less than (200),partition p2 values less than (4000),partition p3 values less than (8000),partition p4 values less than (maxvalue));

示例：

1、查询分区索引相关属性：索引类型

---dba_part_indexesSQL>select index_name,table_name,partitioning_type,locality,ALIGNMENT from dba_part_indexes where table_name='PDBA';INDEX_NAME TABLE_NAME PARTITI LOCALI ALIGNMENT------------------------------ ------------------------------ ------- ------ ------------I_ID_GLOBAL PDBA RANGE GLOBAL PREFIXED

2、查询索引关联的分区信息 -

-dba_ind_partitionsSQL>select index_name,partition_name, status from dba_ind_partitions where index_name='I_ID_GLOBAL';INDEX_NAME PARTITION_NAME STATUS------------------------------ ------------------------------ --------I_ID_GLOBAL P1 USABLEI_ID_GLOBAL P2 USABLEI_ID_GLOBAL P3 USABLEI_ID_GLOBAL P4 USABLE

3、查看索引对应的列

--dba_ind_partitionsset linesize 230col column_name format a30SQL>select table_name,index_name,column_name from dba_ind_columns where table_name='PDBA' and table_owner='SYS';TABLE_NAME INDEX_NAME COLUMN_NAME------------------------------ ------------------------------ ------------------------------PDBA I_ID_GLOBAL ID

4、查询非分区索引的基础信息：存储

--dba_indexesSQL>select owner,index_name,table_name,status from dba_indexes where INDEX_NAME='I_ID_GLOBAL';OWNER INDEX_NAME TABLE_NAME STATUS------------------------------ ------------------------------ ------------------------------ --------SYS I_ID_GLOBAL PDBA N/A

篇6：索引优缺点分析

优点：

1：创建唯一性索引，保证数据库表中每一行数据的唯一性

2：大大加快表的检索速度，是创建索引的主要原因

3：加速表与表之间的链接，特别是在实现数据的参照完整性方面特别有意义

4：在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间

5：使用索引，可以在查询的过程中使用优化隐藏器，提高系统性能

缺点：

1：索引占用磁盘空间，除了数据表要占用数据空间之外，每个索引还要占用一定的物理空间，如果要建立聚簇索引，需要的空间就更大

2：对于要写入的表，如，insert，update，delete操作，索引会降低他们的速度，这是因为不仅要把改动数据写入数据文件，还要把改动写入索引文件

3：索引也要动态维护，创建索引和维护索引要消耗时间，这种时间随数据量的增加而增加，降低了数据的维护速度

特点：

1：

分类：

按记录存储顺序分：聚集索引和非聚集索引

聚集索引：是一种指明了数据物理存储顺序的索引，行的物理存储顺序与索引顺序完全相同，

非聚集索引：非聚集索引不用将物理数据页的数据按列排列，非聚集索引的叶节点存储了组成非聚集索引的关键字值和行定位器，非聚集索引不会影响数据表中记录的实际存储顺序，仅仅记录指向表中行位置的指针，

索引默认为：非聚集索引，可以建多个

一般聚集索引用于范围搜索，是表数据的实际存储顺序，一个表只能建一个聚集索引哦！

按索引行是否有相同值分为：普通索引，唯一索引

普通索引：两行可以有相同的索引值

唯一索引：两行不能有相同的索引值

按字段数分为：简单索引和复合索引

简单索引：基于一个字段的索引

复合索引：基于多个字段的索引，他们也可同时为，唯一索引

按数据库对象分：表索引，视图索引

建索引的场合：

1：有主键时

2：频繁搜索或使用列时

3：字段数据更新频率较低，查询使用频率较高且存储大量重复值时，建议使用聚簇索引

4：经常同时存取多列且每列都含有重复值时，建议使用组合索引

---不建索引

5：很少或从不在查询中使用的列

6：行数很少的列

作者 zqs520

篇7：B+树索引

在数据库中B+树的高度一般都在2～3层，也就是对于查找某一键值的行记录，最多只需要2到3次的IO，

B+树索引

。

InnoDB存储引擎表是索引组织表，即表中数据按照主键顺序存放。而聚集索引就是按照每张表的主键构造一颗B+树，并且叶子节点存放整张表的行记录数据，因此也让聚集索引的叶子节点成为数据页，聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。同B+树结构一样，每个数据页都是通过一个双向链表来进行链接。

聚集索引的另一个好处是，它的语言主键的排序查找和范围查找速度非常快。

辅助索引：叶子节点不包含行的全部数据。叶子节点除了包含键值以外，每个叶级别中的索引行还包含一个书签，该书签用来告诉InnoDB存储引擎，哪里可以找到与索引相对应行的数据。

篇8：MySQL 索引详解

一、单列索引和组合索引（也叫复合索引）的选择效率问题

先阐述下单列索引和组合索引的概念：

单列索引：即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引，

组合索引：即一个索包含多个列。

如果我们的查询where条件只有一个，我们完全可以用单列索引，这样的查询速度较快，索引也比较瘦身。如果我们的业务场景是需要经常查询多个组合列，不要试图分别基于单个列建立多个单列索引。这是因为当SQL语句所查询的列，全部都出现在复合索引中时，此时由于只需要查询索引块即可获得所有数据，当然比使用多个单列索引要快得多。下面以实际例子说明：

举例：

以下是代码片段：

CREATE TABLE people ( peopleid SMALLINT NOT NULL AUTO_INCREMENT, firstname CHAR(50) NOT NULL, lastname CHAR(50) NOT NULL, age SMALLINT NOT NULL, townid SMALLINT NOT NULL, PRIMARY KEY (peopleid) );

下面是我们插入到这个people表的数据：

这个数据片段中有四个名字为“Mikes”的人(其中两个姓Sullivans，两个姓McConnells)，有两个年龄为17岁的人，还有一个名字与众不同的Joe Smith。

这个表的主要用途是根据指定的用户姓、名以及年龄返回相应的peopleid。例如，我们可能需要查找姓名为Mike Sullivan、年龄17岁用户的peopleid(SQL命令为SELECT peopleid FROM people WHERE firstname=“Mike” AND lastname=“Sullivan” AND age=17;)。由于我们不想让MySQL每次执行查询就去扫描整个表，这里需要考虑运用索引。

首先，我们可以考虑在单个列上创建索引，比如firstname、lastname或者age列。如果我们创建firstname列的索引(ALTER TABLE people ADD INDEX firstname (firstname);)，MySQL将通过这个索引迅速把搜索范围限制到那些firstname=“Mike”的记录，然后再在这个“中间结果集”上进行其他条件的搜索：它首先排除那些lastname不等于“Sullivan”的记录，然后排除那些age不等于17的记录。当记录满足所有搜索条件之后，MySQL就返回最终的搜索结果。

由于建立了firstname列的索引，与执行表的完全扫描相比，MySQL的效率提高了很多，但我们要求MySQL扫描的记录数量仍旧远远超过了实际所需要的。虽然我们可以删除firstname列上的索引，再创建lastname或者age列的索引，但总地看来，不论在哪个列上创建索引搜索效率仍旧相似。

为了提高搜索效率，我们需要考虑运用多列索引。如果为firstname、lastname和age这三个列创建一个多列索引，MySQL只需一次检索就能够找出正确的结果!下面是创建这个多列索引的SQL命令：

以下是代码片段：

ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age);

由于索引文件以B+树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录!

那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。

二、谨防最左前缀索引失效问题

继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。它相当于我们创建了(firstname，lastname，age)、(firstname，lastname)以及(firstname)这些列组合上的索引。为什么没有 (lastname,age)等这样的组合索引呢？这是因为 mysql 组合索引“最左前缀”（Leftmost Prefixing）的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引。

以下是代码片段：

The following queries can use theLeftmost Prefixingindex:

SELECT peopleid FROM people WHERE firstname=“Mike” AND lastname=“Sullivan” AND age=“17”;

SELECT peopleid FROM people WHERE firstname=“Mike” AND lastname=“Sullivan”;

SELECT peopleid FROM people WHERE firstname=“Mike”;

The following queries cannot use the Leftmost Prefixing index at all:

SELECT peopleid FROM people WHERE lastname=“Sullivan”;

SELECT peopleid FROM people WHERE age=“17”;

SELECT peopleid FROM people WHERE lastname=“Sullivan” AND age=“17”;

这里我特地实践了下：

执行结果如下：

可以看出这里最左前缀索引失效了。这里没有用到索引直接全表扫描了。

我们再看下如果这样呢？

执行结果如下：

可见还是用到了索引，不是应该失效吗？是不是有点迷糊了？

特地请教了DBA玄惭大师，这里只是最左前缀索引失效，但是不代表整个索引失效，只是效率没有那么高了。最左前缀索引的效率是比较高的。本来我误以为只要第一个查询字段不是组合索引的最左前缀索引字段整个索引会失效，其实不然。

这里强调下只是最有效率的最左前缀索引失效不是整个索引失效。

三、使用explain分析索引

在不确定应该在哪些数据列上创建索引的时候，我们可以从EXPLAIN SELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键字，MySQL将不是去执行那条SELECT命令，而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引(如果有的话)等信息列出来。这里我基本阐述下每个信息字段含义，不展开阐述，我们只要注意几个关键点（关键点以下用红色加粗显示）能大概看懂即可呵呵~~

1.id:SQL执行的顺利的标识。

sql从里向外执行，通过以上观察发现sql是按照id从大到小执行的，

2.select_type:SELECT类型

1)简单SELECT(不使用UNION或子查询等)

2)PRIMARY：最外层的select

3）DERIVED：派生表的SELECT(FROM子句的子查询)

4）UNION：UNION中的第二个或后面的SELECT语句

5）UNION RESULT：UNION的结果。

6）DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询

7）SUBQUERY：子查询中的第一个SELECT

8）DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询

PS:这里我总结了下子查询的in语句会用到DEPENDENT关键字，如果子查询是union则是DEPENDENT UNION；如果子查询是简单的条件语句则是DEPENDENT SUBQUERY。这里不一定准确是我自己总结的哈~~如果不对望指正

3.table：表的名字。

有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)

4.type：连接操作的类型。

这列很重要,显示了连接使用了哪种类别,有无使用索引。在各种类型的关联关系当中，效率最高的是system，然后依次是const、eq_ref、ref、range、index和 All。一般来说，得保证查询至少达到range级别，最好能达到ref，否则就可能会出现性能问题。

1）system

表只有一行：system表。这是const连接类型的特殊情况

2）const

表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待

3）eq_ref

在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用

4）ref

这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少（越少越好）

5）range

这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况>

6）index

这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）

7）ALL

这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免。因为它要扫描整个表。你可以加入更多的索引来解决这个问题。

5.possible_keys：MySQL在搜索数据记录时可以选用的各个索引的名字。

这里的索引名字是创建索引时指定的索引昵称;如果索引没有昵称，则默认显示的是索引中第一个列的名字(在上一节举的例子中是“firstname”)。默认索引名字的含义往往不是很明显。

6.key：它显示了MySQL实际使用的索引的名字。

key数据列是MySQL实际选用的索引，如果它为空(或NULL)，则MySQL不使用索引。

7.key_len：索引中被使用部分的长度，以字节计。

key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。在上例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节（smallint存储大小为2字节）。如果MySQL只使用索引中的firstname部分，则key_len将是50。在不损失精确性的情况下，key_len数据列里的值越小越好(意思是更快)。

8.ref：显示使用哪个列或常数与key一起从表中选择行。

ref数据列给出了关联关系中另一个数据表里的数据列的名字。

9.rows：MySQL所认为的它在找到正确的结果之前必须扫描的记录数。

显然，这里最理想的数字就是1。

10.extra：附加信息

Using index和Using where会遇到的比较多，可以重点记下，其他的我没怎么遇到过了解即可，遇到具体问题可以查阅哈

1）Distinct

一旦MYSQL找到了与行相联合匹配的行，就不再搜索了

2）Not exists

MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了

3）Range checked for each

没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一

4）Using filesort

看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行

5）Using index

列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候

6）Using temporary

看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上

7）Using where

使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题

先说到这，下面一篇给大家总结下如何选择索引列以及使用索引的注意事项。

REF：

www.taobaotest.com/blogs/2395

www.taobaotest.com/blogs/2410

MySQL索引分析和优化

MySQL EXPLAIN 详解

篇9：数据库索引的使用方法

走向精通MySQL的道路非常的艰难，还好各种关系型数据库大同小异，足够让我从增删改查上升到高性能数据库的架构和调优。这期间的各种概念就不絮叨了，我也很难表述的很清楚，昨天写了个小脚本往我本机MySQL数据库的某张表里面注入了200万条数据(Windows7旗舰版/1.66GHz/2G内存/MySQL5.1.50)，数据表的结构如下图所示，属于一个比较基本的定长表，考虑到我可怜的本本的承受能力，id使用从1开始的自增，title字段为随机20个标题中的一个，content都是相同的内容，time使用时间戳而非datetime类型，即10位整型数据。

就是这么一个结构极其简单的表，200万数量级的复杂查询将会变的非常缓慢，比如执行下面的SQL语句。

SELECT a.id,FROM_UNIXTIME(a.time)

FROM article AS a

WHERE a.title=‘PHP笔试题和答案――基础语言方面’

查询时间基本上需要50-100秒，这个是非常恐怖的，如果加上联合查询和其他一些约束条件，数据库会疯狂的消耗内存。

如果这时候数据库里面针对title字段建立了索引，查询效率将会大幅度提升，如下图所示。可见对于大型数据库，建立索引是非常非常重要的一个优化手段(当然还会有很多其他优化这样的数据库的方法，但是本文主题所限，暂不讨论。)，废话了这么多，以下开始总结MySQL中索引的使用方法和性能优化以及一些注意事项。

索引的概念

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。更通俗的说，数据库索引好比是一本书前面的目录，能加快数据库的查询速度。上述SQL语句，在没有索引的情况下，数据库会遍历全部200条数据后选择符合条件的;而有了相应的索引之后，数据库会直接在索引中查找符合条件的选项。如果我们把SQL语句换成“SELECT * FROM article WHERE id=2000000”，那么你是希望数据库按照顺序读取完200万行数据以后给你结果还是直接在索引中定位呢?上面的两个图片鲜明的用时对比已经给出了答案(注：一般数据库默认都会为主键生成索引)。

索引分为聚簇索引和非聚簇索引两种，聚簇索引是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了;聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。

索引的类型

1. 普通索引

这是最基本的索引，它没有任何限制，比如上文中为title字段创建的索引就是一个普通索引。

C直接创建索引

CREATE INDEX indexName ON table(column(length))

C修改表结构的方式添加索引

ALTER tableADD INDEX indexName ON (column(length))

C创建表的时候同时创建索引

CREATE TABLE `table` (

`id` int(11) NOT NULL AUTO_INCREMENT ,

`title` 255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,

`time` int(10) NULL DEFAULT NULL ,

PRIMARY KEY (`id`),

INDEX indexName (title(length))

)

C删除索引

DROP INDEX indexName ON table

2. 唯一索引

与普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值(注意和主键不同)。如果是组合索引，则列值的组合必须唯一，创建方法和普通索引类似。

C创建唯一索引

CREATE UNIQUE INDEX indexName ON table(column(length))

C修改表结构

ALTER table ADD UNIQUE indexName ON (column(length))

C创建表的时候直接指定

CREATE TABLE `table` (

`id` int(11) NOT NULL AUTO_INCREMENT ,

`title` 255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,

`time` int(10) NULL DEFAULT NULL ,

PRIMARY KEY (`id`),

UNIQUE indexName (title(length))

);

3. 全文索引(FULLTEXT)

MySQL从3.23.23版开始支持全文索引和全文检索，FULLTEXT索引仅可用于 MyISAM 表;他们可以从CHAR、VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或CREATE INDEX被添加。////对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引，其速度比把资料输入现有FULLTEXT索引的速度更为快。不过切记对于大容量的数据表，生成全文索引是一个非常消耗时间非常消耗硬盘空间的做法。

C创建表的适合添加全文索引

CREATE TABLE `table` (

`id` int(11) NOT NULL AUTO_INCREMENT ,

`title` 255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,

`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,

`time` int(10) NULL DEFAULT NULL ,

PRIMARY KEY (`id`),

FULLTEXT (content)

);

C修改表结构添加全文索引

ALTER TABLE article ADD FULLTEXT index_content(content)

C直接创建索引

CREATE FULLTEXT INDEX index_content ON article(content)

4. 单列索引、多列索引

多个单列索引与单个多列索引的查询效果不同，因为执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引。

5. 组合索引(最左前缀)

平时用的SQL查询语句一般都有比较多的限制条件，所以为了进一步榨取MySQL的效率，就要考虑建立组合索引。例如上表中针对title和time建立一个组合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。建立这样的组合索引，其实是相当于分别建立了下面两组组合索引：

Ctitle,time

Ctitle

为什么没有time这样的组合索引呢?这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这两列的查询都会用到该组合索引，如下面的几个SQL所示：

C使用到上面的索引

SELECT * FROM article WHREE title=“PHP程序员” AND time=1234567890

SELECT * FROM article WHREE utitle=“PHP程序员”

C不使用上面的索引

SELECT * FROM article WHREE time=1234567890

MySQL索引的优化

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。下面是一些总结以及收藏的MySQL索引的注意事项和优化方法。

1. 何时使用聚集索引或非聚集索引?

动作描述使用聚集索引使用非聚集索引列经常被分组排序使用使用返回某范围内的数据使用不使用一个或极少不同值不使用不使用小数目的不同值使用不使用大数目的不同值不使用使用频繁更新的列不使用使用外键列使用使用主键列使用使用频繁修改索引列不使用使用

事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询1月1日至2010月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可;而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。其实这个具体用法我还不是很理解，只能等待后期的项目开发中慢慢学学了。

2. 索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

3. 使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

4. 索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

5. like语句操作

一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

6. 不要在列上进行运算

例如：select * from users where YEAR(adddate)<2007，将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成：select * from users where adddate<’2007-01-01′。关于这一点可以围观：一个单引号引发的MYSQL性能损失。

最后总结一下，MySQL只对一下操作符才使用索引：<,<=,=,>,>=,between,in,以及某些时候的like(不以通配符%或_开头的情形)。而理论上每张表里面最多可创建16个索引，不过除非是数据量真的很多，否则过多的使用索引也不是那么好玩的，比如我刚才针对text类型的字段创建索引的时候，系统差点就卡死了。

最后的最后PS：现在更新个技术文章真难，还得做大量实验…

[数据库索引的使用方法]

篇10：分区索引（二）本地分区索引

可以使用与表相同的分区键和范围界限来对本地索引分区，每个本地索引的分区只包含了它所关联的表分区的键和ROWID。本地索引可以是B树或位图索引。如果是B树索引，它可以是唯一或不唯一的索引。

这种类型的索引支持分区独立性，这就意味着对于单独的分区，可以进行增加、截取、删除、分割、脱机等处理，而不用同时删除或重建索引。Oracle自动维护这些本地索引。本地索引分区还可以被单独重建，而其他分区不会受到影响。

（1）有前缀的索引

有前缀的索引包含了来自分区键的键，并把它们作为索引的前导。例如，让我们再次回顾participant表。在创建该表后，使用survey_id和survey_date这两个列进行范围分区，然后在survey_id列上建立一个有前缀的本地索引。这个索引的所有分区都被等价划分，就是说索引的分区都使用表的相同范围界限来创建。

技巧：本地的有前缀索引可以让Oracle快速剔除一些不必要的分区。也就是说没有包含WHERE条件子句中任何值的分区将不会被访问，这样也提高了语句的性能。

（2）无前缀的索引

无前缀的索引并没有把分区键的前导列作为索引的前导列。若使用有同样分区键(survey_id和survey_date)的相同分区表，建立在survey_date列上的索引就是一个本地的无前缀索引。可以在表的任一列上创建本地无前缀索引，但索引的每个分区只包含表的相应分区的键值。

如果要把无前缀的索引设为唯一索引，这个索引就必须包含分区键的子集。在这个例子中，我们必须把包含survey 和(或)survey_id 的列进行组合(只要survey_id不是索引的第一列，它就是一个有前缀的索引)。

技巧：对于一个唯一的无前缀索引，它必须包含分区键的子集。

（3）注意事项：

1)局部索引一定是分区索引，分区键等同于表的分区键。

2)前缀和非前缀索引都可以支持索引分区消除，前提是查询的条件中包含索引分区键。

3)局部索引只支持分区内的唯一性，无法支持表上的唯一性，因此如果要用局部索引去给表做唯一性约束，则约束中必须要包括分区键列。

4)局部分区索引是对单个分区的，每个分区索引只指向一个表分区；全局索引则不然，一个分区索引能指向n个表分区，同时，一个表分区，也可能指向n个索引分区，对分区表中的某个分区做truncate 或者move，shrink等，可能会影响到n个全局索引分区，正因为这点，局部分区索引具有更高的可用性。

5)位图索引必须是局部分区索引。

6)局部索引多应用于数据仓库环境中。

（4）示例：

sql>create index ix_custaddr_local_id on custaddr(id) local;

索引已创建。

和下面SQL 效果相同，因为local索引就是分区索引：

create index ix_custaddr_local_id_p on custaddr(id)

local (

partition t_list556 tablespace icd_service,

partition p_other tablespace icd_service

)

SQL>create index ix_custaddr_local_areacode on custaddr(areacode) local;

索引已创建，

验证2个索引的类型：

SQL> select index_name,table_name,partitioning_type,locality,ALIGNMENT from

user_part_indexes where table_name='CUSTADDR';

index_name table_name partition locali alignment

------------------------------ ---------- --------- ------ ------------

ix_custaddr_local_areacode custaddr list local prefixed

ix_custaddr_local_id custaddr list local non_prefixed

因为我们的custaddr 表是按areacode 进行分区的，所以索引ix_custaddr_local_areacode 是有前缀的索引（prefixed）。而 ix_custaddr_local_id是非前缀索引。

篇11：SEO倒叙索引术语

文档（document）：一般搜索引擎的处理对象是互联网网页，而文档这个概念要更宽些，代表以文本形式存在的存储对象，相比网页来说涵盖更多的形式。例如word、html、pdf等都的hi文档，甚至包括微博、微信等也可以称作是文档。

文档集合（document collection）：由若干文档构成的集合成为文件集合。比如海量的互联网网页的集合或者说是大量的电子邮件，都是文档的集合的具体例子。

文档编号（document ID）：在搜索引擎内部，会为文档集合内每个文档赋予一个唯一的一个内部编号，以此编号来作为这个文档唯一标识，这样方便内部处理。每个文档的内部编号即称为文档编号。

单词编号（word ID）：与文档编号类似，搜索引擎内部唯一编号来表示某个单词，单词的编号可以作为某个单词的唯一表征，

倒叙索引（inverted index）：倒叙索引是实现单词－文档矩阵的一种具体存储形式。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒叙索引主要由两个部分组成：单词词典和倒叙文件。

单词词典（lexicon）：搜索引擎通常的索引单位是单词，单词词典是由文档集合中出现过的所有电磁构成的字符串集合，单词词典内每条索引项记载单词本身一些信息及指向倒排列表指针。

倒排列表（postinglist）：倒排列表记载了出现过某个单词的所有文档的列表及单词在该文档中出现的位置信息，每条记录成为一个倒排项。根据倒排列表，即可获知哪些文档包含某个单词。

倒排文件（inverted file）：所有单词的倒排列表往往顺序地存储在磁盘的某个文件里。

篇12：oracle数据库索引失效

这篇文章主要介绍了oracle数据库索引失效的原因及如何避免索引失效，有需要的小伙伴参考下，

今天一个同事突然问我索引为什么失效。说实在的，失效的原因有多种：

但是如果是同样的sql如果在之前能够使用到索引，那么现在使用不到索引，以下几种主要情况:

1. 随着表的增长，where条件出来的数据太多，大于15%，使得索引失效（会导致CBO计算走索引花费大于走全表）

2. 统计信息失效需要重新搜集统计信息

3. 索引本身失效需要重建索引

下面是一些不会使用到索引的原因

索引失效

1) 没有查询条件，或者查询条件没有建立索引

2) 在查询条件上没有使用引导列

3) 查询的数量是大表的大部分，应该是30％以上。

4) 索引本身失效

5) 查询条件使用函数在索引列上（见12）

6) 对小表查询

7) 提示不使用索引

8) 统计数据不真实

9) CBO计算走索引花费过大的情况。其实也包含了上面的情况，这里指的是表占有的block要比索引小。

10)隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误. 由于表的字段tu_mdn定义为varchar2(20),

但在查询时把该字段作为number类型以where条件传给Oracle,这样会导致索引失效.

错误的例子：select * from test where tu_mdn=13333333333;

正确的例子：select * from test where tu_mdn=‘13333333333‘;

11)对索引列进行运算导致索引失效,我所指的对索引列进行运算包括(+，-，*，/，! 等)

错误的例子：select * from test where id-1=9;

正确的例子：select * from test where id=10;

12)使用Oracle内部函数导致索引失效.对于这样情况应当创建基于函数的索引.

错误的例子：select * from test where round(id)=10;

说明，此时id的索引已经不起作用了正确的例子：首先建立函数索引，

create index test_id_fbi_idx on test(round(id));

然后 select * from test where round(id)=10; 这时函数索引起作用了 1, 2,单独的>,<,(有时会用到，有时不会)

3,like “%_” 百分号在前.

4,表没分析.

5,单独引用复合索引里非第一位置的索引列.

6,字符型字段为数字时在where条件里不添加引号.

7,对索引列进行运算.需要建立函数索引.

8,not in ,not exist.

9,当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况，

10, 索引失效。

11,基于cost成本分析(oracle因为走全表成本会更小)：查询小表,或者返回值大概在10%以上

12,有时都考虑到了但就是不走索引,drop了从建试试在

13,B-tree索引 is null不会走,is not null会走,位图索引 is null,is not null 都会走

14,联合索引 is not null 只要在建立的索引列（不分先后）都会走,

in null时必须要和建立索引第一列一起使用,当建立索引第一位置条件是is null 时,

其他建立索引的列可以是is null（但必须在所有列都满足is null的时候）,

或者=一个值；当建立索引的第一位置是=一个值时,其他索引列可以是任何情况（包括is null =一个值）,

以上两种情况索引都会走。其他情况不会走。

篇13：创建索引组织表

索引组织表（IOT）不仅可以存储数据，还可以存储为表建立的索引，索引组织表的数据是根据主键排序后的顺序进行排列的，这样就提高了访问的速度。但是这是由牺牲插入和更新性能为代价的（每次写入和更新后都要重新进行重新排序）。

索引组织表的创建格式如下：

create table indexTable（

ID varchar2 （ 10 ），

NAME varchar2 （ 20 ），

constraint pk_id primary key （ ID ）

）

organization index ;式

注意两点：

● 创建IOT时，必须要设定主键，否则报错。

● 索引组织表实际上将所有数据都放入了索引中。

索引组织表属性

1、OVERFLOW子句（行溢出）

因为所有数据都放入索引，所以当表的数据量很大时，会降低索引组织表的查询性能。此时设置溢出段将主键和溢出数据分开来存储以提高效率。溢出段的设置有两种格式：

PCTTHRESHOLD n :制定一个数据块的百分比，当行数据占用大小超出时，该行的其他列数据放入溢出段

INCLUDING column_name :指定列之前的列都放入索引块，之后的列都放到溢出段

● 当行中某字段的数据量无法确定时使用PCTTHRESHOLD.

● 若所有行均超出PCTTHRESHOLD规定大小，则考虑使用INCLUDING.

create table t88（

ID varchar2 （ 10 ），

NAME varchar2 （ 20 ），

constraint pk_id primary key （ ID ）

）

organization index

PCTTHRESHOLD 20

overflow tablespace users

INCLUDING name ;

● 如上例所示，name及之后的列必然被放入溢出列，而其他列根据 PCTTHRESHOLD 规则。

2、COMPRESS子句（键压缩）

与普通的索引一样，索引组织表也可以使用COMPRESS子句进行键压缩以消除重复值，

具体的操作是，在organization index之后加上COMPRESS n子句

● n的意义在于：指定压缩的列数。默认为无穷大。

例如对于数据（1,2,3）、（1,2,4）、（1,2,5）、（1,3,4）、（1,3,5）时

若使用COMPRESS则会将重复出现的（1,2）、（1,3）进行压缩

若使用COMPRESS 1时，只对数据（1）进行压缩

索引组织表的维护

索引组织表可以和普通堆表一样进行INSERT、UPDATE、DELETE、SELECT操作。

可使用ALTER TABLE … OVERFLOW语句来更改溢出段的属性。

altertable t88 addoverflow; --新增一个overflow

● 要ALTER任何OVERVIEW的属性，都必须先定义overflow,若建表时没有可以新增

altertable t88 pctthreshold15includingname; --调整overflow的参数

altertable t88 initrans2overflowinitrans4; --修改数据块和溢出段的initrans特性

● 关于initrans的概念参考 space.itpub.net/265709/viewspace-166534

索引组织表的应用

Heap Table 就是一般的表，获取表中的数据是按命中率来得到的。没有明确的先后之分，在进行全表扫描的时候，并不是先插入的数据就先获取。数据的存放也是随机的，当然根据可用空闲的空间来决定。

IOT 就是类似一个全是索引的表，表中的所有字段都放在索引上，所以就等于是约定了数据存放的时候是按照严格规定的，在数据插入以前其实就已经确定了其位置，所以不管插入的先后顺序，它在那个物理上的那个位置与插入的先后顺序无关。这样在进行查询的时候就可以少访问很多blocks,但是插入的时候，速度就比普通的表要慢一些。

适用于信息检索、空间和OLAP程序。

索引组织表的适用情况：

1、代码查找表。

2、经常通过主码访问的表。

3、构建自己的索引结构。

4、加强数据的共同定位，要数据按特定顺序物理存储。

5、经常用between…and…对主码或唯一码进行查询。数据物理上分类查询。如一张订单表，按日期装载数据，想查单个客户不同时期的订货和统计情况。

经常更新的表当然不适合IOT,因为oracle需要不断维护索引，而且由于字段多索引成本就大。

如果不是经常使用主键访问表，就不要使用IOT

篇14：如何手动重建 Spotlight 索引

你是否需要重建整个 Mac 系统的 Spotlight 索引?这很简单，虽然重建索引本身会需要一些时间，下面告诉大家如何手动重建索引：

打开系统偏好设置:点选“Spotlight”，选择“隐私”。将 Mac OS X 所在的系统磁盘拖拽进去(或其他所需磁盘)

如果弹出确认框，点选“好”，

现在，选中刚刚添加的磁盘，并点按“-”将其从列表中移除

注意：如果将某个目录或磁盘拖进了“隐私”列表，该目录或磁盘下的所有内容将完全从 Spotlight 索引中排除。

接下来 Spotlight 就会立刻开始重新索引刚才所操作的磁盘了。索引所需时长取决于磁盘上内容的多少。在 Spotlight 菜单中可以看到进度和剩余时间。任何时候都可以来检查进度。同时，在索引重建期间，电脑速度可能也会多少受到影响，因为 mdworker 和 mds 进程会消耗 CPU 资源并进行大量磁盘操作。

篇15：oraclebtreeindex索引块结构初探

通过treedump查看索引结构

语法格式：alter session set events 'immediate trace name treedump level index_object_id'

SQL>create table t1(c1 varchar2(10));表已创建，

oraclebtreeindex索引块结构初探

。SQL>create index i1 on t1(c1);索引已创建。SQL>select object_id from user_objects where object_name='I1'; OBJECT_ID---------- 364492SQL>alter session set events 'immediate trace name treedump level 364492';

trace file 内容：

branch: 0xb0ae6ac 185263788 (0: nrow: 2, level: 2) branch: 0xb11227c 185672316 (-1: nrow: 460, level: 1)leaf: 0xb0ae6ad 185263789 (-1: nrow: 317 rrow: 317)leaf: 0xb112153 185672019 (0: nrow: 295 rrow: 295)leaf: 0xb0ae82f 185264175 (1: nrow: 281 rrow: 281)...leaf: 0xb11211e 185671966 (457: nrow: 334 rrow: 334)leaf: 0xb0ae83c 185264188 (458: nrow: 338 rrow: 338) branch: 0xb112280 185672320 (0: nrow: 454, level: 1)leaf: 0xb112127 185671975 (-1: nrow: 303 rrow: 303)leaf: 0xb0ae6d6 185263830 (0: nrow: 304 rrow: 304)leaf: 0xb112165 185672037 (1: nrow: 300 rrow: 300)...leaf: 0xb0ae810 185264144 (451: nrow: 398 rrow: 398)leaf: 0xb112143 185672003 (452: nrow: 401 rrow: 401)----- end tree dump

块的类别：分支块和叶子块块的rdba地址：十六进制和十进制

相对于上一级块结构的位置，从-1开始，root块从 0开始

nrows: 所有的记录数量（包括已删除的）

rrows: 当前包含的记录数量

level : 分支块的级别，叶子节点隐式为0

注意：oracle的btree index几乎总是平衡的。

怎样获取索引块的地址信息

oracle为我们提供了两个视图：dba_segments dba_extents. 通过这两个视图，我们可以查询索引的root块地址.

SQL>l 1* select tablespace_name,segment_space_management from dba_tablespaces where tablespace_name in ('TS1','USERS')SQL>/TABLESPACE_NAME SEGMEN------------------------------ ------TS1 MANUALUSERS AUTOSQL>col segment_name for a20SQL>col tablespace_name for a20SQL>select segment_name,tablespace_name,header_file,header_block from dba_segments where wner='EASYPOINT' and segment_name like 'I%' 2 /SEGMENT_NAME TABLESPACE_NAMEHEADER_FILE HEADER_BLOCK-------------------- -------------------- ----------- ------------I1 USERS 44 714411I2 TS1 46 17SQL>select segment_name,min(extent_id),min(block_id) from dba_extents where wner='EASYPOINT' and segment_name like 'I%' group by segment_name;SEGMENT_NAME MIN(EXTENT_ID) MIN(BLOCK_ID)-------------------- -------------- -------------I2 017I1 0 714409SQL>SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(192938002) FROM DUAL;DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(192938002)------------------------------------------------ 18SQL>SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(185263788) FROM DUAL;DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(185263788)------------------------------------------------714412

从这个地方我们可以看出，root索引块的地址为dba_segments 中 header_block加1，在ASSM下，首extent的前2个数据块保存位图信息，第三个数据块为header_block. 在mssm下，首extents的第一个数据块即为HEADER_BLOCK.

查看索引块信息

语法格式：alter system dump datafile file_id block block_id; alter system dump datafile file_id block min block_id block max block_id;

dump root branch：

SQL>select dbms_utility.data_block_address_block(185263788) c1,dbms_utility.data_block_address_file(185263788) c2 from dual;C1 C2-------- -------- 714412 44SQL>oradebug setmypid已处理的语句SQL>oradebug tracefile_name/oracle/admin/orcl/udump/orcl_ora_73926.trcSQL>alter system dump datafile 44 block 714412;系统已更改。

trace file 内容

*** 2013-12-13 11:52:38.766Start dump data blocks tsn: 4 file#: 44 minblk 714412 maxblk 714412buffer tsn: 4 rdba: 0x0b0ae6ac (44/714412)scn: 0x0012.4a18d046 seq: 0x01 flg: 0x06 tail: 0xd0460601frmt: 0x02 chkval: 0xacfe type: 0x06=trans dataHex dump of block: st=0, typ_found=1Dump of memory from 0x0000000110432000 to 0x0000000110434000110432000 06A20000 0B0AE6AC 4A18D046 00120106 [........J..F....]110432010 ACFE0000 02030022 00058FCC 4A18D044 [.......“....J..D]110433FB0 024846FE 0B0AE6AF 02545AFE 0B112280 [.HF......TZ...”.]110433FC0 024E4BFE 31322F31 32303639 07787005 [.NK.12/12069.xp.]110433FD0 19101A35 272F6F72 61636C65 2F61646D [...5'/oracle/adm]110433FE0 696E2F6F 72636C2F 6264756D 702F616C [in/orcl/bdump/al]110433FF0 6572745F 6F72636C 2E6C6F67 D0460601 [ert_orcl.log.F..]Block header dump: 0x0b0ae6ac Object id on Block? Y seg/obj: 0x58fcc csc: 0x12.4a18d044 itc: 1 flg: E typ: 2 - INDEX brn: 0 bdba: 0xb0ae6a9 ver: 0x01 opc: 0 inc: 0 exflg: 0 Itl XidUba Flag Lck Scn/Fsc0x01 0x0006.006.000492f3 0x008130ca.aee2.01 -BU- 1 fsc 0x0000.4a18d046 Branch block dump=================header address 4567801932=0x11043204ckdxcolev 2KDXCOLEV Flags = - - -kdxcolok 1kdxcoopc 0x83: pcode=3: iot flags=--- is converted=Ykdxconco 2kdxcosdc 2kdxconro 1kdxcofbo 30=0x1ekdxcofeo 8048=0x1f70kdxcoavs 8018--kdxbrlmc 185672316=0xb11227ckdxbrsno 491kdxbrbksz 8056 kdxbr2urrc 0--row#0[8048] dba: 185672320=0xb112280col 0; len 2; (2): 4e 4bcol 1; TERM----- end of branch block dump -----End dump data blocks tsn: 4 file#: 44 minblk 714412 maxblk 714412

dump leaf block：

SQL>SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(185263789) FROM DUAL;DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(185263789)------------------------------------------------714413SQL>alter system dump datafile 44 block 714413;系统已更改。

tracefile 内容：

*** 2013-12-13 12:20:29.107Start dump data blocks tsn: 4 file#: 44 minblk 714413 maxblk 714413buffer tsn: 4 rdba: 0x0b0ae6ad (44/714413)scn: 0x0012.4a19790f seq: 0x01 flg: 0x06 tail: 0x790f0601frmt: 0x02 chkval: 0xcff9 type: 0x06=trans dataHex dump of block: st=0, typ_found=1Dump of memory from 0x0000000110432000 to 0x0000000110434000110432000 06A20000 0B0AE6AD 4A19790F 00120106 [........J.y.....]110432010 CFF90000 02000000 00058FCC 4A19790E [............J.y.]110432020 00120058 00023200 0B0AE6A9 00060000 [...X..2.........]110432030 00049288 008128AC AEE10100 C0000012 [......(.........]...110433FB0 E8BB01CC 00000641 41565A4F 45060B0A [.......AAVZOE...]110433FC0 E74200A1 0717021C 3C020F02 C10602C1 [.B......<.......]110433FD0 120D7871 0B081701 0B21A1DD 001C3C02 [..xq.....!....<.]110433FE0 C10B02C1 0B018001 80018001 80FFFF01 [................]110433FF0 800180FF 0778710B 0717021C 790F0601 [.....xq.....y...]Block header dump: 0x0b0ae6ad Object id on Block? Y seg/obj: 0x58fcc csc: 0x12.4a19790e itc: 2 flg: E typ: 2 - INDEX brn: 0 bdba: 0xb0ae6a9 ver: 0x01 opc: 0 inc: 0 exflg: 0 Itl XidUba Flag Lck Scn/Fsc0x01 0x0006.000.00049288 0x008128ac.aee1.01 CB-- 0 scn 0x0012.4a184c240x02 0x0008.025.0003bd64 0x00813810.8882.06 --U- 1 fsc 0x0000.4a19790f Leaf block dump===============header address 4567801956=0x110432064kdxcolev 0KDXCOLEV Flags = - - -kdxcolok 0kdxcoopc 0x80: pcode=0: iot flags=--- is converted=Ykdxconco 2kdxcosdc 10kdxconro 317kdxcofbo 670=0x29ekdxcofeo 2960=0xb90kdxcoavs 2290kdxlespl 0kdxlende 0kdxlenxt 185672019=0xb112153kdxleprv 0=0x0kdxledsz 0kdxlebksz 8032row#0[3712] flag: ------, lock: 0, len=16col 0; len 6; (6): 41 41 41 42 43 53col 1; len 6; (6): 0b 11 22 f9 00 95row#1[4464] flag: ------, lock: 0, len=16col 0; len 6; (6): 41 41 41 43 47 4ccol 1; len 6; (6): 0b 0a e8 94 00 20...row#315[8000] flag: ------, lock: 0, len=16col 0; len 6; (6): 41 41 56 58 58 44col 1; len 6; (6): 0b 0a e8 bb 01 ccrow#316[8016] flag: ------, lock: 0, len=16col 0; len 6; (6): 41 41 56 5a 4f 45col 1; len 6; (6): 0b 0a e7 42 00 a1----- end of leaf block dump -----End dump data blocks tsn: 4 file#: 44 minblk 714413 maxblk 714413

tracefile格式解析：

块头区域：

rdba:相对数据块地址

scn : 修改块的最后scn号

seq: 在当前scn号下，数据块改变的次序

tail: scn的最后两个字节

frmt: 数据块的格式 (02 represents a post Oracle8 block format, A2 10g format)

chkval: 校验和

type: 06 C transactional data block type (table/index/cluster)

Hex dump of block: only displayed on later versions of Oracle

seg/obj C object id

csc: commit/cleanout SCN

itc: interested transaction count (defaults 1 branch block, 2 leaf blocks)

typ C block type (2 C index)

Itl C Interested Transaction Location:

Itl: slot id,

Xid: transaction id,

Uba: undo block address,

Flag : state of current transaction (C C Committed)

Lck : number of locks help by current transaction

Scn/Fsc: scn /fsc of current transaction

kdxcolev: index level (0 represents leaf blocks)

kdxcolok: denotes whether structural block transaction is occurring

kdxcoopc: internal operation code

kdxconco: index column count

kdxcosdc: count of index structural changes involving block

kdxconro: number of index entries (does not include kdxbrlmc pointer)

kdxcofbo: offset to beginning of free space within block

kdxcofeo: offset to the end of free space (i.e.. first portion of block containing index data)

kdxcoavs: available space in block (effectively area between kdxcofbo and kdxcofeo)

分支块专用头信息kdxbrlmc: block address if index value is less than the first (row#0) value（例如在root块中,明明有两条记录，却只包含一个row，这是因为第一个可以通过dkxbrlmc来确定）

kdxbrsno: last index entry to be modified

kdxbrbksz: size of usable block space

叶子块专有头信息kdxlespl: bytes of uncommitted data at time of block split that have been cleaned out

kdxlende: number of deleted entries

kdxlenxt: pointer to the next leaf block in the index structure via corresponding rba

kdxleprv: pointer to the previous leaf block in the index structure via corresponding rba

Kdxledsz: deleted space

kdxlebksz: usable block space (by default less than branch due to the additional ITL entry)

记录区域：branch entityRow number (starting at #0) followed by [starting location in block] followed by the dba

Column number (starting at 0) followed by column length followed by column value

Repeated for each indexed column

Repeated for each branch entry

Note: column value is abbreviated to smallest value that uniquely defines path

leaf entity （unique）Row number (starting at #0) followed by [starting location within block]

followed by various flags (deletion flag, locking information etc.) followed by

total length of index entry followed by the rowid

Index column number (starting at 0) followed by column length followed by

column value

Repeated for each indexed column

Repeated for each index entry

Note: Total overhead is 3 bytes for each leaf index entry (unique index)

leaf entity（ununique）Row number (starting at 0) followed by [starting location within block] followed by various

flags (deletion flag, etc locking information) followed by length of index entry

Index column number (starting at 0) followed by column length followed by column value

Repeated for each indexed column with last column in non-unique index being the rowid of

index entry (hence making the index entry effectively unique anyways)

Repeated for each index entry

Note: Total overhead is 4 bytes, 1 more than unique index

篇16：mongodb学习(索引详解)

接下来，我为persons集合的id键创建索引，在mongodb中为我们提供了一个方法：

db.集合名称.ensureIndex({需要创建索引的键：1或-1})

这里1表示建立升序的索引，-1表示建立降序的索引

在创建索引以后的时间变为几乎为0毫秒了，还是大大大的提高了查询效率

注意：使用索引可以提高我们的查询效率，可是会影响我们的插入和更改的效率，因为在插入和更改的时候是会维护该索引的，对于更新较少查询较多的集合可以使用索引。

查看索引

db.persons.getIndexes()

可以看到这里有两个索引，一个是系统默认会创建一个”_id”索引，另外一个就是我们自己创建的”number_id”,可以看到这里的索引名称和我们的键值默认是相同的，如果我需要创建自己的索引名称，比如我为name创建一个叫做”personName”的索引，可以这样写：<?www.2cto.com/kf/ware/vc/“ target=”_blank“ class=”keylink“>vcD4NCjxwcmUgY2xhc3M9”brush:sql;“>db.persons.ensureIndex({name:1},{name:”personName“})

现在，我们的persons集合中有三个索引了，可以看到第三个name索引的名称就是我们自己给的”personName”

★ 数据结构树状数组（二叉索引树）

★ 开发西北的重要情报源――评《西北地方文献索引》

关于索引的范文（共16篇）

欢迎下载DOC格式的关于索引的范文，但愿能给您带来参考作用！

推荐度：

点击下载文档文档为doc格式

猜你喜欢