- 什么是索引；
- 什么是聚簇索引和非聚簇索引;
- 为什么要建索引;
- 动手试试，看看代码怎么敲的；
- 性能比较与分析；
什么是索引.
我们来看看比较大众的定义,OK,那就直接百度百科吧:"索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。" 看中心语-关键词[一种结构],说到底索引就是对数据列的值进行结构化排序的一个东西.
通俗点讲吧. 还记得大学军训的时候吗,大伙第一天穿上迷彩服到运动场或者野外军训场地进行军训的时候,一般都是乱扎堆的吧,乱成一团,结果军训的教官来了,教官一看大伙,有男有女,有高有矮 几分钟很快就把大伙排成了m行n列的方针，尽然有序，高低有序；而且没多久教官还能很快滴说出大家的名字，‘x行y列（或者xx号学员），王大锤，出列!’ 一声令下，王大锤就从队列中走出来了，...
这段场景中，教官就是军训场地上最好的【索引】；
什么是聚簇索引和非聚簇索引
有了索引的概念认知，聚簇索引和非聚簇索引就好理解了,说一个最简单的例子吧；
【聚簇索引】
平时习惯逛图书馆的童鞋可能比较清楚，如果你要去图书馆借一本书，最开始是去电脑里面查书名然后根据书名来定位藏书在那个区，哪个书柜，哪一行，第多少本。。。清晰明确，一目了然，因为藏书的结构与图书室的位置，书架的顺序，书本的摆放顺序与书籍的编号都是从大到小一致的顺序摆放的，所以很容易找到。比如，你的目标藏书在C区2柜3排5仓，那么你走到B区你就很快知道前面就快到了C区了，你直接奔着2柜区就能找到了。 这就是雷同于聚簇索引的功效了，聚簇索引，实际存储的循序结构与数据存储的物理机构是一致的，所以通常来说物理顺序结构只有一种，那么一个表的聚簇索引也只能有一个，通常默认都是主键，设置了主键，系统默认就为你加上了聚簇索引，当然有人说我不想拿主键作为聚簇索引，我需要用其他字段作为索引，当然这也是可以的，这就需要你在设置主键之前自己手动的先添加上唯一的聚簇索引，然后再设置主键，这样就木有问题啦。
总而言之，聚簇索引是顺序结构与数据存储物理结构一致的一种索引，并且一个表的聚簇索引只能有唯一的一条；
【非聚簇索引】
同样的，如果你去的不是图书馆，而是某城市的商业性质的图书城，那么你想找的书就摆放比较随意了，由于商业图书城空间比较紧正，藏书通常按照藏书上架的先后顺序来摆放的，所以如果查询到某书籍放在C区2柜3排5仓，但你可能要绕过F区，而不是A.B.C.D...连贯一致的，也可能同在C区的2柜，书柜上第一排是计算机类的书记，也可能最后一排就是医学类书籍；
那么对照着来看非聚簇索引的概念就比较好理解了，非聚簇索引记录的物理顺序与逻辑顺序没有必然的联系，与数据的存储物理结构没有关系；一个表对应的非聚簇索引可以有多条，根据不同列的约束可以建立不同要求的非聚簇索引；
为什么要建索引
这个问题肯定很简单啦，看了上面的描述就知道了，肯定是为了加快找到目标数据的速度，节约查找话费的时间啦，用数据库属于来描述就是 ：
建立索引的目的是加快对表中记录的查找或排序。
但是话又说回来了，有了索引是不是就以为的数据的查询快得不要不要的，。。。。
或者说，添加了索引之后，查询速度一定回避没有添加索引的情况下更快？ 我看未必哦。。。
我们还是先了解一下 家里索引需要付出的代价和带来的弊端吧：
一.增加了数据库的存储空间，
二.在插入和修改数据时要花费较多的时间(因为索引也要随之变动)；
我们假设在一张表中的一条记录在磁盘上占用1KB话，我们对其中10B的一个字段建立索引，那么该记录对应的索引块的大小只有10B，如果一张表的的数据量比较大，大约100,000条，那么用来存储索引耗费的空间就是100,000X10B=1000,000B=10000KB=1MB,换句话说，这张白表也因为这个索引的建立而多使用了大约1MB的存储空间，当然对与大批量数据来说，这么点空间是不足为道的。但事实是，索引确实耗费了更多空间；
关于第二条我就不用赘述了，这个文字描述已经说的很清楚；
还有就是，对某些场景下，数据量不是特别大的情况下，对于某些添加索引的行为，不但不能优化查询速度，反而会减慢查询速度，当然，如果索引的建立不恰当，所选择建立索引的字段不合适，也可能会削弱查询速度，当然在数据量不大的情况下，基于SQL服务器本身强大的处理能力，这种削弱表现是非常微弱的，但是一旦数据量大起来,原本可以不需要考虑索引就能很快查询出来数据的，结果因为添加了索引反而加重了查询数据的消耗，不恰当的索引方式造成的影响就会表现的很明显；
所以，索引不是万能的，某些情况下，添加索引可能比不添加索引更慢！
动手试试：看看代码怎么敲的
建立索引之前选好表对象，假设表明为IndexTestTable此表中包含三个字段Id，Name，UniqueCode
为了更快的进行姓名查询，我们可以在Name字段上添加非聚簇索引；
创建索引的格式如下：
CREATE NONCLUSTERED INDEX [index_name【索引名称】] ON [table_name【表名称】]([column_name1【列名称】],[column_name2【列名称】],...);
我们给IndexTestTable表的Name字段添加一个非聚簇索引：
CREATE NONCLUSTERED INDEX IndexTestTable_index_name ON IndexTestTable(Name);
给IndexTestTable表的UniqueCode字段添加一个聚簇索引：
CREATE CLUSTERED INDEX IndexTestTable_index_uniquecode ON IndexTestTable(UniqueCode)
以上的代码是最简单最直接设置索引的方式，而通常实际应用中，会有多字段联合添加索引的情况，这个就需要你根据实际的应用查询场景，以及在where条件下最常用的查询字段，例如：在 TableX中你最经常查询的条件为：
SELECT Name，Message FROM TableX
WHERE 1=1 AND DeptId='003523'
AND LimitedCondition='SomeValue'
这个时候你就可以 添加一个基于 DeptId 和 LimitedCondition 两个字段的非聚簇索引，以便于加速查询速度；
CREATE NONCLUSTERED INDEX TableX_index_departid_limitedcondition ON TableX(DeptId,LimitedCondition);
简言之，就是需要根据你的实际应用场景，添加有用并且高效的索引；
性能比较与分析；
在一个有千万级数据量的某表mytable中(表没有实际意义用途，仅限于数据查询研究，只用三个字段)，查询数据总数，遍历表记录耗时大约15秒；
SELECT COUNT(id) FROM mytable;
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 14.750 sec. */
查询某一行数据，基于主键Id查询，耗时1秒不到；
SELECT * FROM mytable WHERE id = 7351158;
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 0.031 sec. */
但是同样是上面 一行数据 如果查询UUID这个种字符型数据且未设置索引的情况下，则需要耗时较长时间；
SELECT * FROM mytable WHERE xuuid = '0e670e7a-427e-11e6-beb1-286ed48926ad';
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 15.563 sec. */
现在我们在 xuuid上添加一条索引；
CREATE NONCLUSTERED INDEX mytable_index_xuuid ON mytable(xuuid);
好吧 接下来见证奇迹的时候到了，我们一起来看一下，加完索引之后有什么神奇的变化：
SELECT * FROM mytable WHERE xuuid = '0e670e7a-427e-11e6-beb1-286ed48926ad';
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 0.046 sec. */
看清楚了， 是0.046秒，换句话说，是46毫秒；
这样来说，数据查询优化的空间可是相当大有可为的，童鞋们学好索引的正确打开方式，对以后加快查询方式会有很大的帮助哦....
最后引用别人[姜敏(http://www.cnblogs.com/aspnet2008/)]曾经总结过的几句话来描述一下索引的使用原则：
总结索引使用原则：
1:不要索引数据量不大的表，对于小表来讲，表扫描的成本并不高。
2:不要设置过多的索引，在没有聚集索引的表中，最大可以设置249个非聚集索引，过多的索引首先会带来更大的磁盘空间，而且在数据发生修改时，对索引的维护是特别消耗性能的。
3:合理应用复合索引，有某些情况下可以考虑创建包含所有输出列的覆盖索引。
4:对经常使用范围查询的字段，可能考虑聚集索引。
5:避免对不常用的列，逻辑性列，大字段列创建索引。
sql优化一般方法：
一.建立索引
二.sql优化
在处理好索引后，接下来就是分析查询语句，查询语句可以借助专业的分析工具来分析，一个好的语句和不好的语句也会很影响效率，现在简单总结一下在查询语句的优化方向：
1、查询字段禁止出现 selete *
2、where 及 order by 涉及的列上建立索引。
3、where避免出现非空判断：比如：select from table where num is null
此时可以给num赋一个默认值0，语句修改为：select from table where num=0
4、应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
5、应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
-----查询value值为1 或者 4 的数据集合
select Id from SYS_Confige where Value=1 or Value=4
---- 可以这样查询：
select * from SYS_Confige where Value=1
union all
select * from SYS_Confige where Value=4
6、in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from SYS_Configet where Value in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from SYS_Configet where num Value 1 and 3
7、查询时避免使用like '%待查询关键字%' 查询
8、在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，
否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致
9、能够用关联查询的不要用exists
10、避免频繁创建和删除临时表，以减少系统表资源的消耗。
11、尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理
三.分区存储
四.分库分表
mysql存储引擎
Mysql的存储引擎有很多种，实际我们在平时用的最多的莫过于InnoDB和MyISAM了。所有如果面试官问道mysql有哪些存储引擎，你只需要告诉这两个常用的就行。那他们都有什么特点和区别呢？MyISAM：默认表类型，它是基于传统的ISAM类型，ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写，它是存储记录和文件的标准方法。不是事务安全的，而且不支持外键，如果执行大量的select，insert MyISAM比较适合。InnoDB：支持事务安全的引擎，支持外键、行锁、事务是他的最大特点。如果有大量的update和insert，建议使用InnoDB，特别是针对多个并发和QPS较高的情况。注：在MySQL 5.5之前的版本中，默认的搜索引擎是MyISAM，从MySQL 5.5之后的版本中，默认的搜索引擎变更为InnoDB。MyISAM和InnoDB的区别：
1，InnoDB支持事务，MyISAM不支持。对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
2，InnoDB支持外键，而MyISAM不支持。
3，InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
4，InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快。
5，Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；5.7以后的InnoDB支持全文索引了。
6，InnoDB支持表、行级锁(默认)，而MyISAM支持表级锁。；
7，InnoDB表必须有主键（用户没有指定的话会自己找或生产一个主键），而Myisam可以没有。
8，Innodb存储文件有frm、ibd，而Myisam是frm、MYD、MYI。
Innodb：frm是表定义文件，ibd是数据文件。
Myisam：frm是表定义文件，myd是数据文件，myi是索引文件。
转发自：https://www.cnblogs.com/auxg/p/Cluster-and-NonCluster-index.html