Mysql

Mysql服务端结构

连接器： 管理数据库连接,权限验证
解析器： 词分析，语法分析，拆分SQL，将from，where等拆分成AST抽象语法树
优化器： CBO成本优化，RBO规则优化，决定走什么索引，最终的执行计划
执行器： 按AST树顺序执行SQL，操作引擎，返回结果

行式存储： 按数据行存储，InnoDB，Myisam
列式存储： 按列存储，如ORC,Parquet
存储引擎： 文件在磁盘不同的组织形式

存储引擎有哪些，区别是什么？
Memory：临时存放数据，数据量不大
Archive：适合归档数据，如记录日志等

查询缓存是什么？
MySQL8.0版本前存在，将查询结果进行缓存，后面就取消了，因为数据经常更新导致数据失效，命中率比较低

InnoDB	Myisam
支持事务	不支持
支持行锁，表锁	支持表锁
有聚簇索引	没有聚簇索引
不支持全文索引	支持全文索引
支持树索引	支持树索引
支持数据缓存	不支持数据缓存
支持外键	不支持外键

MySQL执行计划怎么看？重要参数？
https://blog.csdn.net/qq_38969734/article/details/124053731

Mysql 语法顺序：

select[distinct]  
from  
join（如left join）  
on  
where  
group by  
having  
union  
order by  
limit

MySQL执行顺序：

from  
on  
join  
where  
group by  
having  
select  
distinct  
union  
order by  

索引

索引存在文件中还是内存中？
索引存在文件中，

索引在数据读取的时候要返回什么信息？
可能返回表的行数据（聚簇索引），可能返回聚簇索引（非聚簇索引），可能返回数据地址（myisam）

知识点： 磁盘与内存交互是按页读取
一般每页4k或8k，MySQL默认读16k
优化就是减少IO次数，或者IO数据量
MySQL5.7前没有索引下推就是第一个条件查出数据，后续条件在内存中处理过滤
5.7后默认开启索引下推，第一个，第二个条件都是在存储引擎中过滤，减少数据IO量

索引为什么不像hive一样存在 key值——文件名称—— offsset?
性能太差

OLTP,OLAP区别？
联机事务处理： 频繁的增删改查
联机分析处理： 一般是大数据分析

MySQL如何设计索引系统？
数据格式：k-v
数据结构：hash，树

MySQL应用什么数据结构？
B+树

为什么innodb,myisam不用hash结构？
用hash结构，有几个点
1. 有一个足够大容量的数组
2. hash分布不均匀
3. hash冲突会导致查询性能降低
4. 无序，范围查询性能差

为什么树一定要用 B+ 树？
Hash表 ：适合等值查询，但是数据量大时，发生hash冲突，效率会下降，范围查询时只能全表查询，Memory引擎使用，但由于在内存中操作，所以可以忽略IO耗时

树索引结构	IO次数	磁盘预读	范围查找	缺点	使用场景
二叉查找树	若数据倾斜，树会很高	每个节点不能填满4K内容，浪费	根节点多次遍历	左小右大，数据有序时，容易发生数据倾斜，退化成线性链表	最基础的二叉树，一般都是使用它的变种
AVL树	树的高度就是IO次数，而两个节点存储数据少树会很高	每个节点不能填满4K内容，浪费	根节点多次遍历	每次插入，更新都要旋转树，开销很大	查询性能很高，但是频繁插入开销大
B树（B-树）	非叶子结点也有数据，树较高	一个节点大小设为16K,可充分利用IO	根节点多次遍历	非叶子结点存数据，树比较高，不支持范围查询	MongoDB
红黑树	数据量巨大的场景下，树会高一点	每个节点不能填满4K内容，浪费	根节点多次遍历	大数据也会存在轻量的数据倾斜，不支持范围查询	HashMap，相比其他树插入开销有所减少
B+树	只在叶子节点存储数据，树相对较低	一个节点大小设为16K,可充分利用IO	叶子节点之间使用双向指针连接，最底层的叶子节点形成了一个双向有序链表。	适合大数据索引查询	InnoDB，Myisam

注：只有红黑树和普通的二叉查找树不能保证所有叶子节点同一高度

红黑树和AVL树有什么区别？
AVL平衡二叉树，每次插入更新都要旋转树结构，开销很大；红黑树不追求完全平衡，可以在保证大致平衡的基础上减少旋转的开销，最多三次旋转，而查询最多也只是多比较一次而已

注： 提高查询性能就是减少IO，减少IO次数或者量

为什么性别不适合建索引？
如果key值大量重复，肯定是非聚簇索引，叶子结点存的是聚簇索引，会产生回表，可能全表查询相对起来效率更高，而且索引也会占用空间

索引分类：
主键索引
唯一索引
普通索引
全文索引
组合索引

一个组合索引只有一棵树

回表： 通过普通索引IO找到聚簇索引，再根据聚簇索引的B+树去查表（这是一个可优化的点）

索引覆盖： 通过普通索引直接检索到聚簇索引，直接返回聚簇索引而不用再次走聚簇索引的IO去获取聚簇索引

USING INDEX : 执行计划出现这个说明存在索引覆盖，开心，如果没有想可不可以有

最左匹配： 必须找到前置列，后续列才会有序才有意义

存在问题： 如果前面的列判断存在<或>那么会阻断后面的列，如果是<=或>=则不会，这也是索引列失效的一种情况。

索引下推： 5.7版本后将索引在存储引擎中进行过滤而不是内存中，发现using index condition就是索引下推，例：5.7之前第一个过滤在存储引擎中，第二个在内存中，5.7后都在存储引擎中减少IO量

小知识： 隐式类型转化，会导致索引失效

聚簇索引： B+树的叶子结点存的是数据就是聚簇索引
非聚簇索引： B+树的叶子结点存的是地址就是
聚簇索引选择： 主键》唯一键》Rowid
选择过程： 如果第一次没设主键，导致rowid作为聚簇索引的话，后面设置主键会导致地址重排，将主键改为聚簇索引，解决的一个问题就是，如果主键只是普通索引的话会进行双倍IO

小知识：

字符串按字典序排序
SQL server 有binlog
innodb有redolog undolog