mysql架构及历史
逻辑架构
通常为三层服务
最上层服务：并不是mysql特有的，用于连接处理，授权认证，安全相关
第二层服务：mysql的核心相关功能，包含解析，分析，优化，缓存
以及相关的内置函数（包含：日期，时间，数学等加密函数），所有的跨存储引擎的功能都是在这一步实现的：包含存储过程，触发器，视图等
第三层：即为存储引擎层，负责mysql中数据的存储和提取
优化器：mysql会解析查询，创建内部的数据结构，对其进行各种优化，决定表的读写顺序，以及选择合适的索引等
优化器并不关心表使用的是那种存储引擎，但是存储引擎对于优化查询是有影响的
对于select，解析查询前会先差缓存（query cache）如果能找到对应的查询，服务器就不会再去执行：解析，优化，执行器相关内容，而是直接返回查询缓存中的结果集。
并发控制
本章简单介绍
并发场景下，锁是个很好的工具，但是锁只是一个解决方案，并不是使系统支持了并发处理，任意一个时刻还是只有一个线程可以修改数据
升级：读写锁：支持了并发处理，多个用户可以同时读，但是不能修改数据
锁粒度
一种提高共享资源并发性的方式就是让锁定对象更有选择性 锁定的数据越少，系统并发性就越高
mysql的锁策略
表锁：
开销比行锁小:他会锁住整张表，同时也是读写锁，读锁只有在没有写锁的时候才能获取到，同时写锁的优先级高于读锁，一个写锁请求可能会被插入到读锁队列之前
行级锁：
最大程度的支持并发，但是带来了最大的锁开销
mysql的服务层是完全不了解锁的机制，完全由各存储引擎自身显示实现
事务
理解acid
理解 RU RC RR SERIALIZABLE 四种隔离级别
数据库死锁：指两个或者多个事务在同一资源上互相占用，并请求锁定对方资源
innodb对于死锁的处理方式：将持有最少行级排他锁的事务进行回滚
死锁发生后只有部分或者完全回滚其中一个事务才能打破死锁
事务日志
write-ahead-logging：事务日志以追加的方式顺序写到磁盘上，事务日志存储的快，是以io顺序插入的，事务日志写完以后，内存数据再会以缓慢的方式写到磁盘中，这时候写数据会比较慢，因为磁头在磁盘上的移动是不确定的。
多版本并发控制
mvcc在不同的数据库有不同的实现，mysql，pgsql，oracle，都不一样的实现
但是大都是实现非阻塞的读操作，写操作也只是锁定必要的行
mvcc实现就是通过保存数据在某个时间点的快照来实现的
看着片整理吧>>>引流
https://www.jianshu.com/writer#/notebooks/48158437/notes/87514562
存储引擎
mysql将每个数据库（称之为schema）保存在数据目录下的一个子目录
不同的存储引擎保存数据和索引的方式不同，但是表的定义则是在mysql服务层同一处理的
innodb
innodb使用mvcc支持高并发，默认隔离级别：RR 并采用间隙锁防止幻读的发生
间隙锁不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，防止幻影行的插入
innodb内部优化：
1.从磁盘读取数据采用的可预测读取，能自动在内存中创建hash索引，以加速读操作
2.增加插入缓冲区，加速插入操作
mysuiam
不支持事务。行级锁，崩溃后无法安全恢复
存储：数据文件+索引文件
选择合适的存储引擎
1.事务 inn
2.备份inn
3.崩溃恢复 inn
4.特有：如memory 内存
日志性应用
对日志进行报表分析，生成报表的sql导致插入数据变慢解决方案：将数据备份到另一份数据库上，主库用于插入，从库用于查询不影响日志的插入性能
