CREATE [UNIQUE] INDEX index_name ON table_name(字段 [ASC|DESC]);
成都创新互联主要从事网站建设、成都网站设计、网页设计、企业做网站、公司建网站等业务。立足成都服务英吉沙,十载网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220
UNIQUE --确保所有的索引列中的值都是可以区分的。
[ASC|DESC] --在列上按指定排序创建索引。
(创建索引的准则：
1.如果表里有几百行记录则可以对其创建索引(表里的记录行数越多索引的效果就越明显)。
2.不要试图对表创建两个或三个以上的索引。
3.为频繁使用的行创建索引。
)
示例
create index i_1 on emp(empno asc);
1、要想高效利用索引，我们首先要考虑如何正确建立索引。
（1）在经常做搜索的列上，也就是WHERE子句里经常出现的列，考虑加上索引，加快搜索速度。
（2）唯一标识记录的列，应该加上唯一索引，强制该列的唯一性并且加快按该列查找记录的速度。
（3）在内连接使用的列上加上索引，最好是在内连接用到字段都加上，因为MySQL优化器会自动地选择连接顺序，然后观察索引的使用情况，将没用的索引删除即可。
（4）在需要排序的列上加上索引，因为索引本身是按顺序的组织的，它可以避免 filesort，要知道，Server层在进行排序时是在内存中进行的，非常消耗资源。
（5）可以考虑实现覆盖索引，即根据 SELECT 的所有字段上创建联合索引，这样存储引擎只用读取索引而不用去回表查询，极大地减少了对数据表的访问，大大地提高了性能。
（6）对于那些选择性很小的列，比如性别列，增加索引并不能明显加快查询速度，反而该索引会成为表的累赘。
（7）对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的要么数据量相当大，要么取值很少。
（8）当对写性能的要求远远大于读性能时，不应该创建索引。写性能和读性能是互相矛盾的。这是因为，维护一个 B+Tree 成本是非常大的，对索引的写会涉及到页的分裂等。
（9）复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？如果是，则可以建立复合索引，否则考虑单字段索引。这还是说明，满足查询性能的前提下，索引越少越好。
（10）如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字段。
（11）在用于GROUP BY的列上加上索引，避免使用临时表。
（12）对于较长的字符列，如 char、varchar等，由于字符串的比较相对来说非常耗时，因此考虑使用前缀索引减少索引长度，或者创建自定义哈希索引，将字符串映射成整数，然后以该整数作为索引，同时以字符串的值作为过滤条件。
我们在创建索引时，可以根据下面原则进行简单判断：索引是否将相关记录集合到了一起，从未减少了磁盘I/O，加快搜索速度？索引中数据的排列顺序是否和查找的数据的排列顺序一致，从而避免了Server层的排序？索引中的列是否包含了查询中需要的全部列从而实现了覆盖索引？ 这几个条件层层递进，满足得越多越好。
2、索引正确地建立了，我们还需要正确地使用它们：
（1）使用了运算符 !=，以及关键字not in，not exist，，等，总之产生的结果集很大时（也在where条件进行大范围的选择时），往往导致引擎不使用索引而是走全盘扫描。因为如果使用索引会造成大量的随机I/O，得不偿失。
（2）如果对索引列进行运算，如 WHERE substr(name, 1, 3)=‘mark’，存储引擎并不能聪明地判断哪些索引满足等式，因此不能使用到索引。
（3）使用到了LIKE，并且通配符在最前面时，不能使用索引。
（4）对于联合索引 (a, b, c)，如果没用到最左列，那么一般情况下都使用不到索引。但是，比如统计操作 count(*) where a xxx，是可以使用到该联合索引的。毕竟统计这类操作，它不是检索，并不需要索引完全有序。
（5）对于联合索引，如果某个列使用了范围查找，那么其右边的列都无法作为索引优化查询，但是由于 ICP（Index Condition Pushdown），这些列能作为过滤条件在存储引擎中对数据进行过滤。
（6）如果条件中有 OR，则必须每个OR用到的字段都有索引，否则不能使用任何索引。
（7）想在联合查询中使用索引来避免 filesort，则关联查询中的ORDER BY用到的字段必须全部是第一张表（驱动表）上的。
MySQL的Innodb存储引擎的索引分为聚集索引和非聚集索引两大类
特点：B+树叶子节点存储行数据
一个表中，必须有一个聚集索引，只能有一个聚集索引，Innodb通常把一个表的主键索引作为聚集索引，如果没有主键InnoDB会选择一个唯一索引代替。如果没有这样的索引，InnoDB会隐式的定义一个主键来作为聚集索引，这个字段为6个字节，类型为长整形。
利用主键索引查找行数据是最快的，建议使用自增主键原因是利于索引树的构建（主键自增写入时新插入的数据不会影响到原有页，插入效率高；但是如果主键是无序的或者随机的，那每次的插入可能会导致原有页频繁的分裂，影响插入效率）
特点：B+树叶子节点存储主键ID
一个表中可以有多个非聚集索引，每个非聚集索引即是一棵B+树
通过非聚集索引查找数据时，需要先在非聚集索引上找到主键ID，再从聚集索引获取行数据，这个过程就称之为回表
B树索引中的B树实际上是B+树，至于为什么使用B+树而不使用B树或者红黑树的原因在另外的文章中有提及。
特点：
特点：类似JDK中的HashMap，但无法支持范围查询
特点：使用的算法仍然是B树索引，不同的就是索引列的值必须唯一
对于普通索引来说，查找到满足条件的第一个记录后，需要查找下一个记录，直到碰到第一个不满足条件的记录。
对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索，提升索引性能
另外插入行时会构建该唯一索引，假如索引值重复将插入失败，适合业务上做唯一性检验
通过建立倒排索引，可以极大的提升检索效率,解决判断字段是否包含的问题，但是业务上一般都不采用这种索引，而是使用ES处理全文搜索需求
仅对某个特定字段建立的索引，如(biz_id)
对多个字段建立的索引，如(biz_id,type)
字符串创建索引方式：
1、直接创建完整索引，比较占用空间。
2、创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引。
3、倒序存储，在创建前缀索引，用于绕过字符串本身前缀的却分度不够的问题。
4、创建hash字段索引，查询性能稳定，有额外的存储和计算消耗。
倒序存储和hash字段索引都不支持范围查询。倒序存储的字段上创建的所有是按照倒序字符串的方式排序的。hash字段的方式也只能支持等值查询。
mysql alter table SUser add index index1(email); :包含了每个记录的整个字符串
或
mysql alter table SUser add index index2(email(6)); :-对于每个记录只取前6个字节
全字段索引操作流程
使用的是 index1（即 email 整个字符串的索引结构），执行顺序是这样的：
1、从 index1 索引树找到满足索引值是’ zhangssxyz@xxx.com ’的这条记录，取得 ID2 的值；
2、到主键上查到主键值是 ID2 的行，判断 email 的值是正确的，将这行记录加入结果集；
3、取 index1 索引树上刚刚查到的位置的下一条记录，发现已经不满足 email=' zhangssxyz@xxx.com ’的条件了，循环结束。
前缀字段索引操作流程
如果使用的是 index2（即 email(6) 索引结构），执行顺序是这样的：
1、从 index2 索引树找到满足索引值是’zhangs’的记录，找到的第一个是 ID1；
2、到主键上查到主键值是 ID1 的行，判断出 email 的值不是’ zhangssxyz@xxx.com ’，这行记录丢弃；
3、取 index2 上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出 ID2，再到 ID 索引上取整行然后判断，这次值对了，将这行记录加入结果集；
4、重复上一步，直到在 idxe2 上取到的值不是’zhangs’时，循环结束。
倒序查询和hash字段的区别
它们的区别，主要体现在以下三个方面：
1、从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。当然，倒序存储方式使用 4 个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个 hash 字段也差不多抵消了。
2、在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来看的话，reverse 函数额外消耗的 CPU 资源会更小些。
3、从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。
