mysql逻辑体系结构
1 .读锁定(读锁定/写锁定)示例：读取邮箱信息并不麻烦，多个用户同时读取同一邮箱也没问题。 因为读取操作不会有任何修改，所以没有错误。 但是，如果一个程序正在阅读邮箱，而另一个用户试图删除编号为25的邮件，会怎么样？ 因此，正在阅读的用户可能意外退出，或显示与邮箱的实际状态不匹配的错误视图。 所以为了安全，读邮箱地址也要特别注意。
将邮箱视为数据库，将每封邮件视为表中的一行，就很容易理解了。 在这种场合，问题都很相似。 例如，修改数据库表中的行与删除或修改邮箱文件中的邮件信息非常类似。
解决这种经典问题的方法是使用并发控制，并发控制的概念很简单。 在处理并发读取或并发写入时，系统使用一系列锁定系统来解决问题。 该锁定系统由两种锁定组成，通常为共享锁(Shared Lock)和排他锁(Exclusive Lock)，或者叫读锁(Read Lock)和写锁(Write Lock)。
无需在意锁定技术的具体实现方式，现在相关锁定的概念在以下：中进行描述
某个资源的读锁定是共享的，或者彼此不阻止。 同时，多个用户可以读取相同的资源，而不会相互干扰。 另一方面，写锁定是排他的。 也就是说，一个写入锁定阻止其他读取锁定和写入锁定。 从安全策略的角度看，在一段时间内只有一个用户可以写入写入资源，而在用户执行写入操作时防止其他用户读取相同的资源。
在数据库中，锁定随时随地发生。 如果一个用户修改了部分数据，MySQL将禁止其他用户读取相同的数据。 MySQL通常透明地实现锁定的内部管理。
2 .锁定粒度提高共享资源并发性的一种方法是使锁定对象更有选择性。 请记住，只锁定某些需要更改的数据，而不是所有资源。 更理想的方法是只正确锁定要修改的数据片。 无论何时，在特定资源上锁定的数据量越少，只要不相互冲突，就可以允许修改更多的井。
这样的问题是即使锁定也要消耗系统资源。 每个锁定操作(如获取锁定、检查是否已解除锁定以及解除锁定)都会增加系统开销。 如果管理管脚而不是读写数据需要很多时间，则可能会影响整个系统的性能。
锁定策略是指在锁开销和数据安全之间上寻求影响系统性能的平衡。 许多商业数据库服务器没有提供更多选择，它们通常对表进行行级锁定，并提供了在有锁定时提高系统性能的复杂方法
另一方面，MYSQL有多种选择。 每个MYSQL存储索引都可以提供自己的锁定策略或锁定粒度，并且在存储引擎的设计中可以实现锁定管理如果将锁定粒度调整到一定的级别，可能可以为某个APP应用程序提供适当的性能，但也可能导致存储无法用于其他用途。 MYSQL可以提供多个存储引用，因此不需要通用解决方案。 这里介绍了两个最重要的锁定策略
表锁(Table lock)
MYSQL的开销最小的锁策略是表锁表锁与上述邮箱锁机制：类似，添加了整个表。 当一个用户对表执行写入操作(插入、删除、更新等)时，用户可以获得写入锁定。 写入锁定禁止对其他用户进行读写。 此外，只有在没有人进行写入操作的情况下，用户才能获取读取锁定，在读取锁定期间彼此没有神经
在某些环境中，表锁的性能可能很好。 例如，READ LOCAL表锁支持某种并发写入。 此外，写锁定的优先级高于读取，即使有读取操作的用户已经排在队列中，从中请求的写锁定也可以位于锁定队列的开头。 写入锁定位于读取锁定之前，而读取镇不能位于写入锁定之前。
存储引擎管理着自己的锁，MYSQL本身也可以出于各种目的使用各种有效的表锁。 例如，MYSQL服务器可以在语句(如ALTER TABLE语句)中使用表锁，而不考虑存储引擎。
行级锁(Row locks)
行锁支持最大的并发处理。 同时，锁定开销也最大。 众所周知，行级锁定在INNODB和Falcon存储引擎中实现，也在其他存储引擎中实现。 行级锁定由存储引擎而不是MYSQL服务器实现，服务器完全不知道如何在存储引擎中实现锁定。
3 .事务ACID为原子性(Atomicity)、一致性(Consistency)隔离性(Isolation)和持久性(Durability)这些概念与事务处理标准密切相关，有效的事务处理系统必须符合相关标准。
原子性(Atomicity)
事务必须被视为单独的内部“不可分离”工作单元，以确保整个事务是执行还是全部回滚。 如果事务是原子的，则该事务绝对不会部分执行，而是完全执行或完全不执行。
一致性
( Consistency)数据库总是从一种一致性状态转换到另一种一致性状态。因为最终事务根本没有被提交，任何事务处理过程中所做的数据改变，也不会影响到数据库的内容。
隔离性( Isolation)
当某个事务的结果只有在完成之后才对其他事务可见。在上述例子中，当数据库执行完第3条语句，还未执后文讨论隔离级时，读者就会理解为什么我们所说的通常是“**不可见”( Invisible)**的。
持久性( Durability)
一旦一个事务提交，事务所做的数据改变将是永久的。这意味着数据改变已被记录，即使系统崩溃，数据也不会丢失。
4.隔离级隔离的问题比想象的要复杂。SQL标准定义了4类隔离级，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
下面简单介绍四种隔离级:
READ UNCOMITTED (读取未提交内容)
在READ UNCOMMITTED隔离级，所有事务都可以“看到”未提交事务的执行结果。在这种级别上，可能会产生很多问题，除非用户真的知道自己在做什么，并有很好的理由选择这样做。本隔离级很少用于实际应用，因为它的性能也不比其他级别好多少，而别的级别还有其他更多的优点。读取未提交数据，也被称之为“脏读”(Dirty Read)。
READ COMMITTED (读取提交内容)
大多数数据库系统的默认隔离级是READ COMMITTED (但这不是MySQL默认的!)。它满足了隔离的早先简单定义:一个事务在开始时，只能“看见”已经提交事务所做的改变，一个事务从开始到提交前，所做的任何数据改变都是不可见的，除非已经提交。这种隔离级别也支持所谓的“不可重复读”(Nonrepeatable Read)，这意味着用户运行同一语句两次，看到的结果是不同的。
REPEATABLE READ (可重读)
REPEATABLE READ隔离级解决了READ UNCOMMITTED隔离级导致的问题。它确保同一事务的多个实例在并发读取数据时，会“看到同样的“數据行。不过理论上，这会导致另一个棘手问题:幻读(Phantom Read)。简单来说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插人了新行，当用户再读取该范围的数据行时，会发现有新的“幻影”(Phantom) 行。InnoDB 和Falcon存储引擎通过参版本并发控制(Multiversion Concurrency Control)机制解决了幻读问题。本章后面将进一步村论这部分内容。
REPEATABLE READ 是MySQL的默认事务隔离级。InnoDB 和Falcon存储引擎都遵循这种设置，可参考第6章，了解如何改变这种设置。其他一些存储引擎也以此为默认设置，不过具体设置还要看相关引擎的具体规定。
SERIALIZABLE (可串行化)
SERIALIZABLE是最高级别的隔离级，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，SERIALIZABLE 是在每个读的数据行上加锁。在这个级别，可能导致大量的超时(Timeout)现象和锁竞争(Lock Contention) 现象。作者很少看到有用户选择这种隔离级。但如果用户的应用为了数据的稳定性，需要强制减少并发的话，也可以选择这种隔离级。表1-1总结了各种隔离级及相关的缺点。
表1-1: ANSI SQL隔离级
隔离级脏读可能性不可重复读可能性幻读可能性加锁读READ UNCOMITTED是是是否READ COMMITTED否是是否REPEATABLE READ否否是否SERIALIZABLE否否否是5.死锁死锁是指两个或多个事务在同一资源上互相占用，并请求加锁时，而导致的恶性循环现象。当多个事务以不同顺序试围加锁同一资源时，就会产生死锁。任何时间，多个事务同时加锁-一个资源，-定产生死锁。
例如，设想下列两个事务同时处理stockPrice表:
事务1
START TRANSACTION;
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 TRANSACTION;
UPDATE StockPrice SET high=20.12 WHERE stock id= 3 and date = ‘2002 -05-02’;
UPDATE StockPrice SET high = 47.20 WHERE stock id= 4 and date = ‘2002-05-01’;
COMMIT;
如果很不幸凑巧，每个事务在处理过程中，都执行了第一个查询，更新了数据行，也加锁了该数据行。接着，每个事务都去试图更新第二个数据行，却发现该行已被(对方)加锁，然后两个事务都开始互相等待对方完成，陷入无限等待中，除非有外部因素介人，才能解除死锁。
为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。对于更复杂的系统，例如InnoDB存储擎，可以预知循环相关性，并立刻返回错误。这种解决方式实际很有效，否则死锁将导致很慢的查询。其他的解决方式，是让查询达到一个锁等待超时时间，然后再放弃争用，但这种方法不够好。目前InnoDB处理死锁的方法是，回滚拥有最少排他行级锁的事务(一种对最易回滚事务的大致估算)
锁现象和锁顺序是因存储引擎而异的，某些存储引擎可能会因为使用某种顺序的语向导致死锁，其他的却不会。死锁现象具有双重性:有些是因真实的数据冲突产生的，无法避免，有些则是因为存储引擎的工作方式导致的。
如果不以部分或全部的方式回滚某个事务，死锁将无法解除。在事务性的系统中，这是个无法更改的事实。用户在设计应用时，就应考虑这种问题的处理，许多应用在事务开始时，可以做简单的判定，决定重做事务。
6.事务日志事务日志可使事务处理过程更加高效。和每次数据一改变就更新磁盘中表数据的方式不同，存储引擎可以先更新数据在内存中的拷贝。这非常快。然后，存储引擎将数据改变记录写人事务日志，它位于磁盘上，因此具有持久性。这相对较快，因为追加日志事件导致的写操作，只涉及了磁盘很小区城上的顺序I/O (Sequential 1/O)，而替代了写磁盘中表所需要的大量随机I/O (RandomI/O)。 最后，相关进程会在某个时间把表数据更新到磁盘上。因此，大多存储引擎都选用了这种技术，也是通常所说的预写式日志(Write Ahead Logging)， 利用两次磁盘写人操作把数据改变写人磁盘(注3)。
如果数据更新已写入事务日志，却还未写入磁盘的表中，而发生系统崩溃，存储引擎将会在重启后恢复相关数据改变。具体的恢复方式因存储引擎而异。