数据库中的索引有什么用

先正面回答你的问题

数据是否重复不是建立索引的重要依据，甚至都不是依据。

只要不完全重复（所有元组的该元素都一样），那么建立索引就是有意义的。

即使当前数据完全重复，也不是不能建立索引，这种情况有点复杂，不细说了。

对于你后面的疑问，可以给你一个如何建立索引的忠告，“如何查就如何建”。

索引的建立，唯一的原因就是为了查询（广义的查询），实际上建立索引会使得数据存储所占空间变大，有时索引所占的空间会查过数据本身的空间。索引的建立也会使得数据插入时变慢，特殊情况下，慢的难以忍受，所以dba的重要工作之一，就是检查索引层级并优化。

索引建立的唯一好处，就是按照索引查询时，变快了。type，status这2个字段是否适合建立索引，就要看你是否要按照这2个字段进行检索。而检索的顺序决定了如何建立索引。

对于索引类型和索引方式，我建议就

normal

和

btree

就适用于大多数情况。若你参与的是一个大数据处理项目，对数据存储和检索有特别要求，那么需要分析多个层面，比如数据吞吐量、数据的方差、平均差等等很多参数才考虑是否用聚集索引等（mysql好像还没聚集索引），至于是否是唯一索引，我建议不使用，即使能判定数据是唯一的也不要用，全文索引也没有必要。

您好 波士顿，

我看到你的图标发现以前回答过你的几个问题 ：) 希望大家共勉

ORACLE中有2中Index

普通类型 (数据结构为B tree)

Bit Map Index

只有这2种。

您的问题是“ORACLE 如何控制” 。 这个不是Oracle控制的， 是由人控制的。 你在建立索引的时候选择了BIT MAP 那就是BIT MAP。 如果纯粹是建立一个INDEX 、或者主键 外键， 而没有特别说明， 那么就是普通的 B TREE 结构。

这个是你想要的回答吗？

事实上，在MySQL数据库中，诸多存储引擎使用的是B+树，即便其名字看上去是BTREE。

41 innodb的索引机制

先以innodb存储引擎为例，说明innodb引擎是如何利用B+树建立索引的

首先创建一张表：zodiac，并插入一些数据

对于innodb来说，只有一个数据文件，这个数据文件本身就是用B+树形式组织，B+树每个节点的关键字就是表的主键，因此innode的数据文件本身就是主索引文件，如下图所示，主索引中的叶子页（leaf page）包含了数据记录，但非叶子节点只包含了主键，术语“聚簇”表示数据行和相邻的键值紧凑地存储在一起，因此这种索引被称为聚簇索引，或聚集索引。

这种索引方式，可以提高数据访问的速度，因为索引和数据是保存在同一棵B树之中，从聚簇索引中获取数据通常比在非聚簇索引中要来得快。

所以可以说，innodb的数据文件是依靠主键组织起来的，这也就是为什么innodb引擎下创建的表，必须指定主键的原因，如果没有显式指定主键，innodb引擎仍然会对该表隐式地定义一个主键作为聚簇索引。

同样innodb的辅助索引，如下图所示，假设这些字符是按照生肖的顺序排列的（其实我也不知道具体怎么实现，不要在意这些细节，就是举个例子），其叶子节点中也包含了记录的主键，因此innodb引擎在查询辅助索引的时候会查询两次，首先通过辅助索引得到主键值，然后再查询主索引，略微有点啰嗦

right081999-2020,CSDNNET,AllRightsReserved

程序员必备的浏览器插件

登录

越来越好ing

关注

数据库索引是什么，有什么用，怎么用转载

2018-12-0423:30:36

5点赞

越来越好ing

码龄2年

关注

下面是关于数据库索引的相关知识：

简单来说，数据库索引就是数据库的数据结构！进一步说则是该数据结构中存储了一张表中某一列的所有值，也就是说索引是基于数据表中的某一列创建的。总而言之：一个索引是由表中某一列上的数据组成，并且这些数据存储在某个数据结构中。

2索引的作用。举个例子，假设有一张数据表Emplyee，该表有三列：

表中有几万条记录。现在要执行下面这条查询语句，查找出所有名字叫“Jesus”的员工的详细信息

3如果没有数据库索引功能，数据库系统会逐行的遍历整张表，对于每一行都要检查其Employee_Name字段是否等于“Jesus”。因为我们要查找所有名字为“Jesus”的员工，所以当我们发现了一条名字是“Jesus”的记录后，并不能停止继续查找，因为可能有其他员工也叫“Jesus”。这就意味着，对于表中的几万条记录，数据库每一条都要检查。这就是所谓的“全表扫描”（fulltablescan）

4而数据库索引功能索引的最大作用就是加快查询速度，它能从根本上减少需要扫表的记录/行的数量。

5如何创建数据库索引。可以基于Employee表的两列创建索引即可：

：

索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行相比，索引有助于更

问题一：如何用sql语句在列上建立聚集索引 可以用如下语句

create clustered index 索引名 on 表名(字段名)

问题二：如何设置聚集索引(Cluster Index) 一、使用 SQL Server Management Studio

使用对象资源管理器创建聚集索引

在“对象资源管理器”中，展开要创建聚集索引的表。

右键单击“索引”文件夹，指向“新建索引”，然后选择“聚集索引…”。

在“新建索引”对话框的“常规”页中，在“索引名称”框中输入新索引的名称。

在“索引键列”下，单击“添加…”。

在“从 table_name 中选择列”对话框中，选中要添加到聚集索引的表列的复选框。

单击“确定”。

在“新建列”对话框中，单击“确定”。

使用表设计器创建聚集索引

在“对象资源管理器”中，展开要使用聚集索引创建表的数据库。

右键单击“表”文件夹，然后单击“新建表…”。

右键单击上面创建的新表，然后单击“设计”。

在“表设计器”菜单上，单击“索引/键”。

在“索引/键”对话框中，单击“添加”。

从“选定的主/唯一键或索引”文本框中选择新索引。

在网格中，选择“创建为聚集的”，然后从该属性右侧的下拉列表中选择“是”。

单击“关闭”。

在“文件”菜单上，单击“保存 table_name”。

二、使用 Transact-SQL

创建聚集索引

在“对象资源管理器”中，连接到 数据库引擎的实例。

在标准菜单栏上，单击“新建查询”。

将以下示例复制并粘贴到查询窗口中，然后单击“执行”。

USE yourdatabase;

GO

CREATE TABLE dboTestTable

(TestCol1 int NOT NULL,

TestCol2 nchar(10) NULL,

TestCol3 nvarchar(50) NULL);

GO

-- Create a clustered index called IX_TestTable_TestCol1

-- on the dboTestTable table using the TestCol1 column

CREATE CLUSTERED INDEX IX_TestTable_TestCol1

ON dboTestTable (TestCol1);

GO

问题三：SQL中怎么创建非聚集索引 --创建非聚集索引create nonclustered index inx_entry_stock_ on entry_stock_d(entry_stock_bi) --延伸：--创建聚集索引create clustered index inx_entry_stock_bi on entry_stock_d(entry_stock_bi) --创建主键create table yourtable (id int primary key,name varchar (50))--增加主键alter table entry_stock_d add primary key nonclustered--主键且非聚集( entry_stock_bi,aid)

--除此以外还可以通过SQL Server Management Studio 右击表 -》设计-》 右击列 根据右键菜单 建立主键和索引

问题四：数据库怎样创建一个唯一聚集索引 在 Microsoft SQL Server 数据库中，您可以创建聚集索引。在聚集索引中，表中行的物理顺序与索引键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。

创建聚集索引

在对象资源管理器中，右键单击要为其创建聚集索引的表，然后单击“设计”。

此时，将在表设计器中打开该表。

在表设计器菜单上，单击“索引/键”。

在“索引/键”对话框中，单击“添加”。

从“选定的主/唯一键或索引”列表中选择新创建的索引。

在网格中，选择“创建为聚集的”，然后从该属性右侧的下拉列表中选择“是”。

保存表时将在数据库中创建该索引。

问题五：有了聚集索引，为什么还要让我创建非聚集索引 你也可以不创建。但是有索引在读取的时候会更快。但是插入的时候有可可能会变慢，这种现象得表中的数据到达一定级别的时候才会比较明显。

聚集索引和非聚集索引不冲突。聚集索引只能有一个，非聚集可以有多个

聚集索引是：将数据在物理上排序，比如，图书馆的的书，从编号1开始按数字，1，2，3，4，5这样一直排列下来，这里的 1，2，3，4，5就可以建立聚集索引，检索的时候假设你检索 >4的数据就很快。

非聚集是索引是：将数据在逻辑上排序。比如图书馆的书，按照语音 将中文的放到 A区，将英文放在B区，然后又按照图书的类目，比如 文学类 放在 B曲区的 1号货架，历史图书放在B区的2号货架，这样逻辑上的排序是非聚集索引。

手打，累。。。。这是最基本的。索引在表创建的时候有很大学问。我也是皮毛。自己深入研究吧

问题六：在SQLSERVER中怎么创建聚集索引 CREATE CLUSTERED INDEX CLUSTER_id ON TABLE_name(ID)

问题七：什么叫聚集索引，建立索引的好处。 1、聚集索引：又叫聚簇索引，物理索引，与基表的物理顺序相同，数据值的顺序总是按照顺序排列 CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH ALLOW_DUP_ROW(允许有重复记录的聚簇索引) 2、非聚簇索引：CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)3、索引的好处： 1)创建唯一性索引，保证数据库表中每一行数据的唯一性2)大大加快数据的检索速度，这也是创建索引的最主要的原因3)加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。4)在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。5)通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能。 4、索引的缺点： 1)创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加2)索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空 间， 如果要建立 聚簇索引，那么需要的空间就会更大。3)当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度

问题八：MySQL中怎样创建聚集索引和非聚集索引，求创建这两种索引的SQL语句。谢谢 InnoDB按照主键进行聚集，如果没有定义主键，InnoDB会试着使用唯一的非空索引来代替。如果没有这种索引，InnoDB就会定义隐藏的主键然后在上面进行聚集。

所以，对于 聚集索引 来说，你创建主键的时候，自动就创建了主键的聚集索引。

而普通索引（非聚集索引）的语法，大多数数据库都是通用的：

CREATE INDEX Syntax

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name

[index_type]

ON tbl_name (index_col_name,)

[index_type]

index_col_name:

col_name [(length)] [ASC | DESC]

index_type:

USING {BTREE | HASH | RTREE}

[java] view plaincopy

-- 创建无索引的表格

create table testNoPK (

id int not null,

name varchar(10)

);

-- 创建普通索引

create index IDX_testNoPK_Name on testNoPK (name);

问题九：怎么用两个字段联合建立聚集索引 怎么用两个字段联合建立聚集索引

如何用sql语句在列上建立聚集索引可以用如下语句create clustered index 索引名 on 表名(字段名)

问题十：SQL中怎么创建非聚集索引 --格式：--CREATE INDEX 索引名称 ON 表名 (索引字段);--例：CREATE INDEX INX_TABLEA ON TABLEA(F1,F2,F3);

结合MySQL中Innodb存储引擎索引结构来看的话……

教科书上的B+Tree是一个简化了的，方便于研究和教学的B+Tree。然而在数据库实现时，为了更好的性能或者降低实现的难度，都会在细节上进行一定的变化。下面以InnoDB为例，来说说这些变化。

04 - Sparse Index中的数据指针

在“由浅入深理解InnoDB索引的实现(1)”中提到，Sparse Index中的每个键值都有一个指针指向所在的数据页。这样每个B+Tree都有指针指向数据页。

如果数据页进行了拆分或合并 *** 作，那么所有的B+Tree都需要修改相应的页指针。特别是Secondary B+Tree(辅助索引对应的B+Tree), 要对很多个不连续的页进行修改。同时也需要对这些页加锁，这会降低并发性。为了降低难度和增加更新(分裂和合并B+Tree节点)的性能，InnoDB 将 Secondary B+Tree中的指针替换成了主键的键值。

这样就去除了Secondary B+Tree对数据页的依赖，而数据就变成了Clustered B+Tree(簇索引对应的B+Tree)独占的了。对数据页的拆分及合并 *** 作，仅影响Clustered B+Tree 因此InnoDB的数据文件中存储的实际上就是多个孤立B+Tree。

一个有趣的问题: 当用户显式的把主键定义到了二级索引中时，还需要额外的主键来做二级索引的数据吗(即存储2份主键) 很显然是不需要的。InnoDB在创建二级索引的时候，会判断主键的字段是否已经被包含在了要创建的索引中

接下来看一下数据 *** 作在B+Tree上的基本实现。

- 用主键查询

直接在Clustered B+Tree上查询。

- 用辅助索引查询

A 在Secondary B+Tree上查询到主键。

B 用主键在Clustered B+Tree上查询到数据。

可以看出，在使用主键值替换页指针后，辅助索引的查询效率降低了。

A 如果能用主键查询，尽量使用主键来查询数据。

B 但是由于Clustered B+Tree包含了完整的数据，遍历的效率比 Secondary B+Tree的效率低。如果遍历 *** 作不涉及到二级索引和主键以外的数据，则尽量使用二级索引进行遍历。

- INSERT

A 在Clustered B+Tree上插入一条记录

B 在所有其他Secondary B+Tree上插入一条记录(仅包含索引字段和主键)

- DELETE

A 在Clustered B+Tree上删除一条记录。

B 在所有Secondary B+Tree上删除二级索引的记录。

- UPDATE 非键列

A 在Clustered B+Tree上更新数据。

- UPDATE 主键列

A 在Clustered B+Tree删除原有的记录(只是标记为DELETED,并不真正删除)。

B 在Clustered B+Tree插入一条新的记录。

C 在每一个Secondary B+Tree上删除原有的记录。(有疑问，看下一节。)

D 在每一个Secondary B+Tree上插入一个条新的记录。

- UPDATE 辅助索引的键值

A 在Clustered B+Tree上更新数据。

B 在每一个Secondary B+Tree上删除原有的记录。

C 在每一个Secondary B+Tree上插入一条新的记录。

更新键列时，需要更新多个页，效率比较低。

A 尽量不用对主键列进行UPDATE *** 作。

B 更新很多时，尽量少建索引。

05 – 非唯一键索引

教科书上的B+Tree *** 作，通常都假设”键值是唯一的“。但是在实际的应用中Secondary Index是允许键值重复的。在极端的情况下，所有的键值都一样，该如何来处理呢？InnoDB 的 Secondary B+Tree中，主键也是此二级键的一部分。 Secondary Key = 用户定义的KEY + 主键。

注意主键不仅做为数据出现在叶子节点，同时也作为键的一部分出现非叶子节点。对于非唯一键来说，因为主键是唯一的，Secondary Key也是唯一的。当然，在插入数据时，还是会根据用户定义的Key，来判断唯一性。按理说，如果辅助索引是唯一的(并且所有字段不能为空)，就不需要这样做。可是，InnoDB对所有的Secondary B+Tree都这样创建。

还没弄明白有什么特殊的用途？有知道的朋友可以帮忙解答一下。

也许是为了降低代码的复杂性，这是我想到的唯一理由。

弄清楚了,即便是非空唯一键，在二级索引的B+Tree中也可能重复，因此必须要将主键加入到非叶子节点。

06 – <Key, Pointer>对

标准的B+Tree的每个节点有K个键值和K+1个指针，指向K+1个子节点。

而在“由浅入深理解索引的实现(1)”中图 9的B+Tree上，每个节点有K个键值和K个指针。InnoDB的B+Tree也是如此。

这样做的好处在于，键值和指针一一对应。我们可以将一个<Key,Pointer>对看作一条记录。这样就可以用数据块的存储格式来存储索引块。因为不需要为索引块定义单独的存储格式，就降低了实现的难度。

- 插入最小值

当考虑在变形后的B+Tree上进行INSERT *** 作时,发现了一个有趣的问题。如果插入的数据的健值比B+Tree的最小键值小时，就无法定位到一个适当的数据块上去(<Key,Pointer>中的Key代表了子节点上的键值是>=Key的)。例如，在图5的B+Tree中插入键值为0的数据时，无法定位到任何节点。在标准的B+Tree上，这样的键值会被定位到最左侧的节点上去。这个做法，对于图5中的B+Tree也是合理的。Innodb的做法是，将每一层（叶子层除外）的最左侧节点的第一条记录标记为最小记录(MIN_REC)在进行定位 *** 作时，任何键值都比标记为MIN_REC的键值大。因此0会被插入到最左侧的记录节点上。

07 – 顺序插入数据

标准的B-Tree分裂时，将一半的键值和数据移动到新的节点上去。原有节点和新节点都保留一半的空间，用于以后的插入 *** 作。当按照键值的顺序插入数据时，左侧的节点不可能再有新的数据插入。因此，会浪费约一半的存储空间。

解决这个问题的基本思路是：分裂顺序插入的B-Tree时，将原有的数据都保留在原有的节点上。创建一个新的节点，用来存储新的数据。顺序插入时的分裂过程

以上是以B-Tree为例，B+Tree的分裂过程类似。InnoDB的实现以这个思路为基础，不过要复杂一些。因为顺序插入是有方向性的，可能是从小到大，也可能是从大到小的插入数据。所以要区分不同的情况。如果要了解细节，可参考以下函数的代码。

btr_page_split_and_insert();

btr_page_get_split_rec_to_right();

btr_page_get_split_rec_to_right();

InnoDB的代码太复杂了，有时候也不敢肯定自己的理解是对的。因此写了一个小脚本，来打印InnoDB数据文件中B+Tree。这样可以直观的来观察B+Tree的结构，验证自己的理解是否正确。

Hash 索引的查询效率要远高于 B-Tree 索引。

可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。

（1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。

由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。

（2）Hash 索引无法被用来避免数据的排序 *** 作。

由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；

（3）Hash 索引不能利用部分索引键查询。

对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。

（4）Hash 索引在任何时候都不能避免表扫描。

前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。

（5）Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。

对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下。

如何正确合理的建立MYSQL数据库索引

索引是快速搜索的关键。MySQL索引的建立对于MySQL的高效运行是很重要的。下面介绍几种常见的MySQL索引类型。

在数据库表中，对字段建立索引可以大大提高查询速度。假如我们创建了一个 mytable表：

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL

); 我们随机向里面插入了10000条记录，其中有一条：5555, admin。

在查找username="admin"的记录 SELECT FROM mytable WHERE

username='admin';时，如果在username上已经建立了索引，MySQL无须任何扫描，即准确可找到该记录。相反，MySQL会扫描所有记录，即要查询10000条记录。

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

MySQL索引类型包括：

（1）普通索引

这是最基本的索引，它没有任何限制。它有以下几种创建方式：

◆创建索引

CREATE INDEX indexName ON mytable(username(length));

如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。

◆修改表结构

ALTER mytable ADD INDEX [indexName] ON (username(length))

◆创建表的时候直接指定

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL,

INDEX [indexName] (username(length)) ); 删除索引的语法：

DROP INDEX [indexName] ON mytable;

（2）唯一索引

它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：

◆创建索引

CREATE UNIQUE INDEX indexName ON mytable(username(length))

◆修改表结构

ALTER mytable ADD UNIQUE [indexName] ON (username(length))

◆创建表的时候直接指定

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL,

UNIQUE [indexName] (username(length)) );

（3）主键索引

它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL,

PRIMARY KEY(ID) ); 当然也可以用 ALTER 命令。记住：一个表只能有一个主键。

（4）组合索引

为了形象地对比单列索引和组合索引，为表添加多个字段：

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL,

city VARCHAR(50) NOT NULL, age INT NOT NULL );

为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将 name, city, age建到一个索引里：

ALTER TABLE mytable ADD INDEX name_city_age (name(10),city,age);

建表时，usernname长度为 16，这里用

10。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。

如果分别在

usernname，city，age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引。虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。

建立这样的组合索引，其实是相当于分别建立了下面三组组合索引：

usernname,city,age usernname,city usernname 为什么没有

city，age这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引，下面的几个SQL就会用到这个组合索引：

SELECT FROM mytable WHREE username="admin" AND city="郑州" SELECT FROM

mytable WHREE username="admin" 而下面几个则不会用到：

SELECT FROM mytable WHREE age=20 AND city="郑州" SELECT FROM mytable WHREE

city="郑州"

（5）建立索引的时机

到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此，因为MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引。例如：

SELECT tName FROM mytable t LEFT JOIN mytable m ON tName=musername

WHERE mage=20 AND mcity='郑州'

此时就需要对city和age建立索引，由于mytable表的userame也出现在了JOIN子句中，也有对它建立索引的必要。

刚才提到只有某些时候的LIKE才需建立索引。因为在以通配符%和_开头作查询时，MySQL不会使用索引。例如下句会使用索引：

SELECT FROM mytable WHERE username like'admin%' 而下句就不会使用：

SELECT FROM mytable WHEREt Name like'%admin' 因此，在使用LIKE时应注意以上的区别。

（6）索引的不足之处

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：

◆虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。

◆建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。

索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

（7）使用索引的注意事项

使用索引时，有以下一些技巧和注意事项：

◆索引不会包含有NULL值的列

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

◆使用短索引

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

◆索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order

by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序 *** 作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

◆like语句 *** 作

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

“aaa%”可以使用索引。

◆不要在列上进行运算

select from users where YEAR(adddate)<2007;

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成

select from users where adddate<‘2007-01-01’;

◆不使用NOT IN和<> *** 作

以上，就对其中MySQL索引类型进行了介绍。

以上就是关于数据库中的索引有什么用全部的内容，包括:数据库中的索引有什么用、ORACLE创建索引的时候是如何控制所添加索引的类型的。例如btree，位图神马的。。。。、mysql采用哪些索引，B树索引解释下等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！