索引：
几乎所有的索引都是建立在字段之上。
索引：系统根据某种算法将已有的数据（未来可能新增的数据），单独建立一个文件，文件能够实现快速的匹配数据，
并且能够快速的找到对应表中的记录。索引的意义在于：
1.提升查询数据的效率
2.约束数据的有效性（唯一性等）
增加索引有前提条件：索引本身会产生索引文件（有时候可能比数据文件还大），会非常消耗磁盘空间。
如果某个字段需要作为查询的条件经常使用，那么可以使用索引；
如果某个字段需要进行数据的有效性约束，也可能使用索引（主键，唯一键等）
mysql里面提供了很多索引：
1.主键索引：primary key
2.唯一索引：unique key
3.全文索引：fulltext key
4.普通索引：index
全文索引：
全文索引：针对文章内部的关键字进行索引，全文索引最大的问题在于如何确定关键字，英文单词很容易，英文单词
与单词之间有空格，中文很难没有空格，而且中文可以各种随意组合。（分词：sphinx）
关系：
将实体与实体的关系，反映到最终数据库表的设计上来：将关系分为三种：一对一，一对多（多对一）和多对多。所有的
关系都是表与表之间的关系。
一对一：一张表的一条记录一定只能与另外一张表的一条记录进行对应：反之亦然。
例如：学生表：姓名，性别，年龄，身高，体重，婚姻状况，籍贯，家庭住址，紧急联系人。可以设计成如下方式
表设计成以上的这种形式符合要求，但是姓名，性别，年龄，身高，体重属于常用数据；但是婚姻，籍贯，地址
和联系人属于不常用数据，如果每次查询都是查询所有数据，不常用的数据就会影响效率，实际又不用。
解决方案：将常用的和不常用的信息分离存储，分成两张表。
但是存在没办法匹配的问题，保证不常用信息与常用信息一定能够对应上，找一个具有唯一性（确定记录）的字段来共同连接两张表
一个常用表中的一条记录：永远只能在一张不常用表中匹配一条记录，反过来，一个不常用表中的一条记录在常用表中也只能
匹配一条记录，一对一的关系。
一对多：
一对多：一张表中有一条记录可以对应另外一张表中的多条记录，但是返回过，另外一张表的一条记录只能对应第一张表中的
一条记录，这种关系就是一对多或者多对一。
例如：母亲与孩子的关系：母亲和孩子两个实体
以下关系：一个妈妈可以在孩子表中找到多条记录（也有可能是一条），但是一个孩子只能找到一个妈妈，是一种典型的一对多的关系
但是以上设计：解决了实体的设计表问题，但是没有解决关系问题；妈妈找不到孩子，孩子也找不到妈妈。
解决方案：在某一张表中增加一个字段，能够找到另外一张表中的记录，应该在孩子表中增加一个字段指向妈妈
表，因为孩子表的记录只可以匹配到一条妈妈表的记录。
多对多：
多对多：一张表中（A）中的一条记录可以对应另外一张表中的（B）的多条记录，反之也成立。
例如：老师教学：老师和学生
以上设计方案：实现了实体的设计，但是没有维护实体的关系。
因为一个老师教过很多学生，一个学生有很多老师。
解决方案：在哪张表中增加字段，都会出现一个字段保存多个数据。而且是与其他表有关联，不符合表设计规范，增加一张
新表，专门维护两者的关系。增加中间表之后：中间表与老师形成了一对多的关系，而且中间表是多表，维护了唯一找到一
表的关系。同样的学生表与中间表是一对多的关系，一对多的关系可以匹配到关联表之间的数据。
学生找老师：找出学生ID--> 中间表寻找匹配记录（多条）-->老师表匹配（一条）
老师找学生：找出老师ID--> 中间表寻找匹配记录（多条）-->学生表匹配（一条）
范式：
范式：Nomal Format，是一种离散数学中的为了解决一种数据的存储与优化的问题的知识，保存数据的存储之后，凡是能够通过
关系寻找出来的数据，坚决不再重复存储，终极目标是减少数据的冗余。
范式是一种分层结构的规范，分为六层，每一层都比上一层严格，若要满足下一层范式，前提是满足上一层范式。
六层范式：1NF，2NF，3NF..6NF，1NF是最底层要求最低的，6NF是在最高层，要求也是最严格的。
MYSQL属于关系型数据库，有空间浪费也是致力于节省存储空间，与范式所有解决的问题不谋而合；在设计数据库的时候，会利用
到范式来指导设计。但是数据库不只要解决空间问题要保证效率问题。范式只为了解决空间问题，所以数据库的设计又不能完全按照
范式的要求来做，所以一般情况下只有前三种范式需要满足，满足3NF即可。
范式在数据库的设计当中是有指导意义，但不是强制规范。
1NF：第一范式
第一范式：在设计表存储数据的时候，如果表中设计的字段存储的数据，在取出来使用之前还需要额外的处理（拆分），那么
说表的设计不满足第一范式，第一范式要求所有字段的数据具有原子性，不可以再次拆分。
2NF：第二范式
第二范式：是指在数据表设计的过程中如果有复合主键（多字段主键），且表中有字段并不是由整个主键来确定，而是依赖
主键中的某个字段（主键的某个部分），存在字段依赖主键的部分的问题称之为部分依赖，第二范式 就是要解决不允许出现
部分依赖。
3NF：
要满足第三范式，必须满足第一和第二范式，第三范式理论上讲，应该一张表中的所有字段应该直接依赖于主键（逻辑主键：
代表的是业务主键，逻辑主键除外），如果表设计中存在一个字段并不直接依赖主键，而是通过某个非主键字段依赖，最终
实现依赖主键，把这种不是直接依赖主键而是通过依赖非关键字段的依赖关系称为传递依赖，第三范式就是来解决传递依赖的
问题。
范式（逆规范化）：
有时候在设计表的时候，如果一张表中有几个字段需要分别向其他表中去获取信息，理论上讲的确可以获取到指定的信息，但是
效率相对低下，会刻意的在某些表中，不去保存另外表的主键（逻辑主键），而是直接保存想要的数据，这样一来，在查询数据
的时候，一张表可以直接提供数据，而不需要多表查询（效率低），但是会导致数据冗余增加。
逆规范化：磁盘利用率与效率的对抗。