mysql 索引如何创建（mysql索引如何创建）

Mysql索引体验

那么，如何合理地建立指数呢？在这里，我想分享一下我的一些经历。如有不妥之处，请批评指正。

1.不要盲目建索引，先分析再创建。

虽然索引可以极大地提高我们的查询性能，但我们也应该知道，当您添加、删除和更改时，索引树应该以同样的方式进行维护。所以指标不是越多越好，而是按需分配。最好在开发完成后对整个模块进行分析，并为大多数查询建立一个联合索引。

2.使用联邦索引来覆盖尽可能多的条件。

这意味着，如果一个慢速sql中有五个where和一个order by，那么我们的联合索引将尽可能覆盖这五个查询条件，如果有必要，order by也将覆盖它们。

3.小基数字段不需要索引。

这意味着如果一个表中某个字段只有几个值，那么你为这个字段设置的索引实际上是没有意义的。比如一个性别字段有两个结果，你设置了一个索引，排序是没有意义的(就是索引把男女分开了)。

所以指数要尽量选择基数大的数据来构建，这样可以最大限度的利用指数。

4.长字符串可以通过前缀进行索引。

我们尽量选择较小字段类型的字段，比如varchar(20)和varchar(256)。我们设置在20以上的索引和256上的索引有明显的差距(字符串这么长就不好排序了，唉)。

当然，如果一定要对varchar(256)进行索引，可以选择其中的前20个字符放在索引树中(这里的20不是绝对的，所以尽量选择能够区分数据的最小字符字段设计)。像这样，KEY索引(姓名(20)，年龄，职务)，索引只会搜索姓名的前20个字符，但是前缀索引不能应用于order by和group by。

5.为排序字段设计索引的优先级较低。

如果我们在SQL中有一个范围搜索，后跟一个排序字段，那么我们首先设置范围搜索字段的索引，而不是先对它进行排序。

6.如果有慢速SQL，可以只为这个SQL设计一个联合索引。

但是慢SQL的优化需要一步一步来分析。可以先用explain检查SQL语句的分析结果，然后根据结果进行相应的改进。我们下次会谈到解释。

PS:在select语句前添加explain关键字，MySQL会在查询上设置一个标志，执行查询会返回执行计划的信息，而不是执行这条SQL。

mysql四个索引怎么建立？

mysql四个索引建立语句如下：

create index 索引名 on table_name(column1,column2);

alter table table_name add index 索引名(column1,column2);

mysql中不能创建索引的语句？

一、创建索引

1.PRIMARY KEY（主键索引）

mysql > ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

2.UNIQUE(唯一索引)

mysql > ALTER TABLE `table_name` ADD UNIQUE (`column` )

3.INDEX(普通索引)

mysql > ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

4.FULLTEXT(全文索引)

mysql > ALTER TABLE `table_name` ADD FULLTEXT ( `column` )

5.多列索引(组合索引)

mysql > ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

CREATE TABLE table_name ( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOTNULL, age INT NOT NULL );

mysql innodb建立普通索引怎么写？

先从数据结构的角度来答。

题主应该知道B-树和B+树最重要的一个区别就是B+树只有叶节点存放数据，其余节点用来索引，而B-树是每个索引节点都会有Data域。

这就决定了B+树更适合用来存储外部数据，也就是所谓的磁盘数据。

从Mysql（Inoodb）的角度来看，B+树是用来充当索引的，一般来说索引非常大，尤其是关系性数据库这种数据量大的索引能达到亿级别，所以为了减少内存的占用，索引也会被存储在磁盘上。

那么Mysql如何衡量查询效率呢？磁盘IO次数，B-树（B类树）的特定就是每层节点数目非常多，层数很少，目的就是为了就少磁盘IO次数，当查询数据的时候，最好的情况就是很快找到目标索引，然后读取数据，使用B+树就能很好的完成这个目的，但是B-树的每个节点都有data域（指针），这无疑增大了节点大小，说白了增加了磁盘IO次数（磁盘IO一次读出的数据量大小是固定的，单个数据变大，每次读出的就少，IO次数增多，一次IO多耗时啊！），而B+树除了叶子节点其它节点并不存储数据，节点小，磁盘IO次数就少。这是优点之一。

另一个优点是什么，B+树所有的Data域在叶子节点，一般来说都会进行一个优化，就是将所有的叶子节点用指针串起来。这样遍历叶子节点就能获得全部数据，这样就能进行区间访问啦。

至于MongoDB为什么使用B-树而不是B+树，可以从它的设计角度来考虑，它并不是传统的关系性数据库，而是以Json格式作为存储的nosql，目的就是高性能，高可用，易扩展。首先它摆脱了关系模型，上面所述的优点2需求就没那么强烈了，其次Mysql由于使用B+树，数据都在叶节点上，每次查询都需要访问到叶节点，而MongoDB使用B-树，所有节点都有Data域，只要找到指定索引就可以进行访问，无疑单次查询平均快于Mysql（但侧面来看Mysql至少平均查询耗时差不多）。

总体来说，Mysql选用B+树和MongoDB选用B-树还是以自己的需求来选择的。