@mysql

mysql

innodb 和myisam的区别

1. innodb 支持事务，外键，myisam 不支持
2. innodb支持最小粒度锁为行锁，myisam支持表锁，所以并发不行
3. innodb是主键索引，叶子节点存放数据，myisam非主键索引，索引和数据和分开的
4. myisam适合读多写少的场景

mysql 执行过程

1. 客户端连接服务器
2. 词法分析
3. 语法分析
4. 优化器
5. 执行器

b树 和b+树的区别

1. b树所有的节点都存放数据和指针索引，导致一个节点存放的数据会很少，而b+树只有叶子节点存放数据，非叶子节点只存放指针
2. b树的查询是不稳定的，可能还没有到叶子节点查询会结束，b+树查询是稳定的
3. b树不能再叶子节点进行范围查找，而b+树是可以的

wal 是什么

先写日志，在写磁盘，顺序写磁盘，速度快，类似kafka
redo log 日志是物理的，比如某个页修改了什么，可循环写
binlog 是逻辑的，类似sql语句，追加写

crash-safe 是什么

innodb 通过写redo log，保证数据库发送异常重启，之前的数据不丢失,redo日志是inndb引擎独有的，而binlog 是mysql server层所有的 

两阶段提交

1. 先写redo日志
2. prepare
3. 在写binlog日志
4. commit

事务特性

1. 原子性
2. 隔离性
3. 一致性
4. 持久性

https://blog.csdn.net/baidu_3...

隔离级别：
1. 未提交读：  脏读
2. 已提交读：  不可重复读
3. 可重复度：  幻读
4. 串行化， 加锁排队

索引下推，覆盖索引

mysql日志

binlog

1. 主要记录mysql的逻辑日志，采用追加写的方式

2. 使用场景：1. 主从复制 2. 数据恢复

   redolog

3. mysql 采用先写日志，后写磁盘的方式，宕机的时候开业通过redolog来进行恢复
4. undo日志用于回滚

mysql的幻读其实分为两种情况

1. 当前读的幻读情况
   当前读select 永远读到的数据不会发生任何变化，通过mvvc实现
2. 快照读的幻读情况
   快照读通过锁实现，都已经锁住了，你插入个基基！
   A. select *from t;
   B. insert into t values(1)
   C. insert into t values(1)
   c报错：这种场景不是幻读，网上一顿瞎几把乱说的

这种查的时候是通过快照读的，插入的时候又是通过当前读，什么狗币东西！，网上一大堆概念错误，通过当前读和快照读的数据不一样，来表示幻读。
https://xie.infoq.cn/article/...

mysql 打断点

https://juejin.cn/post/684490...

mysql加锁是给索引加锁的，如果字段没索引就会给全表加索引

Field	Type	Null	Key	Default	Extra
id	int(1)	NO	PRI	NULL	auto_increment
name	varchar(8)	YES		NULL

INSERT INTO `test` VALUES ('100', '小罗');
INSERT INTO `test` VALUES ('500', '小黄');
INSERT INTO `test` VALUES ('700', '小明');
INSERT INTO `test` VALUES ('1100', '小红');

主键索引：
1. 如果是等值查询，且id存在则只会锁住一条记录
a: select *from T where id=100 for update;
b: insert into T values(200,'张三');
结果：能够正常插入

2. 如果等值查询，且id不存在，会锁住一个范围
a：select *from T where id=200 for update;

b: 插入的时候[100,500]的这个范围内都不能进行插入

1.  在普通索引列上，不管是何种查询，只要加锁，都会产生间隙锁，这跟唯一索引不一样！
2.  在普通索引跟唯一索引中，数据间隙的分析，数据行是优先根据普通索引排序，再根据唯一索引排序。

mysql为什么采用b＋数

1. b+数叶子节点存放数据，非叶子节点只存放指针，这样的话，非叶子节点能够存放更多的数据，导致数的高度变低，而磁盘查找效率主要又树的高度来决定。
2. 查询效率稳定的，因为根节点到叶子节点的路径是相同的
3. 叶子节点通过指针连接在一起，这样的话方便做范围查询

聚簇索引和非聚簇索引的区别

1. 聚簇索引的数据在物理是连续的，叶子节点存放的是数据【整行的值】，非聚簇索引数据不连续，叶子节点存放指针

为什么采用自增id

1. 如果数据是连续的，只要在后面插入数据就行
2. 不是连续的，假如插入的页满了，就需要出发页分裂，把其他数据拷贝到其他页，页分裂是很耗时的，数据会导致页的合并
3. 不用自增id用其他值得花会导致二级索引的叶子节点占用空间较大

注： b加数叶子节点其实存放的页，页里面在通过二分查找

而 MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。

事务

1. 隔离性
2. 原子性
3. 一致性
4. 持久性

事务的四种级别

1. 读未提交： 1个事务还未提交的时候他的变更会被其他事务看到
2. 读已提交 1个事务只有提交了，变更才会被看到
3. 可重复读 1个事务在执行的过程中看到的数据是一样的
4. 串行： 读写会加锁

在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

mvcc实现方式

写新数据的是把旧数据放到其他地方，比如房到回滚段中，其他人读数据的时候从回滚段读数据

https://zhuanlan.zhihu.com/p/...
start transaction with consistent snapshot;

1. b+树叶子节点存放数据，非叶子节点存放指针
2. 主键索引叶子节点的value存放的是行的信息
3. 非主键索引的value值存放的是主键信息
4. hash索引不适合不适合范围查询
5. hash索引没办法走最左匹配
6. 大量重复的key，value的话，索引效率低，有冲突
7. b+数叶子节点有指针，方便进行范围查询
8. 聚簇索引的索引就是数据存储的物理顺序

数据是存放在磁盘上的，为了提高数据的查找效率的，只能降低io次数