第1章 MySQL架构与历史

1.1 MySQL逻辑架构

连接管理与安全性

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个独立的线程中执行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。

优化与执行

MySQL会解析查询并创建内部数据结构（结构树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。
优化器不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。

1.2 并发控制

读写锁

共享锁(shared lock)和排他锁(exclusive lock)，也叫读锁(read lock)和写锁(write lock)。
读锁是共享的，或者说是相互不阻塞的，多个客户在同一时刻同时读取同一个资源，而互不干扰。
写锁是排他的，也就是一个写锁会阻塞其他的写锁和读锁。
只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。

锁粒度

锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等都会增加系统的开销。

表锁(table lock)

表锁是MySQL中最基本的锁策略，并且是开销最小的策略。
它会锁定整张表。一个用户要对表进行写操作（插入，删除，更新等）前，需要先获取写锁，这会阻塞其他用户对该表的所有读写操作。
只有没有写锁时，其他读取用户才能获得读锁，读锁间是不会相互阻塞的。
写锁比读锁拥有更高的优先级，因此一个写锁请求可能会被插入到读锁请求队列的前面。(写锁可以插入到锁队列中读锁的前面,反之读锁则不能插入到写锁的前面)

行级锁(row lock)

行级锁可以最大程度地支持并发处理(同时带来最大的锁开销)
行级锁只在存储引擎层实现,而MySQL服务器层没有实现.服务器层完全不了解存储引擎层的锁实现.

1.3 事务

事务就是一组原子性的SQL查询,或者说一个独立的工作单元.事务内的语句,要么全部执行成功,要么全部执行失败.

原子性(atomicity):一个事务要么全部执行成功,要么全部失败回滚
一致性(consistency):数据库总是从一个一致性的状态转换成另个一个一致性的状态
隔离性(isolation):一个事务所做的修改在最终提交前,对其他事务是不可见的
持久性(durability):一旦事务提交,则其所做的修改就会永久保存到数据库中

1.3.1 隔离级别

隔离性其实比想象的要更复杂

READ UNCOMMITTED(未提交读)

事务中的修改,即使没有提交,对其他事务都是可见的

事务可以读取未提交的数据,这也被称为脏读(Dirty Read)

READ COMMITTED(提交读,不可重复读)

一个事务开始前,只能看见已经提交的事务所做的修改.换句话说,一个事务从开始直到提交前,所做的任何修改对于其他事务都是不可见的.
这个级别有时候也叫不可重复读(nonrepeatable read),因为两次执行同样的查询,可能会得到不同的结果
例如:

用户 1 开始事务，查询账户余额为 0 元。

用户 1 继续执行其他操作，过程中用户 2 执行另外的事务，向同一账户增加了 100 元。

用户 1 再次查询账户余额，发现在同一事务中，账户余额居然从 100 元变成 0 元。

提交读

REPEATABLE READ(可重复读)

REPEATABLE READ 解决了脏读的问题.该级别保证了在同一事务中多次读取同样记录的结果是一致的.
但是理论上,可重复读隔离级别还是没办法解决幻读(Phantom Read)的问题.

幻读(Phantom Read)指的是当某个事务在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录,当之前的事务再次读取该范围的记录时,会产生幻行(Phantom Row).

InnoDB通过多版本并发控制解决了幻读的问题.

可重复读是MySQL的默认隔离级别.

SERIALIZABLE(可串行化)

SERIALIZABLE是最高的隔离级别.
它通过强制事务串行执行,避免了之前说的幻读的问题.
简单来说,SERIALIZABLE会在读取的每一行都加上锁,所以可能导致大量的超时和锁争用的问题.

1.3.2 死锁

死锁是指两个或者多个事务在同一个资源上相互占用,并请求锁定对方占用的资源,从而导致资源恶性循环的现象.
当多个事务试图以不同的顺序锁定资源时,就可能产生死锁。多个事务同时锁定同一个资源时,也会产生死锁.

设想下面两个事务同时处理Stock Price表:
事务1:

START TRANCSATION; UPDATE StockPrice SET close=45.50 WHERE stock_id=4 and date='2002-05-01'; UPDATE StockPrice SET close=19.80 WHERE stock_id=3 and date='2002-05-02'; COMMIT;

事务2:

START TRANCSATION; UPDATE StockPrice SET close=20.12 WHERE stock_id=3 and date='2002-05-02'; UPDATE StockPrice SET close=47.20 WHERE stock_id=4 and date='2002-05-01'; COMMIT;

如果凑巧,两个事务都执行了第一条update语句,更新了第一行数据,同时锁定了该行的数据,接着每个事务都尝试去执行第二条update语句,却发现该行已经被对方锁定,然后两个事务都等待对方释放锁,同时又持有对方需要的锁,则陷入死循环.

InnoDB目前处理死锁的方法是,将持有最少行数级排他锁的事务进行回滚(这是相对比较简单的死锁回滚算法)

1.3.3 事务日志

事务日志可以帮助提高事务的效率.

使用事务日志,存储引擎在修改表的数据时,只需要修改其内存拷贝,再把该修改行为记录到持久在硬盘上的事务日志,而不用每次都修改的数据本身修改到磁盘.
事务日志采用的追加的方式,因此写日志的操作是磁盘上一小块区域内的顺序I/O,而不是随机I/O需要在磁盘的多个地方移动磁头,所以采用事务日志的方式要快得多.
事务日志持久以后,内存中被修改的数据在后台可以慢慢地刷回到磁盘. 目前大多数存储引擎都是这样实现的,我们称之为预写式日志(Write-Ahead Logging),修改数据需要写两次磁盘.

如果数据的修改已经记录到事务日志并持久化,但数据本身还没有写回磁盘,此时系统崩溃,存储引擎在重启时能够自动化恢复这部分修改的数据.

1.3.4 MySQL中的事务

隐式和显性锁定

1.隐式锁定 InnoDB采用的是两阶段锁定协议(two-phase locking protocal).
在事务执行的过程中,随时都可以执行锁定,锁只有在COMMIT或者ROLLBACK的时候才会释放,并且所有在锁是在同一时刻被释放.

2.显式锁定: InnoDB也支持特定的语句进行显示锁定

select ... lock in share mode //共享锁
select ... for update //排他锁

1.4 多版本并发控制

MVCC是行级锁的一个变种,但是它在很多情况下避免了加锁操作,,因此开销更低. 虽然实现机制有所不同,但都实现了非阻塞的读操作,写操作也只锁定必要的行.
MVCC的实现是通过保存数据在某个时间点的快照来实现的.

《高性能MySQL》读书笔记