【mysql数据库001】mysql数据库的逻辑架构
MYSQL服务器逻辑架构图
最上层的服务并不是MYSQL所独有的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构。例如：链接处理、授权认证、安全等等。
第二层架构MYSQL的核心宫鞥你都再这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如、日期、时间）所有跨存储引起的功能都在这一层实现：存储过程、触发器、视图
第三层包含了存储引擎。存储引擎负责MYSQL中书籍的存储和提取。MYSQL支持多种存储引擎，每个存储引擎都有它的优势和劣势。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。
1.1连接管理与安全性
每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询值会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或销毁线程。
1.2优化与执行
MYSQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询，决定表的读写顺序，以及选择合适的索引等。用户看奕通过特殊的关键字提示(hint)优化器，影响它的决策过程。也可以请求优化器解释(explain) 。优化过程的各个因素。（标红色的应用很多，很多SQL的优化，索引的排查都可以用它）。使用户可以知道服务器是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和schema，修改相关配置，使应用极可能高效运行。
1.3 并发控制
无论何时，只要有多个查询需要在同一时刻修改数据，都会产生并发控制的问题。
此次只分析两个层面：1.服务器层面 ；2.存储引擎层面
Mysql是如何控制并发读写？
1.3.1读写锁
通用的理论，读 -读 可以共享；读-写 互斥；写-写互斥
专业术语叫 ：共享锁（share lock），排他锁(exclusive lock)；
Java语言里面也有大量的锁，也有各种前辈为了提升性能做出的各种不懈的努力。从大的方面这些锁的优化方向
可以从锁的粒度来进行。
1.3.2锁粒度
一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发度越高，只要相互间不发生冲突即可。
加锁也是需要耗费性能的，选择合适 的锁策略，就是在锁的开销和数据的安全之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库系统没有提供更多的选择，一般都是在表上面施加行锁(row-level lock ).并以各种复杂的方式来实现，以便在锁比较多的情况下尽可能的提供更好的性能。
表锁
表锁是MYSQL中最基本的锁策略，并且是开销最小的策略。它会锁定整张表。一个用户在对表进行写操作（插入，删出，更新等）前，需要先获得写锁，这会阻塞其他用户对该表的读写操作。只有没有读写锁时，其他读取 的用户才能获得读锁，读锁之间是不相互阻塞的。
在特定的场景中，表锁也可能有良好的性能。例如：READ LOCAL 表锁支持某些类型的并发写操作。另外，写锁也比读锁具有更高的优先级，因此一个写锁请求可能会被插入到读锁的队列的前面（写锁可以插入到锁队列中读锁的前面，反之读锁则不能查到写锁的前面）
尽管存储引擎也可以管理自己的锁，MYSQl 本身还是会使用各种有效的表锁来实现不同的目的。例如：服务器会为诸如 ALTER TABLE 之类的语句使用表锁，而忽略存储引擎的锁机制。
行级锁
行级锁可以最大程度的支持并发处理（同事也带来了最大的锁开销）。中所周知，在InnoDB中实现了行级锁。行级锁只在存储引擎层面实现，而MYSQL服务器层，没有实现。服务器层完全不了解存储引擎中的锁实现。
1.4事务
事务就是一组原子性的SQL操作，如果数据库引擎能够成功的对数据库应用该组操作语句，那么就执行该组操作。如果其中有任何一条语句因为崩溃或者其他原因无法执行，那么所有的语句都不会执行。也就是说，事务内的语句，要么全执行成功，要么全执行失败。
谈起数据库事务就绕不开ACID特性
原子性（atomictity）
一致性（consistency）
隔离性(isolation)
持久性(durability)
隔离级别
在SQL标准中定义了4中隔离级别，每一种级别都规定了一个事务中所做的修改，哪些在事务内和事务间是可见的，哪些是不可见的。较低级别的隔离通常可以执行更高的并发，系统的开销也更低。
REDA_UNCOMMITTED(未提交读)
在READ_UNCOMMITED 级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来讲，不会比其他的级别好太多，但却缺乏其他的级别的很多好处，除非真有非常必要的理由，在实际应用中，一般很少使用。
READ_COMMITTED（读已提交）
大多数数据库系统的默认隔离级别都是READ_COMMITED(但MYSQL不是)。它满足前面提到的隔离性的简单定义：一个事务开始时，只能看到已经提交的事务所作的修改。换句话说，一个事务从开始直到提交之前，所做的的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读（noreapeatable read）,因为两次执行相同的查询，可能会得到不一样的结果。
REPEATABLE_READ(可重复度)
此解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行（Phantom Row）. 的问题。InnoDB 存储引擎通过多版本并发控制(MVCC) muti version Concurrency Controller 解决了幻读的问题。
可重复读似乎MYSQL默认的事务隔离级别。
SERAILIZABLE（可串行化）
串行化是最高的隔离级别。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，串行化会在去读的每一行上都加上锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别。只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。
1.4.1死锁
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。最常见的有当多个事务试图以不同的顺序锁定资源的时候，就可能会产生死锁。多个事务同时锁定同一个资源，也会产生死锁。
最常见的即使 A -B 和B-A 问题
即 执行 时 事务1 锁定了A ，等待锁定B的时候 ，事务2 先锁定了B ，然后尝试去获取A的锁，这样就会产生死锁。
为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立刻返回一个错误。这种解决方案很有效，否则死锁会导致出现非常慢的查询语句。还有一种解决方案，就是当查询的时间达到锁的等待超时的设定后放弃锁请求，这种方式通常来说不太友好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。
1.4.2事务日志
事务日志可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久的磁盘上的事务日志中，而不用每次都将修改的数据本身持久化到磁盘上。事务日志采用的是追假的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像是随机I/O需要再磁盘的多个地方来回移动磁头，所以采用事务日志的方式相对来说要快的多。事务日志持久化以后，内存中被修改的数据再后台可以慢慢的刷回到磁盘。目前大多数据存储引擎都是这样实现的，我们通常称之为预写式日志（Write-Ahead Logging）,修改数据需要写两次磁盘（写操作日志，和写数据）。
如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时候能够自动恢复这部分修改的数据。具体的恢复方式视存储引擎而定。
这种思路 是结合了 硬盘的特点和操作系统的特性，大多数存储类的系统都有此设计。 阅读Rocket源码的时候发现里面也有这种设计思路。日志文件顺序写，性能比内存差不了太多，然后在异步处理数据变更。
具体想深入研究数据库可搞本书看看
本文参考《高性能MYSQL第3版》