一、MySQL逻辑架构      

 

        中间是MySQL的核心服务，包括查询分析、优化、缓存及所有的内置函数(日期、时间、数据等)，所有跨存储的引擎的功能都在这一层实现：存储过程、触发器、视图等。
        存储引擎负责MySQL中的存储和提取。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含十几个底层函数，用于执行诸如"开始一个事务"或“根据主键提取一行记录”等操作。但是存储引擎不会去解析SQL，不同存储引擎之间也不会相互通信。

二、并发控制

        只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。

1、读写锁

        在处理并发读写时，可以通过实现一个由两种类型的锁组成的锁系统来解决问题。这两种锁通常被称为共享锁、排他锁，也叫(读锁、写锁)。
        读锁是共享的，多个客户在同一时间可以同时读取同一个资源，而互不干扰。
        写锁是排他的，一个写锁会阻塞其他写锁和读锁。只有这样才能确保在给定的时间里，只有一个用户能执行行写入，并防止其他用户读取正在写入的同一资源。

2、锁粒度

        一种提高共享资源并发性的方式就是让锁定的对象更具有选择性。尽量只锁定需要修改的部分数据，而不是所有资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。
        锁的各种操作，包括获取锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会因此受到影响。
        所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡。

        表锁

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

        行级锁

        行级锁可以最大程度的支持并发处理(同时也带来了最大的锁开销)。行级锁只在存储引擎层实现，而MySQL服务层没有实现。

三、事务

        事务就是一组原子性的SQL查询，或者说是一个独立的工作单元。如果数据库引擎能够成功的对数据库应用该组查询的全部语句，那么就执行该组查询。如果其中有任何一条语句应为崩溃或者其他原因无法执行，那么所有的语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。
        与事务相关的测试ACID测试。ACID：原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)。一个好的事务处理系统，必须具备这些标准。
        原子性：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部成功提交，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操纵。
        一致性：数据库总是从一个一致性状态转换到另一个一致性状态。银行转账A转给B，转账前和转帐后，AB账户的余额总数不变。
        隔离性：一般一个事务所做的修改在最终提交前，对其他事务是不可见的。
        持久性：一旦事务提交，则其所作的修改就会永久保存到数据库中。

1、隔离级别

        SQL标准中定义了四种隔离级别，每一种级别都规定了一个事务中所做的修改，那些在事务内和事务间是可见的，那些是不可见的。

        读未提交 read uncommitted
        事务中的修改即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读dirty read。从性能上来说对比读已提交没有很大的提升。

        读已提交 read committed
        一个事务从开始知道提交之前，所作的任何修改对其他事务都是不可见的，这个级别也叫不可重复读，因为两次执行相同的查询，可能得到的结果不一致。

        可重复读 repeatable read
        这个级别解决了脏读和不可重复读不能解决的问题。但不能解决幻读，当某个事务在读取某个范围内的记录时，另一个事务又在该范围内插入了新的数据，当前一个事务再次执行时，就会产生幻行。InnoDB通过多版本并发控制(mvcc)解决了此问题。MySQL默认

        串行化 serializable
        此级别为最高级别。通过强制事务串行化执行，避免了幻读问题。此级别会在每一行数据上都加锁，可能导致大量的超时和锁争用的问题。

2、死锁

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

3、MySQL中的事务

        MySQL提供了两种支持事务的存储引擎：InnoDB、NDB Cluster。

        自动提交(AUTOCOMMIT)
        MySQL默认采用自动提交模式。不是显式的开始一个事务，则每个查询都被当作一个事务执行提交操作。
        设置自动提交：set autocommit =1。1或on表示开启，0或off 表示关闭。

        MySQL可以通过执行 set  transaction isolation level命令来设置隔离级别。新的隔离级别会在下一个事务开始的时候生效。

        在事务中混合使用存储引擎
        在事务中混合使用了事务型和非事务型的表(InnoDB、MyISAM)，在正常提交的情况下不会有什么问题。
        但事务需要回滚，非事务型表上的更改便无法撤销，这会导致数据库处于不一致的状态。

四、多版本并发控制

        MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，一般都同时实现了多版本并发控制(MVCC)。
        MVCC在很多情况下避免了加锁操作，因此开销更低。大都实现了非阻塞的读操作，写操作也只锁定必要的行。
        InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间(或删除时间)。当然存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版号都会自动递增。事务开始时刻的系统版本号作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
        具体操作：

        select
                只会查询符合下列条件的数据:
                        1、查找版本早于当前事务的数据行(行的系统版本号小于或等于事务的系统版本)，
                               这样可以确保事务读取的行，要么是在事务开始前已存在，要么是事务自己处
                               理过的。
                        2、行的删除版本未定义，要么大于当前事务版本号。可以确保事务读取到的行，
                              在事务开始之前被删除。

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

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

        update
                为新行保存当前系统版本号为行版本号，为旧行保存当前系统版本号作为删除标识。 

       保存这两个额外系统版本号，使大多数读操作都可以不用加锁。读取操作简单，性能好，并且保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查。
       MVCC只在读已提交、可重复读两个隔离级别下工作。