Mysql 逻辑架构
文章目录
- Mysql 逻辑架构
- 1、Mysql服务器逻辑架构
- a、连接管理与安全性
- b、优化与执行
- 2、并发控制
- a、读写锁
- c、锁粒度
- 3、事务
- a、隔离级别
- b、死锁
- c、事务
- 事务日志
- MySQL中的事务
- 4、多版本并发控制
- 参考：
1、Mysql服务器逻辑架构
- 连接处理器
- 核心服务功能：查询解析、分析、优化、缓存以及内置函数；跨存储引擎功能实现：存储过程、触发器、视图等
- 存储引擎：负责mysql数据的存储和提取
- 服务器通过API与存储引擎通信， 接口屏蔽了不同存储引擎之间的差异， 是的差异对上层查询过程透明
- 存储引擎API包含几十个底层函数， 方便执行操作
- 不会去解析SQL， 不同存储引擎之间不会相互通信， 而是简单的响应上层服务器的请求
a、连接管理与安全性
每个客户端连接都会在服务进程中拥有一个线程， 这个连接的查询只会在这个单独的线程找那个执行，该线程只能够在某个CPU核心或者CPU中运行
- 服务器会负责缓存线程，不需要为每一个新建的廉洁创建或者销毁线程
当客户端连接到服务器时， 服务器会对其进行认证 - 用户名、原始主机信息和密码认证
- 安全套接字(ssl)连接时， 可以使用X.059证书认证
- sql 执行权限认证
b、优化与执行
对mysql进行查询时， Mysql会解析查询，并创建内建数据接口（解析树），然后对其进行各种优化（重写查询、决定表、读取顺序、选择合适的索引），
优化器并不关心表所使用的的存储引擎， 但优化语句对存储引擎的查询是有影响的
- 对于SELECT语句，在解析查询之前， 会先在查询缓存中检查， 如果能在期中检查到对应的查询， 就不必在执行查询解析、优化和执行的过程， 直接返回查询缓存中的结果集
2、并发控制
服务器层和存储引擎层的并发控制
通过锁控制多个进程对同一份数据的修改，避免冲突和数据损坏；当线程修改数据时，会锁定数据，直到释放后才允许其他线程修改
a、读写锁
对于多线程同时修改同一份数据的场景，通常使用并发控制来解决，而并发控制可以通过两种锁来实现
-
共享锁（shared lock）
又名:读锁（read lock），读锁是共享的， 相互不阻塞。 多个用户可以同时读取同一个资源， 而不相互干扰 -
排他锁（exclusive lock）
又名：写锁（write lock），写锁是排他性的， 会阻塞其他的写锁和读锁。
c、锁粒度
让锁的对象具有具有选择性， 可以提高共享资源的并发性
尽量锁定需啊哟修改的部分数据， 所不是所有资源，锁定的数据越少， 系统的并发程度越高
-
锁策略
在锁的开销和数据安全之间寻求平衡。
加锁会消耗资源， 锁的各种操作（获得锁、检查锁等）会增加系统的开销 -
表锁（table lock）
是mysql最基本的所策略， 他会锁定整张表， 一个线程对表进行变更操作时， 需要先获得锁， 才能对表的数据进行编辑 -
行级锁（row lock）
可以最大程度的支持并发处理， 但同时也带来了最大的锁开销
只在存储引擎层实现，而不再服务器层
3、事务
ACDI原则
-
原子性（atomicity）
一个事物必须被视为一个不可分割的最小工作单元，整个事务的的所有操作要么全部提交成功，要么全部失败回滚 -
一致性（consistency）
数据库总是从一个一致性转换到另一个一致性的状态， 数据的修改只有在成功提交之后才会生效 -
隔离性（isolation）
一个事务的修改在最终提交前， 对其他事务是不可见的 -
持久性（durability）
事务一旦提交， 所做的修改会永久的保存在数据库中
a、隔离级别
-
READ UNCOMMITTED(未提交读)
事务的修改即使没有提交， 对其他事务都是可见的- 脏读：读取未提交的数据
性能不会比其他级别好太多， 而且容易导致问题
- 脏读：读取未提交的数据
-
READ COMMITTED（提交读）
事务直到未提交前，所作的修改对其他事务都是不可见的
大多数数据库默认级别都是 READ COMMITTED ， MySQL不是 -
REPEATABLE READ（可重复读）
同一个事务的多次读取同样的记录的结果是一致的
MySQL默认的事务隔离级别- 幻读（Phantom Read）：当事务在读取某个范围内的记录时，另一个事务又在该范围内插入新的记录，当之前的事务再次读取该范围的记录时， 会产生幻行（Phantom Row）
-
SERIALIZABLE（可串行化）
MySQL最高的隔离级别
通过强制事务串行执行， 避免幻读的问题
会在读取的每一行数据上加锁， 实现避免幻读，但会导致大量的超时和锁竞争的问题
b、死锁
死锁是多个事务在同一个资源上相互占用， 并请求对方暂用的资源，从而导致恶性循环的现象
- 数据库通过死锁检测和死锁超时的机制解除死锁
- 锁的行为和顺序和存储引擎是相关的
- 死锁发生后，只有部分或者完全会馆其中一个事务， 才能打破死锁
c、事务
事务日志
事务日志可以提高事务的效率
存储引擎在修改表的数据时，只需要修改其内存拷贝， 再把修改行为记录到持久在硬盘上的事务日志中，为不用将每次修改的数据本身持久到磁盘
事务日志采用追加的方式， 因此只需要占用磁盘上的一小块顺序I/O，而不需要在磁盘的多个地方移动磁头
存储引擎能够自动恢复那些记录到事务并持久化但数据本身写会磁盘的数据
MySQL中的事务
MySQL提供两种事务引擎：InnoDB 和 NDB Cluster
+ 自动提交
mysql默认采用自动提交事务的模式， 如果不显式的开始一个事务， 每个查询都会被当做一个事务提交
+ 混合使用存储引擎
服务器层不管理事务，事务有下层存储引擎实现， 所以在同一个事务中使用不同存储引擎是不可靠的
+ 隐式和显式锁定
+ 隐式： 根据隔离级别在需要额时候， 自动加锁
+ 显式：使用 LOCK TABLE 和 UNLOCK TABLE语句在服务器层实现加锁，与存储引擎无关， 也不能替代事务处理
4、多版本并发控制
行级锁的变种，大多数情况下避免了加锁的操作，开销更低
-
多版本并发控制（MVCC）
通过保存数据在某个时间点的快照实现的， 因此不管多长时间，当前事务看到的数据是一致的
但对于不同事务， 开始时间的不同， 可能导致的同一时刻看到的数据不同 -
InnoDB中的MVCC
通过在每行记录后面保存两个隐藏的列来实现的， 创建时间和过期时间，存储的系统版本号而不是实际的时间值
参考：
高性能MySQL（第三版）
本文地址：https://blog.csdn.net/qq_40601372/article/details/107192061