方法一：alter table 表名  add index(字段名) ；

方法二：create index 索引名 on 表名(字段名)；

区别：

方法一 :

1.索引名可不写，mysql自动生成，也可以加。

例如：alter table 表名  add index  index_A (字段名A) ;

2.同时创建多个索引。

例如：alter table 表名  add index index_A(字段名A)，add index  index_B(字段名B)；

方法二：

1.不可用省略索引名。

拓展：

选择字段作为索引，最好选择索引区分度大的字段，这样检索的效率高，速度快；

索引区分度=count(discount 字段A)/count(字段A)

1 避免使用字符串索引
       字符串索引与数字索引有一些方面如果没做好会非常的慢。
　　事情的起因是线上日志发现的mysql慢查询。100万数据量的标准，联合查询全部走索引的情况下，尽然要600多毫秒。很不解，但是将索引列由varchar(50)型改为bigint型后，数据提升了30倍。究其原因就索引树上搜索时要进行大量的比较操作，而字符串的比较比整数的比较耗时的多。
　　所以建议一般情况下不要在字符串列建立索引，如果非要使用字符串索引，可以采用以下两种方法：
　　1.只是用字符串的最左边n个字符建立索引，推荐n<=10;比如index left(address,8),但是需要知道前缀索引不能在order by中使用，也不能用在索引覆盖上。
　　2.对字符串使用hash方法将字符串转化为整数，address_key=hashToInt(address)，对address_key建立索引，查询时可以用如下查询where address_key = hashToInt(‘beijing,china’) and address = ‘beijing,china’;

什么是索引？
索引是数据库存储引擎用于快速查找到指定数据的一种数据结构。
可以用新华字典做类比：如果新华字典中对每个字的详细解释是数据库中表的记录，那么按部首或拼音等排序的目录就是索引，使用它可以让我们快速查找的某一个字详细解释的位置。
在MySQL中，存储引擎也是用了类似的方法，先在索引中找到对应的值，然后再根据匹配的索引值找到对应表中记录的位置。面试中为什么问索引？
之所以在索引在面试中经常被问到，就是因为：索引是数据库的良好性能表现的关键，也是对查询能优化最有效的手段。索引能够轻易地把查询性能提高几个数量级。
然而，糟糕的索引也同样会影响查询性能，当表中的数据量越来越多的时候，索引对性能的影响就越大。在数据量比较少并且负责比较低的时候，糟糕的索引对性能的影响可能不明显，但是当数据量逐渐增多的时候，性能会急剧下降。索引的类型
经过前面的介绍，我们就进入正题，了解一下MySQL支持的索引类型，以及它们的原理和用法。
不同类型的索引，可以为不同场景提供更好的性能。在MySQL中，索引是在存储引擎层面实现的，而不是在服务器层面实现的。正如大家所知道，MySQL支持多种类型的存储引擎。所以，在不同存储引擎中索引的实现方式并不是一样的，也不是所有类型的索引都被所有存储引擎支持的，即使多个存储引擎支持同一种类型的索引，它底层的实现也有可能是不相同的。B-Tree索引
B-Tree索引是被大多数MySQL存储引擎支持的，在我们讨论索引时，假如没有特别地说明类型，那么大概率说的就是B-Tree索引了。我们使用B-Tree这个词，是因为MySQL在创建表和其他语句中就使用这个关键字。
然而，在不同存储引擎的底层可能使用不同的数据结构和算法，比如：InnoDB存储引擎内部使用的是B+Tree结构，NDB集群存储引擎内部使用的是T-Tree结构。不同存储引擎用以不同的方式使用B-Tree索引，性能也可能不同，比如：InnoDB的索引上存储的是元数据格式，而MyISAM存储引擎使用前缀压缩技术使索引更小，InnoDB索引的行存储的数据行的主键引用，而MyISAM存储引擎的索引的行存储的是数据行的物理位置。B-Tree索引的原理
B-Tree索引能够加快访问数据的速度，因为不需要全表扫描就可以快速检索的需要的数据。那么B-Tree索引是怎么做到的呢？我们通过一个简单的例子了解一下InnoDB的B-Tree索引是怎么工作的：
这个表中共有4个字段，分别表示省、市、区和详细地址，还有一个B-Tree索引，其中包含了省、市、区三个字段。因为索引的所有值都是按照顺序存储的，即：节点的左子树比当前节点小，节点的右子树比当前节点大。那么当查询数据时，从索引的根节点开始搜索，根据比较当前节点的索引值向子树进行查找，直到找到对应的索引值，或者根本没有找到。B-Tree索引的用法
根据B-Tree索引的特点，它可以用于全值匹配、值范围匹配和最左前缀匹配。
全值匹配是指和索引中所有的字段进行匹配，比如：查询黑龙江省哈尔滨市南岗区的数据。值范围匹配是指索引中字段的某一范围进行匹配，但是必须满足前面字段的全匹配，比如：第一个字段province_name省名称的全匹配，第二个字段city_name城市名称的范围匹配。最左前缀匹配是指索引中字段的某一开头部分进行匹配，但是必须满足前面字段的全匹配，比如：第一个字段province_name省名称为内蒙古，第二个字段city_name城市名称以“呼”开头。哈希索引
哈希索引是基于哈希表实现的，用于精确匹配索引所指向的数据。存储引擎对每一行数据的所有索引字段计算出一个哈希码，哈希码是一个比较小的值，并且不同的数据计算出来的哈希码一般情况下也不一样。哈希索引中存放了这个哈希码和指向这个数据行的指针。
在MySQL中，只有Memory存储引擎支持哈希索引，也是Memory存储引擎的默认索引类型。另外，在InnoDB存储引擎中也运用了哈希索引，叫做自适应哈希索引。当某些索引中被非常频繁的使用时，InnoDB存储引擎会在内存中基于B-Tree索引之上再创建一个哈希索引，这样一来使得B-Tree索引也具有的快速哈希查找的优点。
哈希索引因为只需存放对应数据的哈希值，所以索引的结构非常紧凑，占用空间小，同时查询速度也非常快。不过，哈希索引只支持全值等值查询，不能索引字段范围匹配和部分索引字段匹配。空间数据索引
空间数据索引(R-Tree)主要用于地理数据的存储，会从所有维度来索引数据，查询时可以有效的使用任意维度进行组合查询。 目前，MyISAM存储引擎支持空间数据索引，不过必须使用MySQL的GIS相关的函数来维护数据。
在MySQL中，空间索引只能建立在空间数据类型上，如：GEOMETRY、POINT、LINESTRING等。全文索引
全文索引不像之前介绍的索引那样直接比较索引中的值，而是直接比较查找的文本中的关键词，它类似于搜索引擎做的事情，不是简单的where条件匹配。
在相同的字段上，可以同时创建全文索引和B-Tree索引，不会有冲突。全文索引适用于match和against操作，不是普通的where条件操作。在MySQL中，只能在类型为CHAR、VARCHAR、TEXT的字段上创建全文索引。总结
索引是数据库存储引擎用于快速查找到指定数据的一种数据结构，它包括B-Tree索引、哈希索引、空间数据索引、全文索引，其中B-Tree索引是我们最常用到的，InnoDB存储引擎内部使用的是B+Tree结构；哈希索引是基于哈希表实现的，用于精确匹配索引所指向的数据；空间数据索引从所有维度来索引数据，查询时可以有效的使用任意维度进行组合查询；全文索引是直接比较查找的文本中的关键词，类似于搜索引擎。更多相关知识请点击：

MySQL索引实现
在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的，本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。
走进搜索引擎的作者梁斌老师针对B树、B+树给出了他的意见(为了真实性，特引用其原话，未作任何改动)： “B+树还有一个最大的好处，方便扫库，B树必须用中序遍历的方法按序扫库，而B+树直接从叶子结点挨个扫一遍就完了，B+树支持range-query非常方便，而B树不支持。这是数据库选用B+树的最主要原因。
比如要查 5-10之间的，B+树一把到5这个标记，再一把到10，然后串起来就行了，B树就非常麻烦。B树的好处，就是成功查询特别有利，因为树的高度总体要比B+树矮。不成功的情况下，B树也比B+树稍稍占一点点便宜。
B树比如你的例子中查，17的话，一把就得到结果了，
有很多基于频率的搜索是选用B树，越频繁query的结点越往根上走，前提是需要对query做统计，而且要对key做一些变化。
另外B树也好B+树也好，根或者上面几层因为被反复query，所以这几块基本都在内存中，不会出现读磁盘IO，一般已启动的时候，就会主动换入内存。"
MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。下图是MyISAM索引的原理图：
这里设表一共有三列，假设我们以Col1为主键，上图是一个MyISAM表的主索引(Primary key)示意。可以看出MyISAM的索引文件仅仅保存数据记录的地址(默认是以存储顺序)。在MyISAM中，主索引和辅助索引(Secondary key)在结构上没有任何区别，只是主索引要求key是唯一的，而辅助索引的key可以重复。如果我们在Col2上建立一个辅助索引，则此索引的结构如下图所示：
同样也是一颗B+Tree，data域保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。
MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。
InnoDB索引实现
虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。
第一个重大区别是InnoDB的数据文件本身就是索引文件。从上文知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。
上图是InnoDB主索引(同时也是数据文件)的示意图，可以看到叶节点包含了完整的数据记录。这种索引叫做聚集索引。因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键(MyISAM可以没有)，如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。
第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。例如，上图为定义在Col3上的一个辅助索引：
这里以英文字符的ASCII码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。再例如，用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。
使用explain对sql进行优化：
1) consts 单表中最多只有一个匹配行(主键或者唯一索引),在优化阶段即可读取到数据。
2) ref 指的是使用普通的索引。(normal index)
3) range 对索引进范围检索。
反例:explain 表的结果,type=index,索引物理文件全扫描,速度非常慢,这个 index 级别
比较 range 还低,与全表扫描是小巫见大巫。
当使用索引时，InnoDB会锁住它不需要的元组。更糟糕的是，如果查询不能使用索引，MySQL会进行全表扫描，并锁住每一个元组，不管是否真正需要