理解mysql--复制-索引优化--并行分区讲述.pdf

理解 MySQL——架构与概念 主要参考资料《MySQL Manual》和《High Performance MySQL》 第一章、MySQL 架构与概念 1、MySQL 的逻辑架构 最上面不是 MySQL 特有的，所有基于网络的 C/S 的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是 MySQL 的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能，包括存储过程、触发器和视图等。 最下面是存储引擎，它负责存取数据。服务器通过 storage engine API 可以和各种存储引擎进行交互。 1.1、查询优化和执行(Optimization and Execution) MySQL 将用户的查询语句进行解析，并创建一个内部的数据结构——分析树，然后进行各种优化，例如重写查询、选择读取表的顺序，以及使用哪个索 引等。查询优化器不关心一个表所使用的存储引擎，但是存储引擎会影响服务器如何优化查询。优化器通过存储引擎获取一些参数、某个操作的执行代 价、以及统计信息等。在解析查询之前，服务器会先访问查询缓存(query cache)——它存储 SELECT 语句以及相应的查询结果集。如果某个查询结果 已经位于缓存中，服务器就不会再对查询进行解析、优化、以及执行。它仅仅将缓存中的结果返回给用户即可，这将大大提高系统的性能。 1.2、并发控制 MySQL 提供两个级别的并发控制：服务器级(the server level)和存储引擎级(the storage engine level)。加锁是实现并发控制的基本方法，MySQL 中锁的粒度： (1) 表级锁：MySQL 独立于存储引擎提供表锁，例如，对于 ALTER TABLE 语句，服务器提供表锁(table-level lock)。 (2) 行级锁：InnoDB 和 Falcon 存储引擎提供行级锁，此外，BDB 支持页级锁。InnoDB 的并发控制机制，下节详细讨论。 另外，值得一提的是，MySQL 的一些存储引擎（如InnoDB、BDB）除了使用封锁机制外，还同时结合 MVCC 机制，即多版本两阶段封锁协议(Multiversion two-phrase locking protocal)，来实现事务的并发控制，从而使得只读事务不用等待锁，提高了事务的并发性。 注：并发控制是 DBMS 的核心技术之一(实际上，对于 OS 也一样)，它对系统性能有着至关重要的影响，以后再详细讨论。 1.3、事务处理 MySQL 中，InnoDB 和 BDB 都支持事务处理。这里主要讨论 InnoDB 的事务处理(关于 BDB 的事务处理，也十分复杂，以前曾较为详细看过其源码， 以后有机会再讨论)。 1.3.1、事务的ACID 特性 事务是由一组 SQL 语句组成的逻辑处理单元，事务具有以下 4 个属性，通常简称为事务的 ACID 属性(Jim Gray 在《事务处理：概念与技术》中对事务 进行了详尽的讨论)。 (1)原子性（Atomicity ）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 (2)一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完 整性；事务结束时，所有的内部数据结构（如 B 树索引或双向链表）也都必须是正确的。 (3)隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态 对外部是不可见的，反之亦然。 (4)持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。 1.3.2、事务处理带来的相关问题 由于事务的并发执行，带来以下一些著名的问题： (1)更新丢失（Lost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生 丢失更新问题－－最后的更新覆盖了由其他事务所做的更新。 (2)脏读（Dirty Reads）：一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读 取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做脏 读。 (3)不可重复读（Non-Repeatable Reads）：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，