数据库优化，设计表的三范式、数据库引擎选择、索引设计

1、什么是三范式

设计关系型数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系型数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。一般来说，数据库只需要满足第三范式就行了。

第一范式：保证每列的原子性--属性不可再分

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库满足了第一范式。

第一范式需要根据系统的实际需求来定，比如有一张用户信息表：

一般来说"住址"设计成一个字段就行，但是如果经常访问"住址"中城市的部分，那么就非要将"住址"这个属性重新拆分为"省份"、"城市"、"地址"等多个部分进行存储，这样在对"住址"中某一部分进行操作的时候将非常方便。这么设计才算满足了数据库的第一范式，修改之后的表结构如图：

第二范式：保证一张表只描述一件事情　　--比如用户信息表中不包含积分

这是通俗的说法，用第二范式的定义描述第二范式，说的是在满足第一范式的基础上，数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖，也即所有非关键字段都完全依赖于任一组候选关键字。

看不懂是吗，没关系，我也看不懂，下面举一个例子，有一张表如下图：

上表满足第一范式，即每个字段不可再分，但是这张表设计得并不好，或者说，这张表的设计并不满足第二范式。因为这张表里面描述了两件事情：学生信息、课程信息，"学分"完全依赖于"课程名称"、"姓名"与"年龄"完全依赖于"学号"。这么做的后果是：

1、数据冗余：同一门课程由n个学生选修，"学分"重复n-1次；同一个学生选修了m门课程，姓名和年龄重复m-1次

2、更新异常：若调整了某门课程的学分，数据表中所有行的"学分"值都需要更新，否则会出现同一门课程学分不同的情况

3、插入异常：假设要开一门新课程，暂时没有人选修，那么由于没有"学号"关键字，"课程"与"学分"也无法记录入数据库

4、删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，"课程"和"学分"也被删除了，显然，这最终可能会导致插入异常

所以，此表的结构必须修改，修改后如下：

增加了表，将学生信息与课程信息通过一张中间表关联，很好地解决了上面的几个问题，这就是第二范式的中心----保证一张表只讲一件事情。

第三范式----保证每列都和主键直接相关

第三范式又和第二范式相关，用第三范式的定义描述第三范式就是，数据库表中如果不存在非关键字段任一候选关键字段的传递函数依赖则符合第三范式，所谓传递函数依赖指的是如果存在"A-->B-->C"的决定关系，则C传递函数依赖于A。也就是说表中的字段和主键直接对应不依靠其他中间字段，说白了就是，决定某字段值的必须是主键。

举个例子，看一下如下的表结构：

第三范式和第二范式有点像，从这张数据库表结构中可以看出，"姓名"、"年龄"、"学院"和主键"学号"直接关联，但是"学院地点"、"学院电话"却不直接和主键"学号"相关联，和"学院电话"直接相关联的是"学院"，如果表结构这么设计，同样会造成和第二范式一样的数据冗余、更新异常、插入异常、删除异常的问题。

修改之后的表结构如下图：

 

 

2、存储引擎的选择：MyISAM和InnoDB

1. 是否支持行级锁 : MyISAM 只有表级锁(table-level locking)，而InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。
2. 是否支持事务和崩溃后的安全恢复： MyISAM 强调的是性能，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。但是InnoDB 提供事务支持，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
3. 是否支持外键： MyISAM不支持，而InnoDB支持。
4. 是否支持MVCC ：仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一
5. BTree索引的区别：MyISAM: B+Tree叶节点的data域存放的是数据记录的地址；InnoDB: 其数据文件本身就是索引文件

3. 索引

　　a.为什么要使用索引

1. 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
2. 可以大大加快 数据的检索速度（大大减少的检索的数据量）, 这也是创建索引的最主要的原因。
3. 帮助服务器避免排序和临时表。
4. 将随机IO变为顺序IO
5. 可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

　　b.索引不宜过多

1. 当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
2. 索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
3. 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

　　首先Mysql的基本存储结构是页(记录都存在页里边)：

 

 

 　　

 

• 各个数据页可以组成一个双向链表
• 而每个数据页中的记录又可以组成一个单向链表
  • 每个数据页都会为存储在它里边儿的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录
  • 以其他列(非主键)作为搜索条件：只能从最小记录开始依次遍历单链表中的每条记录。

　　c.索引的实现

索引做了些什么可以让我们查询加快速度呢？

其实就是将无序的数据变成有序(相对)：下面B数索引的实现：，B+数是将数据都放在叶子节点上

 

 

要找到id为8的记录简要步骤：

 

 

很明显的是：没有用索引我们是需要遍历双向链表来定位对应的页，现在通过**“目录”**就可以很快地定位到对应的页上了！

其实底层结构就是B+树，B+树作为树的一种实现，能够让我们很快地查找出对应的记录

原则：

• 1，最左前缀匹配原则。这是非常重要、非常重要、非常重要（重要的事情说三遍）的原则，MySQL会一直向右匹配直到遇到范围查询（>,<,BETWEEN,LIKE）就停止匹配。
• 3，尽量选择区分度高的列作为索引，区分度的公式是 COUNT(DISTINCT col) / COUNT(*)。表示字段不重复的比率，比率越大我们扫描的记录数就越少。
• 4，索引列不能参与计算，尽量保持列“干净”。比如，FROM_UNIXTIME(create_time) = '2016-06-06' 就不能使用索引，原因很简单，B+树中存储的都是数据表中的字段值，但是进行检索时，需要把所有元素都应用函数才能比较，显然这样的代价太大。所以语句要写成 ： create_time = UNIX_TIMESTAMP('2016-06-06')。
• 5，尽可能的扩展索引，不要新建立索引。比如表中已经有了a的索引，现在要加（a,b）的索引，那么只需要修改原来的索引即可。
• 6，单个多列组合索引和多个单列索引的检索查询效果不同，因为在执行SQL时，MySQL只能使用一个索引，会从多个单列索引中选择一个限制最为严格的索引。

作者：Java3y
链接：https://juejin.im/post/6844903645125820424
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。