Mysql复习

数据库的三范式

第一范式1NF：数据库表中的字段都是单一属性的，不可再分
第二范式2NF：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖，即符合第二范式
第三范式3NF：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合3NF

char 和 varchar 的区别

定长和变长
char 表示定长，长度固定，varchar表示变长，即长度可变。char如果插入的长度小于定义长度时，则用空格填充；varchar小于定义长度时，还是按实际长度存储，插入多长就存多长。
因为其长度固定，char的存取速度还是要比varchar要快得多，方便程序的存储与查找；但是char也为此付出的是空间的代价，因为其长度固定，所以会占据多余的空间，可谓是以空间换取时间效率。varchar则刚好相反，以时间换空间。
存储的容量不同
对 char 来说，最多能存放的字符个数 255，和编码无关。
而 varchar 呢，最多能存放 65532 个字符。varchar的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是 65,532字节。

哪些情况需要创建索引，哪些情况不需要创建索引

需要创建索引
1.主键自动建立唯一索引
2.频繁作为查询条件的字段应该创建索引
3.查询中与其他表关联的字段，外键关系建立索引
4.单键/组合索引的选择，who？（在高并发下倾向创建组合索引）
5.查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
6.查询中统计或者分组字段
不需要创建索引
1.表记录太少
2.频繁更新的字段不适合创建索引
3.Where条件里用不到的字段不创建索引
4.数据重复且分布平均的表字段，为它建立索引没有太大的效果

为什么mysql用B+树做索引而不用B-树或红黑树

一，B+树做索引而不是用B-树

mysql如何衡量查询效率？–磁盘IO次数

一般来说索引非常大，尤其是关系型数据库这种数据量大的索引能达到亿级别，所以为了减少内存的占用，索引也被存储在磁盘上。B-tree和B+tree的特点就是每层节点数目非常多，层数很少，目的就是为了减少磁盘IO次数，但是B-tree的每个节点都是data域（指针）这无疑增大了节点大小，说白了增加量磁盘IO次数（磁盘IO一次读出的数据量大小是固定的，单个数据变大，每次读出的比之前少，IO次数增多），而B+树除了叶子结点其它节点并不存储数据，节点小，磁盘IO次数就少。

• 优点一：B+树只有叶节点存放数据，其余节点用来索引，而B-树是每个索引节点都会有Data域。
• 优点二：B+树所有的Data域在叶子节点，并且所有叶子结点之间都有指针。这样遍历叶子结点就能获得全部数据，，这样就能进行区间访问了。在数据库中基于范围的查询是非常频繁的，而B树不支持这样的遍历操作。

二：B+树做索引而不用红黑树

AVL树和红黑树基本都是存储在内存中才会使用的数据结构。在大规模数据数据存储的时候，红黑树往往出现由于树的深度过大而造成磁盘IO读写过于频繁，进而导致效率底下的情况。

谈下什么是前缀索引

当索引是很长的字符序列时，这个索引将会很占内存，而且会很慢，这时候就会用到前缀索引了。所谓的前缀索引就是去索引的前面几个字母作为索引，但是要降低索引的重复率，索引我们还必须要判断前缀索引的重复率。

什么情况下索引会失效？即查询不走索引

• 最左前缀法则（复合索引中间字段不能缺失，否则后面索引失效）
• 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换，会导致索引失效而转向全表扫描
• 在使用不等于( != 或者 <> )时候无法使用索引
• is null,is not null也无法使用索引
• like以通配符开头（‘%abc…’)mysql索引失效
• 字符串不加单引号索引失效
• 少用or，用它来连接时会索引失效

InnoDB 和 MyISAM 的比较

主从复制中涉及到哪三个线程

1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；

2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中；

3. 从：sql执行线程——执行relay log中的语句；

如何实现 MySQL 的读写分离？

基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。

MySQL 的主从复制原理是什么？

主库将变更写binlog日志，然后从库连接到主库后，从库有一个I/O线程，将主库的binlog日志拷贝到本地，写入一个中继日志
接着从库中有一个SQL线程会从中继日志读取binlog，
然后执行binlog日志中的内容，即在本地再次执行一遍SQL，确保跟主库的数据相同

这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。

而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

所以 MySQL 实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据丢失问题；一个是并行复制，用来解决主从同步延时问题。

这个所谓半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了。

所谓并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

如何解决 MySQL 主从同步延迟问题？

通过 MySQL 命令：

show status

查看 Seconds_Behind_Master，可以看到从库复制主库的数据落后了几 ms。

一般来说，如果主从延迟较为严重，有以下解决方案：

• 分库，将一个主库拆分为多个主库，每个主库的写并发就减少了几倍，此时主从延迟可以忽略不计。
• 打开 MySQL 支持的并行复制，多个库并行复制。如果说某个库的写入并发就是特别高，单库写并发达到了 2000/s，并行复制还是没意义。
• 重写代码，写代码的同学，要慎重，插入数据时立马查询可能查不到。
• 假如你的业务时间允许，你可以在写入主库的时候，确保数据都同步到从库了之后才返回这条数据写入成功，当然如果有多个从库，你也必须确保每个从库都写入成功。显然，这个方案对性能和时间的消耗是极大的，不推荐。
• 可以引入redis或者其他nosql数据库来存储我们经常会产生主从延迟的业务数据。当我在写入数据库的同时，我再写入一份到redis中。然后用户去读取数据的时候发现没有读取到这个数据，那么我们就可以再去查看redis中是否有这个数据，如果有我们就可以直接从redis中读取这个数据。当数据真正同步到数据库中的时候，再从redis中把数据删除。
• 任何的服务器都是有吞吐量的限制的，没有任何一个方案可以无限制的承载用户的大量流量。所以我们必须估算好我们的服务器能够承载的流量上限是多少。达到这个上限之后，就要采取缓存，限流，降级的这三大杀招来应对我们的流量。这也是应对主从延迟的根本处理办法。
• 如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置直连主库。不推荐这种方法，你要是这么搞，读写分离的意义就丧失了。

InnoDB 什么时候使用行级锁？什么时候使用表级锁？

InnoDB行锁是通过索引上的索引项来实现的，这一点ＭySQL与Oracle不同，后者是通过在数据中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味者：只有通过索引条件检索数据，InnoDB才会使用行级锁，否则，InnoDB将使用表锁
在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。 在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。

Mysql show processlist 排查问题
更多复习