本文章主要是以线性的方式引入MYSQL的原理，从梳理到快速记忆，做到过目不忘的效果。

MYISAM和INNODB的区别

	MYISAM	INNODB
事物支持	不支持	支持
数据行锁	无	有
外键约束	不支持	支持
全文索引	支持	不支持
表空间	小	大（两倍）

区别速记

MYISAM 是轻量级、效率高，支持全文索引，但不安全
INNODB 安全，支持事物
MYISAM的索引和数据是分开存储的，索引文件只存放了行的主键（这种方式叫做聚簇索引）

物理空间的位置

所有的数据库文件都存放在data目录下，本质还是文件的存储
-INNODB 在数据库表中只有一个.frm文件，以及上级目录下的ibdata1文件
-MYISAM 对应的文件，.frm ,.MYD ,.MYI

聚簇索引和非聚簇索引的区别（KEY：是否能直接找到行数据）

1.聚簇索引和非聚簇索引的区别，其实就是MYISAM和INNODB对索引实现的方式的区别
2.从空间上看：聚簇索引将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据，
非聚簇索引将数据与索引分开存储，索引结构的叶子节点指向了数据对应的位置
3.在innodb中，在聚簇索引之上创建的索引称之为辅助索引，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引。辅助索引叶子节点存储的不再是行的物理位置，而是主键值，辅助索引访问数据总是需要二次查找。
引出 MYISAM 和INNODB的索引实现方式，索引的类型，索引的数据结构演变

MYISAM 和INNODB的索引实现方式

MYISAM  索引文件和数据文件 是分离的，通过索引查询只能查询到 数据文件的地址
INNODB 索引文件和数据文件是聚集的，能直接通过主键索引查询到行数据。
引出：辅助索引 -> innodb 的非主键索引，是先查找到主键索引，再回表搜索数据行的。

索引的类型 （HASH&B+）

哈希索引通过哈希的一致性算法，计算主键的哈希值 。缺陷：hash碰撞，不支持范围搜索
B+索引：以B+树的形式存储数据结构、支持范围搜搜。 
引出B+索引的发展史

索引的数据结构演变

二叉树 ：缺陷 ，顺序插入时，退化为链表。查询效率不稳定
红黑树 ：通过自选在一定程度上解决了平衡问题，但依旧存在右倾，高度是递增的
AVL树:：绝对平衡树  ，解决了高度问题。缺陷：一次只能读取一个数据。
B树：每个节点多存放几个数据，一次性取出多个数据。缺陷：数据一起存放在子节点中，有点。
B+树：只有叶子结点才会存放data数据，并且将最终子节点，连接上了

Mysql 事物的基本要素（ACID，原一隔持）

原子性（Atomic）一个事物，要么所有执行成功，要么全失败，当做成一个不可分割的概念
一致性（Consistent）数据处于一种有意义的状态。是语义上的，也是最终目的。（转账， ++，--必须同步）
隔离性（Isolation） 同一时间只允许一个请求，不同的事物不能有干扰
持久性（Durability）事物完成后，事物对数据库的所有更新都保存到数据中，不能回滚

Mysql 事物并发问题

1.脏读，事物A读取到了B事物中的过程数据（非最终结果）
2.重复读，事物A读取到了B事物中的过程数据（B操作了多次，导致每次结果不一样，A全部读取到了）（注重点在修改）
3.幻读，事物A没有接收到事物B的新增/删除的操作导致数据，多/少（注重点在 删除和插入）

Mysql支持的事物隔离级别(可以解决哪些并发问题)（速记：对角线分割）

事物隔离级别	脏读	重复读	幻读
读未提交（read-uncommitted）	是	是	是
读已提交（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

如何记忆？（按时间顺序记忆）
读取B线程未提交的数据会导致  脏读（读已提交能解决脏读）
读取B线程已经提交的数据会导致 重复读（可重复读，能解决重复读）
无法读取到B线程新插入/删除的记过  幻读 （串行化能解决 所有）

Mysql实现可重复读，读已提交（MVCC，Multi-Version Concurrency Control （ PS： 不同于MVC和前端的MVVM））

MVCC 只在 读已提交、可重复读两种隔离级别工作
如何实现的呢？ 增加版本号
insert 保存当前事物的系统版本号
delete  存放当前系统版本号，作为删除标记
update 原数据：插入一行新数据版本号为系统版本号。旧数据 存放当前系统版本号，作为删除标记
select 
  1.仅仅查找版本号小于等于当前事物版本号的数据
  2.行的删除版本要么未定义，要么大于当前事物版本号。

PS：MVCC在一定程度上解决了幻读，（但，如果 先 commit  create ，当A线程执行更新对应的语句后，再次select 依旧会出现幻读）

image.png

快照读和当前读

select 快照读
  当select执行以前的，任何操作，都可以监听，一旦select执行，就无法监听 之后的 事物提交了
  比如说：（第一次select  会存储快照  也就是 select * from id >10）如果此时插入 id=11 是无法获取的
  当前读（update，insert（无所谓），delete），在update user set age =18 where name ="zs"
 中，一定获取的是最新版本的记录。（并更新为当前事物版本，因此，更新后，再次select就能查询到数据了，因为 update的新版本已经更新为当前版本， 删除版本号为null）

引发的问题：如果 修改数据都是获取到最新版本的操作。会引发冲突 => X锁，或者是next-key锁解决（上锁，避免同时修改）

PS ：
情况一：
假设目前有2个会话
会话A：开启事物 (update t set name = 'ls' where id = 1)
会话B：开启事物（update t set name = 'zs' where id = 1）
  此时会产生排它锁 => 阻塞，必须等待其中一个会话释放才能进行。
情况二：
假设目前有2个会话
会话A：开启事物  select * from t;  update t set c = c+1; select * from t;  
会话B：不开启事物（update t set c = c+1;）
结果  会话A结果 取到了会话B的值  因此 c=3；
结论：update、delete  都是当前读、select 可以添加   select xx for update  或则 select XX for share mode 

MYSQL查询过程

select
1.客户端发起查询请求（select） -> 2.查询缓存（命中则直接返回） -> 3.语法解析器和预处理器（分析语法、词法，是否合理）->4.查询优化器（索引覆盖，中断查询。）返回查询执行计划（数据结构，指令树）->5.查询执行引擎（INNODB 、MYISAM） ->6.调用api接口并并返回数据
2.快速记忆，头尾缓存不用记（请求必须要有发起和结束，查询缓存很正常）：只需要记住三步：语法解析和预处理，内部优化，查询执行引擎
update（举例说明redo log和binlog在update T set c=c+1 where ID=2;时是怎么工作的）
1.查询缓存
2.更新，写内存
3.写redo.log 
4.写binlog
5.提交事物

回顾SELECT执行顺序： [from、join]、[on,where],[group by ,having ] ,select、distinct、order by、limit 
小记：
select （先查询）、distinct（去重）、order by（排序）
on（先关联表）、where（过滤数据）、group by（分组） ，having（分组数据过滤）
引出 redo log（重做日志）和 binlog（归档日志）

image.png
image.png

binlog（归档日志）和 redo log（重做日志）

1.binlog 记录mysql的写入性操作（PS：与引擎无关，任何殷勤都有，是在服务层进行写入的）
  引入：逻辑日志（sql操作）&物理日志（具体的数据行） 对比redis（因为是二进制，因此叫做bin log）
  作用：数据恢复、主从复制
  刷盘时机：sync_binlog 控制，（0,1[默认]，N，N代表事物个数）写入磁盘
  binlog的日志格式： statement（sql，批量更新时，只会记录单条），row（无上下文的sql，批量更新，会新增N条记录）、 mixed（两者混合）
2.redo log
  引入：MYSQL如何保证持久性 -> 每次提交事物时，就将数据写入盘中 => 结果，INNODB是按页提交，修改的仅仅是一部分数据浪，费资源，并且一个事物是多个数据页，需要进行随机IO，性能差 => redo log 优化，解决资源和性能的问题。
  作用：实现mysql的原子性，并提供性能，降低资源消耗（引入关键字：write ahead log(写前日志)）
  刷盘时机（参数配置）：先写内存 批量提交都磁盘（先写入OS buffer，在写入到redo file），
innodb_flush_log_at_trx_commit （0,1,2） 
理解方式：  （0，commit，后续都是按秒写入）写入内存（2，commit，写入内存既可提交事物）-- 写入磁盘 （1，commit，都写完才提交事物）  
 3.undo log
  引入：delete时，如何回滚？ redo log 仅仅记录了 delete操作 => undo log ，反向操作，以便回滚。（更新操作是如何回滚的？）
  作用：回滚，多个行版本控制MVCC
flush阶段、sync阶段、commit阶段。

image.png
image.png

Mysql 锁

分类 --行锁（INNODB）&表锁（MYISAM为主）

1.无锁
    索引不存在
    select * from user where id = -1 for update;
2.行锁
    INNODB实现的行锁，是基于索引的，也就是当查询条件包含索引时才会添加行锁，否则添加的就是表锁
    索引明确
    select * from user where id = 1 for update;
    select * from user where id = 1 and name = 'kk' for update;
3.表锁
    索引不明确
    select * from user where name = "zs" for update;
    select * from user where id !=3 for update;

锁算法（锁机制：粒度-实现）

1.行锁算法
    record lock 普通行锁
        ·键值在条件范围内
        ·记录存在
    gap lock 间隙锁
        ·对于键值不存在条件范围内，叫做间隙，引擎会对 这个间隙加锁
    next-key lock （行&间隙锁，可能会降级为行锁。）
         ·键值在条件范围内，同时又不在条件范围内。
          ·select * from user id >49 for update ; //id只有50
2.表锁算法
  意向锁（升级机制）
  1.当一个事物带着表锁去范恩一个被加了行锁的资源，行锁会升级为表锁。（升级）
  2.举例如下：
      select * from user where id = 10 for update ;  //事物A(行锁，此时升级为意向锁，将表锁住)
      select * from user where name like 'zs%' for update ;  //事物B (表锁)
  自增锁
    1.事物插入增增类型的列时，会获取自增锁
    2.如果一个表正在插入自增记录，其他事物必须等待

Mysql锁的实现

共享锁&排它锁
  行锁和表锁是粒度的概念，共享锁和排它锁是具体的实现

共享锁（S Share）：（不仅仅是读锁）
  允许一个事物去读一行，组织其他事物去获取改行的排它锁
排它锁（X  Exclusive ）：写锁
  允许持有排它锁的事物读取写数据，阻止其他事物获取该资源的共享锁和排它锁
  不能获取任何锁，但不代表不能读
注意点
  某个事物获取数据的排它锁，其他事物不能获取该数据的任何锁，并不代表其他事物不能无锁读取该数据
  无锁  select ... from ..
  共享锁 select ... lock in share mode => 增设了 for share skip locked跳过锁  ，可以高效的实现等待队列（Mysql 8.0）
  排它锁 update、delete、insert、select

乐观锁&悲观锁

乐观锁
  一般通过版本号进行更新行
  update set xx ='x' where id =1 and version = 1;
悲观锁
  如果一个事务执行的操作读某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作（比如说库存的超卖） select * from xx for update;
  

Mycat（ShareDB）

在集成mycat之前，可以先考虑分区


RXC方案与Replication方案
RXC  必须所有节点都写入，才提交，写入慢，但更可靠
Replication 其他节点延时提交。

主键生成算法：
1.雪花算法，生成 有序整数（推荐）
2.UUUID ，无序字符串（不利于索引书创建）
3.取余算法（无法动态扩容）

后续可以整合 keepalived +HAProxy  做到高可用

总结

希望通过自己的文章，能将大家的MYSQL知识，串联起来，加深理解（巩固），喜欢的朋友可以点个赞，若是有不错的文章也可以推荐一下。谢谢大家的支持。（知识积累的差不多了，后续会继续 细化这些原理，配上测试案例。达到小白入门即学会。）