Mysql.tex

\documentclass[UTF8]{ctexart}
\title{Mysql学习笔记}
\author{fefive}
\begin{document}
\maketitle
\section{并发控制}
\subsection{读写锁}
在处理并发读写时, 通常可以使用锁来解决问题, 这两种类型的锁通常称为  共享锁(shared lock) 和  排他锁(exclusive lock)

共享锁也叫读锁, 排他锁也叫写锁

读锁是共享的, 或者说相互不阻塞, 多个客户在同一时刻可以读取同一个资源, 而互不干扰

写锁是排他的, 也就是说一个写锁会阻塞其他的锁(无论是写锁还是读锁), 只有这样, 才能确保在给定的时间里, 只有一个用户才能执行写作, 并防止其他用户读取正在写的同一资源

写锁比读锁有更高的优先级

\subsection{锁粒度}
提高共享资源的并发性可以通过让锁定对象更有选择性的方式来进行, 尽量只锁定需要修改的部分数据, 而不是所有资源

在给定的资源上, 锁定的数据量越少, 则系统的并发程度越高, 只要相互之间不发生冲突即可

锁策略: 在锁的开销和数据的安全性之间寻求平衡, 这种平衡当然也会影响到性能.

锁策略: 表锁(table lock) 和 行级锁(row lock)

表锁会锁整张表, 行级锁可以最大程度支持并发处理

\subsection{事务}
事务就是一组原子性的SQL查询, 或者说一个独立的工作单元

事务内的语句, 要么全部执行成功, 要么全部执行失败

一个事务拥有ACID特征

原子性(atomicity): 一个事务必须被视为一个不可分割的最小工作单元, 整个事务中的所有操作要么全部提交成功, 要么全部失败回滚, 对于一个事务来说, 不可能只执行其中的一部分操作

一致性(consistency): 数据库总是从一个一致性的状态转换到另外一个一致性的状态.

隔离性(isolation): 通常来说, 一个事务所做的修改在最终提交以前, 对其他事务是不可见的.

持久性(durability): 一旦事务提交, 则其所做的修改就会永久保存到数据库中,此时即使系统崩溃, 修改的数据也不会丢失.

\subsection{隔离级别}
较低级别的隔离通常可以执行更高的并发, 系统的开销也更低

四种隔离级别

1.未提交读(READ UNCOMMITTED) 

事务中的修改, 即使没有提交, 对其他事务也都是可见的. 事务可是读取未提交的数据, 这种也被称为脏读(Dirty Read)

这个级别会导致很多问题, 一般很少使用

2.提交读(READ　COMMITED)

大部分数据库系统的默认级别都是提交读，Mysql不是

提交读满足前面提到的隔离性的定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。即：一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别也称不可重复读，执行两次相同的查询，可能会得到不一样的结果。

3.可重复读(REPEATABLE READ)

可重复读解决了脏读的问题，该级别保证了在同一个事务中多次读取同样记录的结果是一致的

但是可重复读隔离级别还有一个无法解决另外一个幻读

幻读：某一个事务Ａ在读取某个范围的记录时，另外一个事务Ｂ又在该范围内插入了新的记录，当Ａ再次读取该范围的记录时，会产生幻行。

InnoDB 存储引擎通过多版本并发控制(MVCC),解决幻读的问题。


4.可串行化（SERIALIZABLE)

它通过强制事务串行执行，避免前面的幻读问题。

可串行化在读取每一行数据都加锁，所以可能导致大量的超时和锁争用的问题，所以一般很少用到这个隔离级别

\subsection{死锁}

死锁是指两个或者多个事务在同一资源上相互占用, 并请求 *锁定对方* 占用的资源, 从而导致恶性循环的现象.

InnoDB 目前处理死锁的方法: 将持有最小行级排他锁的事务进行回滚

发生的原因: 

1. 真正的数据冲突 \\2.由于存储引擎的实现方式导致的

\subsection{多版本并发控制 MVCC}
MVCC是行级锁的一个变种, 很多情况下避免了加锁操作,所以开销更低, 大都实现了非阻塞的读操作, 写操作也只锁定必要的行.

MVCC的实现, 是通过保存数据在某个时间点的快照实现的

典型的有乐观并发控制 和 悲观并发控制







\end{document}