1.逻辑架构图
逻辑架构图
2.并发控制
只要有多个查询需要在同一个时刻修改数据导致出现并发问题(读取数据不会出现问题)
解决并发控制的读写
通过实现两种类型的锁组成的锁系统解决
读写锁
- 共享锁(读锁)
- 排他锁(写锁)
什么是锁
- 读锁: 多个客户都可以在同一时刻读取同一个资源并且是共享的(互不干扰)
- 写锁:只有一个用户可以能执行写入，会阻塞其他的读锁和写锁，防止其他用户读取正在写入的同一资源
锁粒度
一种提高共享资源并发性的方式
出现问题：加大开销，消耗资源
- 例如：锁的各种操作
- 获取锁 检查锁是否解除 释放锁等
锁策略
锁的开销和数据的安全性之间寻求平衡
常用的锁策略
- 表锁
1.基本锁策略，开销最小
2.锁住整张表
一个用户操作表的话需要获取到写锁，
这会阻塞其他用户的对该表所有的读写操作，释放掉写锁后，其他读取用户才可以操作(读锁[互不阻塞])
- 行级锁(存储引擎实现)
1.最大程度的支持并发处理，开销最大
3.事务
一组原子性(不成功便成仁)的SQL查询语句 （独立工作的单元）
事务内的语句，要么全部执行成功，要么全部执行失败(一条语句崩溃或者其他原因无法执行)
开启事务
start transaction 语句开启事务
commit提交事务
roolback撤销所有事务
例子：银行应用（转账）
所有事务必须经过ACID测试
- A: atomicity 原子性
- C: consistency 一致性
- I: isolation 隔离性
- D: durability 持久性
原子性：
要执行事务代码逻辑成功，要么就执行事务代码失败
一致性:
“一致性”在数据库领域有两个意义：
，一个是ACID中的C，也是普遍意义上的数据库事务一致性，
另一个是CAP的C，有关分布式事务的一致性。
举例来说，假设用户A和用户B两者的钱加起来一共是1000，
那么不管A和B之间如何转账、转几次账，
事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。
ACIP
1.事务对数据完整性的遵循
约束可能包括主键约束、外键约束或是一些用户自定义约束。
事务执行的前后都是合法的数据状态，不会违背任何的数据完整性
2.不能写出错误的事务逻辑
CAP
1.CAP定理是分布式系统理论的基础
分布式系统（或者由于网络隔离等原因产生的分区系统），它无法同时保证一致性、可用性和分区容忍性，
而是必须要舍弃其中的一个。
2.具体在数据库上，就是分布式数据库中，
每一个节点对于同一个数据必须有相同的拷贝每个库里的同一个数据内容必须是一致的）
分布式事务
隔离性
当多个用户并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，
不能被其他事务的操作所干扰，多个并发事务之间要相互隔离
持久性
一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，
即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作
隔离级别（隔离性）
- 未提交读（脏读）[READ UNCOMMITTED]
事务可以读取为提交的的数据[问题多,实际少用] - 提交读（不可重复读）[READ COMMITTED]
一个事务开始到结束，所做的所有修改对其他事务是不可见的[两次所执行的查询，得到的结果可能不一样] - 可重复读[REPEATABLE READ]
- 解决脏读问题
2.保证同一事务中多次读取同样的记录结果是一致的
3.幻读：当一个事务读取某一范围的记录，又有新事务在这个范围插入新的记录，上一个事务再次读取就会出现此问题-->幻行
- 可串行化[SERALIZABLE]
1.强制事务串行执行，避免幻行问题
2.读取的每一行数据上加锁增大开销和争锁问题（实际上少用除了非常需要保持数据一致性且可以接受没有并发的情况）
SQL隔离级别
死锁
两个或者多个事务在同一资源上相互占用，请求锁定对方的资源从而导致恶性循环现象
出现死锁原因：
1.数据出现冲突
2.存储引擎实现方式导致
解决：大多数情况只需要重新执行因死锁回滚的事务
image.png
·
Mysql 事务
常见事务存储引擎：innodb NDB Cluster
Mysql 事务
多版本并发控制
Mysql存储引擎
//查看存储引擎显示表的相关信息
SHOW TABLE STATUS LIKE 表名
- innoDB 存储引擎
