每个客户端连接都会在服务进程中拥有一个线程, 这个连接的查询只会在这个单独的线程找那个执行,该线程只能够在某个CPU核心或者CPU中运行
对mysql进行查询时, Mysql会解析查询,并创建内建数据接口(解析树),然后对其进行各种优化(重写查询、决定表、读取顺序、选择合适的索引),
优化器并不关心表所使用的的存储引擎, 但优化语句对存储引擎的查询是有影响的
服务器层和存储引擎层的并发控制
通过锁控制多个进程对同一份数据的修改,避免冲突和数据损坏;当线程修改数据时,会锁定数据,直到释放后才允许其他线程修改
对于多线程同时修改同一份数据的场景,通常使用并发控制来解决,而并发控制可以通过两种锁来实现
共享锁(shared lock)
又名:读锁(read lock),读锁是共享的, 相互不阻塞。 多个用户可以同时读取同一个资源, 而不相互干扰
排他锁(exclusive lock)
又名:写锁(write lock),写锁是排他性的, 会阻塞其他的写锁和读锁。
让锁的对象具有具有选择性, 可以提高共享资源的并发性
尽量锁定需啊哟修改的部分数据, 所不是所有资源,锁定的数据越少, 系统的并发程度越高
锁策略
在锁的开销和数据安全之间寻求平衡。
加锁会消耗资源, 锁的各种操作(获得锁、检查锁等)会增加系统的开销
表锁(table lock)
是mysql最基本的所策略, 他会锁定整张表, 一个线程对表进行变更操作时, 需要先获得锁, 才能对表的数据进行编辑
行级锁(row lock)
可以最大程度的支持并发处理, 但同时也带来了最大的锁开销
只在存储引擎层实现,而不再服务器层
ACDI原则
原子性(atomicity)
一个事物必须被视为一个不可分割的最小工作单元,整个事务的的所有操作要么全部提交成功,要么全部失败回滚
一致性(consistency)
数据库总是从一个一致性转换到另一个一致性的状态, 数据的修改只有在成功提交之后才会生效
隔离性(isolation)
一个事务的修改在最终提交前, 对其他事务是不可见的
持久性(durability)
事务一旦提交, 所做的修改会永久的保存在数据库中
READ UNCOMMITTED(未提交读)
事务的修改即使没有提交, 对其他事务都是可见的
READ COMMITTED(提交读)
事务直到未提交前,所作的修改对其他事务都是不可见的
大多数数据库默认级别都是 READ COMMITTED , MySQL不是
REPEATABLE READ(可重复读)
同一个事务的多次读取同样的记录的结果是一致的
MySQL默认的事务隔离级别
SERIALIZABLE(可串行化)
MySQL最高的隔离级别
通过强制事务串行执行, 避免幻读的问题
会在读取的每一行数据上加锁, 实现避免幻读,但会导致大量的超时和锁竞争的问题
死锁是多个事务在同一个资源上相互占用, 并请求对方暂用的资源,从而导致恶性循环的现象
事务日志可以提高事务的效率
存储引擎在修改表的数据时,只需要修改其内存拷贝, 再把修改行为记录到持久在硬盘上的事务日志中,为不用将每次修改的数据本身持久到磁盘
事务日志采用追加的方式, 因此只需要占用磁盘上的一小块顺序I/O,而不需要在磁盘的多个地方移动磁头
存储引擎能够自动恢复那些记录到事务并持久化但数据本身写会磁盘的数据
MySQL提供两种事务引擎:InnoDB 和 NDB Cluster
+ 自动提交
mysql默认采用自动提交事务的模式, 如果不显式的开始一个事务, 每个查询都会被当做一个事务提交
+ 混合使用存储引擎
服务器层不管理事务,事务有下层存储引擎实现, 所以在同一个事务中使用不同存储引擎是不可靠的
+ 隐式和显式锁定
+ 隐式: 根据隔离级别在需要额时候, 自动加锁
+ 显式:使用 LOCK TABLE 和 UNLOCK TABLE语句在服务器层实现加锁,与存储引擎无关, 也不能替代事务处理
行级锁的变种,大多数情况下避免了加锁的操作,开销更低
多版本并发控制(MVCC)
通过保存数据在某个时间点的快照实现的, 因此不管多长时间,当前事务看到的数据是一致的
但对于不同事务, 开始时间的不同, 可能导致的同一时刻看到的数据不同
InnoDB中的MVCC
通过在每行记录后面保存两个隐藏的列来实现的, 创建时间和过期时间,存储的系统版本号而不是实际的时间值
本文地址:https://blog.csdn.net/qq_40601372/article/details/107192061
如对本文有疑问, 点击进行留言回复!!
SSD原理及Pytorch代码解读——网络架构(二):特征提取网络及总体计算过程
集合类 ArrayList 和 LinkedList 直接用 Innodb(MySQL 5.0
网友评论