数据库优化1（逻辑结构）

写了几年的程序总结来说程序只是操作数据的一个逻辑，而对于数据库我自己并没那么深入的了解，经过一段时间的学习，就分享下自己的心得吧，

我个人对mysql数据库比较有好感，要先了解mysql数据库就先看看它的逻辑架构，下面有一张图：




其实数据库总的来说就两部分，数据库服务和数据仓库，前者是服务与我们对数据的管理，而后者就是来存储。来说说这个图
最上面的服务并不是mysql独有的，它仅仅只是基于网络的一个客户端或者是服务端。
第2层包含了mysql的核心服务：解析，分析，优化 ，缓存等等
第3层就是存储引擎了，负责对数据的存储和提取，这些引擎和linux的系统文件一样，各有千秋。

mysql服务会首先通过解析器解析sql，然后看是否在缓存中存在，存在就唉缓存中查询，否则就将sql进行优化，我们可以可以通过关键字来影响优化器，从而选择优化的决策，当然也可以修改mysql提供一些参数配置，让用户来选择优化的方式。

musql中最重要的一部分是并发控制，而谈到并发就不得不提锁，锁的颗粒度，（要提醒的是mysql是不支持行级锁的）和事务，
数据库事务要遵循的4大基本原则：ACID， 原子性，一致性，隔离性，持久性，对于这4个特性定义上的理解一定要非常深刻，这会影响到你是否能真正明白数据库应该如何优化，而糟糕的是这些概念性的定义确实比较抽象难以理解。
原子性：是用来保证一个事务成为一个最小单位切不可分割，也就是说在整个操作的过程中只有两种情况要么成功或者失败（我们先不考虑一直等待的情况）
一致性：这点比较难理解，在一个事务中，一些数据的状态可能会发生N次的变化，而一致性就要保证这些数据要么为初始的状态或者是完成的状态，而这种一致性其实是一种强一致性，是一种假象，这点在这里不做深究后面在讨论。
隔离性：在一个事务没有完成提交之前，我们其实是将该事务范围内的数“保护”起来的，也就是所谓的隔离起来让其他人不可见，这就是隔离性，但当我们去研究隔离级别的时候会发现隔离性的本质其实就是对一致性的一种破坏，而这也是数据库中安全性和性能取舍的本质所在
持久性：一但事务提交之后，数据就会永久的保存在数据库中。但我们真的去深究持久性的持久程度又是一个比较模糊的概念。

要保证事务的ACID是一件很难的事，所以会很影响性能，事务的本质就是锁，而有锁的地方必然放弃了性能，大神们为了能两者兼得做了很多事，主要是从锁的颗粒度和锁的“松紧”程度去考虑，所谓锁的颗粒度就是锁住内容的多少，通常来说，锁的越少 性能越高，而锁的“松紧”程度就是对隔离级别的调整，
隔离级别一共有4个级别：
read uncommitted（读未提交）
read commit（读已提交）
repeatable read （可重复读）
serializable（串行化）
他们的级别依次增高
很多文章只是仅仅对这4哥隔离级别做了一些区分，而没说明他们的本质，当然要真正说明清楚他们的的区别确实是一件很不容易的事
而且比较难理解，说到本质这要说到这4哥级别的历史和由来，在N年前（我不记得是几几年了）是只有一种级别的那就是串性化，后来一些聪明的人为了提高性能，总结的发现:对数据库的操作只有4总情况：分别是：读读 写写 读写 写读，聪明人发现在有些情况下是没有必要把隔离性控制的那么死的，放松一些是不会带来“太大的问题”，所以根据这4种情况依次建立了4层隔离级别，当然困难的写写这种情况是没人敢放宽的。mysql默认的隔离级别是repeatable
read，但大多数其他数据库的级别是 read commit（比如oracle），虽然repeatable read隔离级别会带来幻读的情况，但是mysql使用存储引擎有InnoDB，InnoDB底层使用的是MVCC快照隔离技术解决了幻读的情况。另外mysql还有其他的一些存储引擎：myisam，archive，csv等等。





以上是是对mysql结构上的大致了解，而对于数据库事务的理解还是太过去浅显，要真正理解事务的ACID的本质我们才能走的更远，包括后面我们要怎么处理在分布式数据库中如何保证事务的特性。