《高性能MySql》一.MYSQL架构和历史

MYSQL逻辑架构

1.Mysql架构图

并发控制

1.读写锁

(1)共享锁 和 排他锁 ，也叫读锁 和 写锁

(2)写锁是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑。

 

2.锁粒度

(1)一种提高共享资源并发性的方式就是让锁定的对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。锁定的数据量越少，则系统的并发程度越高

 

(2)所谓锁策略，就是在锁的开销和数据的安全性之间寻求平衡，大多数商业数据库系统一般是在表上施加行级锁。Mysql提供多种选择

 

(3)表锁：最基本的锁策略，开销最小。

 

(4)写锁也比读锁有更高的优先级，因此一个写锁可能会被插入到读锁队列的前面

 

(5)行级锁：可以最大程度地支持并发处理(同时也带来了最大的锁开销)。在InnoDB和XtraDB，以及其他一些存储引擎中实现了行级锁。

 

事务

1.ACID，一个事务处理系统必须具备这些标准特征。  实现ACID需要更大的开销

 

2.隔离级别：

(1)读未提交：事务可以读其他事务为提交的数据，性能比其他级别好太多

(2)读已提交：事务只可以读其他事务已提交的数据，大多数数据库系统默认的隔离级别都是读已提交(mysql不是)

(3)可重复读：保证了在同一个事务中多次读取同样记录的结果是一致。mysql默认隔离级别

(4)可串行化：最高隔离级别，通过强制事务串行执行。会在读取每一行数据上都加锁。开销大

 

3.死锁

(1)数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并返回错误。

 

(2)InnoDB目前处理死锁的方法：将持有最少行级排他锁的事务进行回滚。

 

(3)只有部分或完全回滚其中一个事务，才能打破死锁。

 

4.事务日志

(1)使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘的事务日志中，而不是修改的数据本身持久到磁盘。事务日志采用的是追加的方式。采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回磁盘。目前大多数存储引擎都是这样实现的。

 

5.MySql中的事务

(1)MySql提供了两种事务型存储引擎：InnoDB和NDB Cluster.

 

(2)自动提交：MySql默认采用自动提交模式，也就是说，如果不是显式地开始一个事务，则每个查询都被当作一个事务执行提交操作。

 

(3)Mysql服务器层不管理事务，事务是由下层的存储引擎实现的。

 

多版本并发控制

1.MySql的大多数事务型存储引擎实现都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制

 

2.MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低

 

3.MVCC的实现，是通过保存数据在某个时间点的快照来实现的。根据事务开始的时间不用，每个事务对同一张表，同一时刻看到的数据可能是不一样的。

 

4.工作原理：

(1)InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。存储的是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

 

(2)行版本号，删除标识

 

(3)MVCC只在读已提交 和 可重复读 两个隔离级别下工作，因为读未提交总数读取最新的数据行，而不是符合当前事务版本的数据行。而串行化则会对所有读取的行都加锁。

 

MYSQL的存储引擎

1.InnoDB是MySql的默认事务型引擎，也是最重要，使用最广泛的存储引擎。被设计用来处理大量的短期事务，短期事务大部分情况是正常提交的，很少会被回滚。

 

2.在MySql5.1及之前的版本，MyISAM是默认的存储引擎。但不支持事务行级锁，而且有一个毫无疑问的缺陷就是奔溃后无法安全恢复。MyISAM只将数据写到内存中，然后等待操作系统定期将数据刷出到磁盘上。