Mysql相关知识点

范式

三大范式

• 第一范式(1NF)：每个列都不可以再拆分。
• 第二范式(2NF)：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。
• 第三范式(3NF)：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。

第一范式

第二范式

我们先分析一下表结构。

1. 假设学号是表中的唯一主键，那由学号就可以确定姓名和年龄了，但是却不能确定课程名称和成绩。

2. 假设课程名称是表中的唯一主键，那由课程名称就可以确定学分了，但是却不能确定姓名、年龄和成绩。

3. 虽然通过学号和课程名称的联合主键，可以确定除联合主键外的所有的非主键值，但是基于上述两个假设，也不符合第二范式的要求。

第三范式

反三大范式

空间换时间

B树以及B+树区别

区别：
1.非叶子节点并不存储真正的 data
2.为所有叶子结点增加了一个链指针

为什么采用B+树

1.B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。
2.B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
3.由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

聚簇索引和非聚簇索引

非聚簇索引

如果索引值和行记录分开存放就属于非聚簇索引。

聚簇索引

B+Tree的叶子节点存放主键索引值和行记录就属于聚簇索引。

主键索引和辅助索引

主键索引

B+Tree的叶子节点存放的是主键字段值就属于主键索引；

辅助索引

如果存放的是非主键值 就属于辅助索引（二级索引）。

在InnoDB引擎中，主键索引采用的就是聚簇索引结构存储。

索引类型

普通索引

联合索引

组合索引，区分度高的，查询度高的在前面；
根据where 条件来确定 ; 最左匹配原则

覆盖索引

一个索引包含（或者说覆盖）所有需要查询的字段的值

select * from tableA join (
select a as tempa from tableA where c like '%CDS1606080014%'
) b on tableA.a= b.tempa；

强制索引

force index(indexa,indexb)

强制索引并不会百分百生效，特别是有排序的情况；允许多个，但是不会两个都使用（索引合并）
可以采用union方式来使用多个索引

排序

MySQL可以使用同一个索引满足排序(ORDER BY)和查询(WHERE)操作,因此如果可以，设计索引的时候尽可能考虑同时满足两种任务
前提
只有当索引列顺序和ORDER BY的列顺序完全一致
如果存在表关联，则只有当ORDER BY引用的字段全部为第一个表是，才能使用索引排序
最左前缀
例外
有一种特殊的情况即使不满足最左法则，MySQL也能通过索引来实现排序，如果WHERE或者JOIN中对索引中某些列指定为常量，那么可以弥补这个最左法则！

索引失效

之前的文章已经有了，就不再重述索引失效

存在哪几种锁

按照对数据操作的锁粒度来分：行级锁、表级锁、页级锁、间隙锁
按照锁的共享策略来分：共享锁、排他锁、意向共享锁、意向排他锁
共享锁和排他锁在MySQL中具体的实现就是读锁和写锁
意向共享锁:当事务准备在某条记录上加共享锁锁时，需要先在表级别加一个意向共享锁锁。
意向排他锁:当事务准备在某条记录上加排他锁时，需要先在表级别加一个意向排他锁锁。
从加锁策略上分：乐观锁和悲观锁