mysql笔记

一、MySQL语句执行情况
1、客户端请求-连接器-server层执行（命中就执行查询缓存，没有命中就执行分析器——优化器优化sql语句——执行器执行sql）——调用引擎执行
2、MySQL8.0去除查询缓存（对于频繁操作更新、新增数据库）维护缓存代价搞高
3、分析器分析sql语句的正确性等、优化器优化sql语句（如使用索引等）、执行器执行优化后的sql语句
二、数据结构
二叉树
红黑树（二叉平衡树）
B树
B+树
三、数据存储引擎
1、MySMI（非聚集索引）
2、InnoDB（聚集索引）
叶节点包含所有的记录
推荐使用自增主键唯一索引（未设置，MySQL自动寻找数据唯一列或者创建虚拟列维护唯一索引）
3、hash索引
范围查找性能差，精确查找性能高
四、索引（排好序的数据结构）
主键索引推荐id自增，避免新增数据时索引分裂重组
五、数据库的读写分离
1、数据同步：主节点执行sql语句同时生成binlog日志文件，从数据库使用IO线程将binlog文件读写到中间文件，然后sql线程执行中间文件sql同步数据
全同步、半同步
主从模式、级联模式、主主模式、一主一从等
六、MySQL日志文件，binlog （归档日志）,redo log(重做日志)
redo log innodb引擎所拥有的，具有crash-safe能力（宕机恢复）
特点：内存空间有限，在进行更新操作时，会记录当前已提交操作（如临时记账账本，在数据库空闲时间或合适时间会进行磁盘更新操作）
不解问题：1、查询时是直接会与redo log 日志交互吗？在为进行磁盘数据同步时会不会影响数据一致性问题？；
2、什么时候会触发同步磁盘行为。
binlog是server层实现，并非引擎独有；
特点：日志记录为追加记录，记录更新操作的相关具体行为。
执行器更新流程：执行器先将更新数据更新到内存中，同时将更新操作更新到redo log中并处于准备就绪状态，随时可以提交，这时执行器将更新操作过程记录到binlog日志中，最后执行器提交事务将redo log改为commit状态
3、事务的隔离级别
读未提交：不同事务之间可以读到还未提交的数据
读已提交：不同事务之间只可以读到已经提交的数据
可重复读：可以读取事务过程中的数据但数据不变
串行化：读写加锁
不解问题：不同事务隔离级别是如何实现的，怎么设置可读和不可读的？
4、索引，
hash索引：查询快，维护方便，但区间范围，模糊查询等效率低，需要进行全表扫描
B+树：平衡多叉树，查找快，索引维护相对复杂，存在索引页分裂等问题。所以索引也不适合建多；
联合索引的作用（如身份证、姓名）：可以减少第二索引检索范围，以及回表读取行为。（有利于联合搜索条件查询，不利于但条件查询）
缺陷：索引维护相对复杂，遵循最左前缀原则；
5、mvcc多版本并发控制
实现事务隔离的实现（读提交和可重复读两种隔离级别）
innodb每个事务都有一个事务id（严格自增）,且会保留旧事务id
实现上是：innodb为每个事务创建了一个事务id数组，由低水位到高水位，当前事务只能看到以及提交的就事务数据和自己修改的数据（根据事务id大小判断事务新旧）
在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询 都共用这个一致性视图；
在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。
对于可重复读，查询只管在执行前就已经提交完成的数据；
对于读提交，查询只管在语句执行前就已经提交完成的数据；
6、数据库刷新脏页：redo log内存不足；MySQL相对空闲；统一处理，定期刷新