在引用里面选择目录，把设置弄好之后，自动编制目录。

提示：要想有好看的目录，那么提前把文件中各段的格式设置好是前提。

步骤一、自动生成目录准备：大概索引

1、要想让word自动生成目录，就得先建立系统能认识的大纲索引，这是自动生成目录的前提。选中你的标题。

2、在开始选项卡——格式里选中——选中自己喜欢的目录格式结构。

3、选择之后，就会建立大纲索引，同时，也会具有word默认的标题格式。

4、同理，逐级建立标题2、标题3等目录结构索引。

5、同理，把整个文档中的所有标题都建立起大纲索引。

步骤二、自动生成目录及更新目录

1、前提准备已做好，接下来就开始生成目录。首先，把光标定位到目录存放的位置，然后，点击选项卡的引用——目录——自动目录1或2。

2、就会自动生成目录了。

3、如果你多文章进行了更新，或者目录结构进行了调整，那么就需要对目录进行更新域，点击目录，右键下拉菜单——更新域。

4、建议选择更新整个目录，这样就不会漏掉，点击确定，更新即可。

自定义目录格式调整

如果，你对系统的默认目录格式不满意，需要自定义，也是可以的。点击引用——目录——插入目录。

有很多目录格式的选项可以设置，如要不要显示页面，页面是否右对齐，显示制表符，显示几个级别等。

同时还可以设置目录的字体大小与格式，如图，点击修改——选择要修改的目录——点击修改——就看到相关的字体、间距等相关格式的调整，自定义修改之后，确定即可。

当你进行所以的自定义设定之后，点击确定，就会在刚刚目录的地方出现替换的提示框，点击是就可以了。

关于MySQL复合索引的用法

可以创建多个MySQL的复合索引，每个复合索引可以包含一个或多个列。复合索引的基本原理是左对齐。例如，一个复合索引包含字段A、B和C，这实际上相当于创建五个索引，即:

那么问题来了，如果我们创建两个复合索引，复合索引1:包含A、B、C列，复合索引2:包含B、C列，MySQL会如何执行？

按照正常逻辑和复合索引原理，应该能命中的索引是A_B_C_index。让我们拭目以待！

结果:与上次检测不一致。虽然这个测试中有三个ABC列，但是命中索引是B_C_index。

结论:当命中两个或多个不同的复合索引时，MySQL会有不同的策略根据创建顺序选择其中一个复合索引。

mysql联合索引建立规则？

MySQL中联合索引规则：

1、需要加索引的字段，要在where条件中

2、数据量少的字段不需要加索引

3、如果where条件中是OR关系，加索引不起作用

4、符合最左原则。

create怎么加索引？

1方式:在执行CREATE

2方式:使用ALTERTABLE命令去增加索ALTERTABLEtable_nameADDINDEXindex_name(column_list);1ALTERTABLE用来创建普通索引、UNIQUE索引或PRIMARYKEY索引。其中table_name是要增加索引的表名,column_list指出对哪些列进行索引,多列时各列之间用逗号分隔。索引名index_name可自己命名,缺省时,MySQL将根据第一个索引列赋一个名称。另外,ALTERTABLE允许在单个语句中更改多个表,因此可以在同时创建多个索引。

3方式:使用CREATEINDEX命令创建CREATEINDEXindex_nameONtab

mysql多表查询索引怎么使用？

1selectfromtable1,table2wheretable1id=table2id;2手册上有3是独立的4定期清理数据碎片

mysql联合索引最左匹配原因？

最左前缀匹配原则

在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，

示例：

对列Gid、列Cid和列Sid建一个联合索引

联合索引uni_Gid_Cid_SId实际建立了(Gid)、(Gid,Cid)、(Gid,Cid,SId)三个索引。

插入模拟数据

查询实例：

上面这个查询语句执行时会依照最左前缀匹配原则，检索时会使用索引(Gid,Cid)进行数据匹配。

注意

索引的字段可以是任意顺序的，如：

这两个查询语句都会用到索引(Gid,Cid)，mysql创建联合索引的规则是首先会对联合合索引的最左边的，也就是第一个字段Gid的数据进行排序，在第一个字段的排序基础上，然后再对后面第二个字段Cid进行排序。其实就相当于实现了类似orderbyGidCid这样一种排序规则。

有人会疑惑第二个查询语句不符合最左前缀匹配：首先可以肯定是两个查询语句都保函索引(Gid,Cid)中的Gid、Cid两个字段，只是顺序不一样，查询条件一样，最后所查询的结果肯定是一样的。既然结果是一样的，到底以何种顺序的查询方式最好呢？此时我们可以借助mysql查询优化器explain，explain会纠正sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。

那么问题产生了？既然结果是一样的，到底以何种顺序的查询方式最好呢？

所以，而此时那就是我们的mysql查询优化器该登场了，sql语句中字段的顺序不需要和联合索引中定义的字段顺序一致，查询优化器会自己调整顺序，mysql查询优化器会判断纠正这条sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。所以，当然是我们能尽量的利用到索引时的查询顺序效率最高咯，所以mysql查询优化器会最终以这种顺序进行查询执行。

为什么要使用联合索引

减少开销。建一个联合索引(Gid,Cid,SId)，实际相当于建了(Gid)、(Gid,Cid)、(Gid,Cid,SId)三个索引。每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！

覆盖索引。对联合索引(Gid,Cid,SId)，如果有如下的sql:selectGid,Cid,SIdfromstudentwhereGid=1andCid=2。那么MySQL可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io操作。减少io操作，特别的随机io其实是dba主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。

效率高。索引列越多，通过索引筛选出的数据越少。有1000W条数据的表，有如下sql:selectfromtablewhereGid=1andCid=2andSId=3,假设假设每个条件可以筛选出10%的数据，如果只有单值索引，那么通过该索引能筛选出1000W10%=100w条数据，然后再回表从100w条数据中找到符合Gid=2andCid=3的数据，然后再排序，再分页；如果是联合索引，通过索引筛选出1000w10%10%10%=1w，效率提升可想而知！

缺点。联合索引越多，索引列越多，则创建的索引越多，索引都是存储在磁盘里的，通过索引算法(Btree代表索引算法使用二叉树的形式来做索引的)来查找数据，的确可以极大的提高查询效率，但是与此同时增删改的同时，需要更新索引，同样是需要花时间的，并且索引所占的磁盘空间也不小。

建议。单表尽可能不要超过一个联合索引，单个联合索引不超过3个字段。

引申

对于联合索引(Gid,Cid,SId)，查询语句SELECTFROMstudentWHERECid=465176354;是否能够触发索引？大多数人都会说NO，实际上却是YES。

原因：

观察上述两个explain结果中的type字段。查询中分别是：

type:index

type:ref

index：这种类型表示mysql会对整个该索引进行扫描。要想用到这种类型的索引，对这个索引并无特别要求，只要是索引，或者某个联合索引的一部分，mysql都可能会采用index类型的方式扫描。但是呢，缺点是效率不高，mysql会从索引中的第一个数据一个个的查找到最后一个数据，直到找到符合判断条件的某个索引。所以，上述语句会触发索引。

ref：这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引，而不是会对索引中每一个数据都进行一一的扫描判断，也就是所谓你平常理解的使用索引查询会更快的取出数据。而要想实现这种查找，索引却是有要求的，要实现这种能快速查找的算法，索引就要满足特定的数据结构。简单说，也就是索引字段的数据必须是有序的，才能实现这种类型的查找，才能利用到索引。

索引类型？

索引就是一种将数据库中的记录按照特殊形式存储的数据结构。

通过索引，能够显著地提高数据查询的效率，从而提升服务器的性能。

专业一点来说呢，索引是一个排好序的列表，在这个列表中存储着索引的值和包含这个值的数据所在行的物理地址。

在数据库十分庞大的时候，索引可以大大加快查询的速度，这是因为使用索引后可以不用扫描全表来定位某行的数据，而是先通过索引表找到该行数据对应的物理地址然后访问相应的数据。

说起索引，其实并不是MySQL数据库特有的机制，在关系型数据库中都会有类似不同的实现。

这里我们也只是讨论MySQL数据库中的索引实现。

事实上，说是MySQL的索引其实并不准确。

因为在MySQL中，索引是在存储引擎层而不是服务器层实现的。

这意味着我们所讨论的索引准确来说是InnoDB引擎或MyISAM引擎或其它存储引擎所实现的。

所以索引即便是在MySQL中也没有统一的标准，不同存储引擎的所实现的索引工作方式也并不一样。

不是所有的存储引擎都支持相同类型的索引，即便是多个引擎支持同一种类型的索引，其底层的实现也可能不同。

当我们建立好一个联合索引之后，我们的SQL语句要怎么写，才能让他的查询使用到我们建立好的索引呢？

索引最基本的规则就是等值匹配了，就是where条件里的查询条件字段和联合索引的字段完全一样，都是基于等于来匹配的。

最左侧列匹配 ，假如我们设计的索引是INDEX(class_name, student_name, course_name)，查询的SQL语句where里不一定要根据三个字段来查询，只要最左侧的部分字段来查，就可以了

比如：select from student_score where class_name='xx' and student_name='xx'，只有class_name和student_name可以在索引里搜索，就可以查询某个学生所有科目的成绩。

但如果你SQL是select from where course_name='xx’，那就不能走索引了，因为B+树里必须先按class_name查找，再按student_name查找，不能跳过前面两个字段。

最左侧匹配规则 ，假如你要用like语法来查，比如select from student_socre where class_name like '1%'，查找所有1开头的班级的分数，那么也是可以用索引的。

因为你的联合索引的B+树里，是按照class_name排序的，所以你要是给出class_name的最左前缀就是1，然后后面的给一个模糊匹配符号，那也是可以基于索引来查找的。

但如果你where条件是class_name like '%班'，左侧是模糊查询，就没法用索引了。

范围查找 ，假如你查询的SQL是：select from student_score where class_name>'1班’ and class_name<'5班'，查找几个班的分数。也是可以用到索引的。

因为我们的索引的最下层的数据页都是按顺序组成双向链表的，所以完全可以先找到'1班'对应的数据页，再找到'5班'对应的数据页，两个数据页中间的那些数据页，就全都是在你范围内的数据了！

ORDER BY如何使用上索引？

假设你有一个查询：select from table where xxx=xxx order by xxx，似乎应该是基于where语句通过索引快速筛选出来一波数据，接着放到内存里，或者放在一个临时磁盘文件里，然后通过排序算法按照某个字段来一个排序，最后把排序好的数据返回。

如果是这样的话，肯定就会比较慢，所以最好别这么搞。

尤其是类似于select from table order by xx1,xx2,xx3 limit 10，这样的SQL语句，查出一批数据后，按照多个字段进行排序，最后返回前10条数据，类似的语句其实常常见于分页SQL语句里。

这种情况，我们可以建立一个联合索引INDEX(xx1, xx2, xx3)，这时候数据在索引里默认是按照xx1,xx2,xx3排序的，就不需要查出一批数据再在内存里或磁盘里做复杂的排序工作了。

直接拿到10条数据的主键去聚簇索引里回表查询剩下的字段。

所以，你的SQL里最好是按照联合索引的字段顺序去进行order by排序，这样就可以直接利用联合索引的数据有序性，到索引树里直接按照字段值的顺序去获取数据了。

GROUP BY如何使用上索引？

那假设你有这样一个查询：select count() from table group by xx语句，看起来必须先查出一批数据，然后数据放到一个临时磁盘文件里还有加上部分内存，按照指定字段的值分成一组一组的，接着对每一组都执行一个聚合函数，这个性能也是极差的，因为毕竟涉及大量的磁盘交互。

在索引树里数据都是按照指定的一些字段都排序好的，其实字段值相同的数据都是在一起的，假设要是走索引去执行分组后再聚合，那性能一定比临时磁盘文件去执行好多了。

所以，group by后的字段，最好也是按照联合索引里最左侧的字段开始，按照顺序排列的，这样就可以用上索引来提取一组一组的数据了。

order by和group by用上索引的原理差不多，都是依赖索引数据的顺序性。

索引设计的考虑因素

一般建立索引，尽量使用那些区分度比较大的字段 ，那么才能发挥出B+树快速二分查找的优势来。

什么是区分度比较大？

就是你表里一个列的值不同的越多，区分度越大，值不同的越少，区分度越小。比如订单号，订单表每条数据的订单号都不一样，所以它的区分度大，而性别字段一般就男，女，未知，三个值，区分度就比较小。

要是针对区分度小的字段建立索引，会查出一大批数据，没有太大意义。

尽量对字段类型比较小的列设计索引 ，比如说tinyint之类的，因为他的字段类型比较小，说明这个字段自己本身的值占用磁盘空间小，此时你在搜索的时候性能也会比较好一点。

如果你的字段是name VARCHAR(255)，你可以针对字段的前20个字符建立索引，就是说，对这个字段的每个值的前20个字符放在索引树里。

但此时，你order by name就没法用上索引了，group by name也是一样的道理。因为你索引树里仅仅包含了前20个字符。

函数与索引

假设你设计好了索引，但你SQL里这么写，where sum(xxx)=xx，你给你索引里的字段xxx使用了函数，还能用上索引吗？

不能了，所以尽量不要让你的查询语句里的字段搞什么函数。

现在设计索引的时候需要注意的点都已经讲完了，其实就是好好设计索引，让你的查询语句都能用上索引，同时注意一下字段基数、前缀索引和索引列套函数的问题，尽量让你的查询都能用索引，别因为一些原因用不上索引了。

由于索引本身要占用存储空间，增删改的时候也要维护索引本身，索引一般不要设计太多索引，建议两三个联合索引就应该覆盖掉你这个表的全部查询了。

覆盖索引

一般二级索引的叶子节点仅仅包含了索引里的几个字段值和主键值，如果你要查询表里的很多字段，就需要回表查询，就是先在二级索引里拿到主键id，再回表根据主键id查出所有字段，这个性能其实也不高。

如果能只在二级索引里查到所有字段，那就完美了，这就要引入覆盖索引的概念了。

覆盖索引不是一种索引，是一种基于索引查询的方式。

假设你有查询select xx1,xx2,xx3 from table order by xx1,xx2,xx3这样的语句，这种情况下，你仅仅需要联合索引里的几个字段的值，那么其实就只要扫描联合索引的索引树就可以了，不需要回表去聚簇索引里找其他字段了。

你要查的xx1,xx2,xx3在二级索引里都能提取出来，不需要到聚簇索引里查，这就是覆盖索引。

所以你SQL里最好指定你仅仅需要的几个字段，不要动不动搞一个select 把所有字段都拿出来，甚至最好是直接走覆盖索引的方式，不要去回表到聚簇索引。

即使是必须要回表到聚簇索引，那你也尽可能用limit、where之类的语句限定一下回表到聚簇索引的次数，从二级索引里筛选最少的数据，然后再回表到聚簇索引里去，这样性能也会好一些。