MySQL架构

温习《高性能MySQL》的第一章 MySQL架构与历史

1.1   MySQL逻辑架构

参考

 

 

图1-1：MySQL服务器逻辑架构图

 

　　最上层的服务并不是MySQL所独有的，大多数基于网络的客户端／服务器的工具或者服务都有类似的架构。比如连接处理、授权认证、安全等等。

　　第二层架构是MySQL比较有意思的部分。大多数MySQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。

　　第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。和GNU/Linux下的各种文件系统一样，每个存储引擎都有它的优势和劣势。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。但存储引擎不会去解析SQL，不同存储引擎之间也不会相互通信，而只是简单地响应上层服务器的请求。

1.2   并发控制

1.2.1  读写锁

　　这两种类型的锁通常被称为共享锁(shared lock)和排他锁(exclusive lock)，也叫读锁(read lock)和写锁(write lock)。读锁是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰。写锁则是排他的，也就是说一个写锁会阻塞其他的写锁和读锁。

1.2.2 锁粒度

　　两种最重要的锁策略：表锁和行级锁

表锁(table lock)

　　表锁是MySQL中最基本的锁策略，并且是开销最小的策略。它会锁定整张表。一个用户在对表进行写操作（插入、删除、更新等）前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不相互阻塞的。

　　在特定的场景中，表锁也可能有良好的性能。例如，READ LOCAL表锁支特某些类型的并发写操作。另外，写锁也比读锁有更高的优先级，因此一个写锁请求可能会被插入到读锁队列的前面（写锁可以插入到锁队列中读锁的前面，反之读锁则不能插入到写锁的前面）。

行级锁( row lock)   

　　行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。众所周知，在InnoDB和XtraDB，以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层实现，而MySQL服务器层没有实现。服务器层完全不了解存储引擎中的锁实现。

1.3   事务

事务支持ACID原则。

原子性(atomicity)

　　一个事务必须被视为一个不可分割的最小工作单元。

一致性(consistency) 

　　数据库总是从一个一致性的状态转换到另外一个一致性的状态。

隔离性(isolation)

　　通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。

持久性(durability)

　　一旦事务提交，则其所做的修改就会永久保存到数据库中。

1.3.1  隔离级别

下面简单地介绍一下四种隔离级别。

READ UNCOMMITTED（未提交读）

　　在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读(Dirty Read)。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。

READ COMMITTED（提交读）

　　大多数数据库系统的默认隔离级别都是READ COMMITTED（但MySQL不是）。一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读(nonrepeatable read)，因为两次执行同样的查询，可能会得到不一样的结果。

REPEATABLE READ（可重复读）

　　REPEATABLE READ解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读 (Phantom Read)的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行(Phantom Row)。InnoDB和XtraDB存储引擎通过多版本并发控制(MVCC，Multiversion Concurrency Control)解决了幻读的问题。

　　可重复读是MySQL的默认事务隔离级别。

SERIALIZABLE（可串行化）

　　SERIALIZABLE是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE会在谟取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。

 

1.3.2  死锁

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

　　为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。

　　锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。

1.3.3  事务日志

　　使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用的是追加的方式。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写式日志(Write-Ahead Logging)，修改数据需要写两次磁盘。

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

1.3.4  MySQL中的事务

1.4   多版本并发控制

　　MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。下面我们通过InnoDB的简化版行为来说明MVCC是如何工作的。

　　InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号(system version number)。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。下面看一下在REPEATABLE READ隔离级别下，MVCC具体是如何操作的。

SELECT

  InnoDB会根据以下两个条件检查每行记录：

    　　a．InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。

    　　b．行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

    　　只有符合上述两个条件的记录，才能返回作为查询结果。

INSERT

        InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

DELETE

    　　InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

UPDATE

    　　InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

　　保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。

　　MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容注4，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

1.5   MySQL的存储引擎

　　在文件系统中，MySQL将每个数据库（也可以称之为schema）保存为数据目录下的一个子目录。创建表时，MySQL会在数据库子目录下创建一个和表同名的.frm文件保存表的定义。例如创建一个名为MyTable的表，MySQL会在MyTable.frm文件中保存该表的定义。因为MySQL使用文件系统的目录和文件来保存数据库和表的定义，大小写敏感性和具体的平台密切相关。在Windows中，大小写是不敏感的；而在类Unix中则是敏感的。不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在MySQL服务层统一处理的。

　　可以使用SHOW TABLE STATUS命令（在MySQL 5.0以后的版本中，也可以查询INFORMATION SCHEMA中对应的表）显示表的相关信息。例如，对于mysql数据库中的user表：

mysql> SHOW TABLE STATUS LIKE 'user' \G

          Name: user

         Engine: MyISAM

    Row_format: Dynamic

           Rows :  6

  Avg_row_length: 59

      Data length: 356

Max data length: 4294967295

     Index length: 2048

       Data_free: 0   

  Auto_increment: NULL

     Create_time: 2002-01-24 18:07:17

    Update_time : 2002 -01-24  21: 56 : 29

      Check_time: NULL

        Collation : ut f8_bin

        Checksum: NULL

     Create_options :

          Comment: Users and global privileges

1 row in set (o.oo sec)

 

榆出的结果表明，这是一个MyISAM表。输出中还有很多其他信息以及统计信息。下面简单介绍一下每一行的含义。

Name	表名。
Engine	表的存储引擎类型。在旧版本中，该列的名字叫Type，而不是Engine。
Row- format	行的格式。对于MyISAM表，可选的值为Dynamic、Fixed或者Comp ressed。Dynamic的行长度是可变的，一般包含可变长度的字段，如VARCHAR或BLOB。Fixed的行长度则是固定的，只包含固定长度的列，如CHAR和INTEGER。Compressed的行则只在压缩表中存在。
Rows	表中的行数。对于MyISAM和其他一些存储引擎，该值是精确的，但对于InnoDB，该值是估计值。
Avg_ row_length	平均每行包含的字节数。
Data_length	表数据的大小（以字节为单位）。
Max- data_length	表数据的最大容量，该值和存储引擎有关。
Index_length	索引的大小（以字节为单位）。
Data_free	对于MyISAM表，表示已分配但目前没有使用的空间。这部分空间包括了之前删除的行，以及后续可以被INSERT利用到的空间。
Auto_increment	下一个AUTO INCREMENT的值。
Create_time	表的创建时间。
Update_time	表数据的最后修改时间。
Check_ time	使用CKECK TABLE命令或者myisamchk工具最后一次检查表的时间。
Collation	表的默认字符集和字符列排序规则。
Checksum	如果启用，保存的是整个表的实时校验和。
Create_options	刨建表时指定的其他选项。
Comment	该列包含了一些其他的额外信息。对于MyISAM表，保存的是表在创建时带的注释。对于InnoDB表，则保存的是InnoDB表空间的剩余空间信息。如果是一个视图，则该列包含“VIEW”的文本字样。

 

1.6   MySQL时间线

1.7   MySQL的开发模式

 

 

参考：《高性能 MySQL》 

Atas ialah kandungan terperinci MySQL架构. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!