1. 计算机组成原理(三)存储系统
辅存中的数据要调入主存后才能被CPU访问
按存储介质，存储器可分为磁表面存储器（磁盘、磁带)、磁心存储器半导体存储器（MOS型存储器、双极型存储器）和光存储器（光盘)。
随机存取存储器（RAM）：读写任何一个存储单元所需时间都相同，与存储单元所在的物理位置无关，如内存条等
顺序存取存储器（SAM）：读写一个存储单元所需时间取决于存储单元所在的物理位置，如磁盘等
直接存取存储器（DAM）：既有随机存取特性，也有顺序存取特性。先直接选取信息所在区域，然后按顺序方式存取。如硬盘等
相联存储器，即可以按内容访问的存储器（CAM）可以按照内容检索到存储位置进行读写，“快表”就是一种相联存储器
读写存储器—即可读、也可写（如：磁盘、内存、Cache）
只读存储器—只能读，不能写（如：实体音乐专辑通常采用CD-ROM，实体电影采用蓝光光盘，BIOS通常写在ROM中）
断电后，存储信息消失的存储器——易失性存储器（主存、Cache）
断电后，存储信息依然保持的存储器——非易失性存储器（磁盘、光盘）
信息读出后，原存储信息被破坏——破坏性读出（如DRAM芯片，读出数据后要进行重写）
信息读出后，原存储信息不被破坏——非破坏性读出（如SRAM芯片、磁盘、光盘）
存储器芯片的基本电路如下
封装后如下图所示
图中的每条线都会对应一个金属引脚，另外还有供电引脚、接地引脚，故可以由此求引脚数目
n位地址对应2 n 个存储单元
假如有8k×8位的存储芯片，即
现代计算机通常按字节编址，即每个字节对应一个地址
但也支持按字节寻址、按字寻址、按半字寻址、按双字寻址
(Dynamic Random Access Memory，DRAM)即动态RAM，使用栅极电容存储信息
(Static Random Access Memory，SRAM)即静态RAM，使用双稳态触发器存储信息
DRAM用于主存、SRAM用于Cache，两者都属于易失性存储器
简单模型下需要有 根选通线，而行列地址下仅需 根选通线
ROM芯片具有非易失性，断电后数据不会丢失
主板上的BIOS芯片（ROM），存储了“自举装入程序”，负责引导装入操作系统（开机）。逻辑上，主存由 辅存RAM+ROM组成，且二者常统一编址
位扩展的连接方式是将多个存储芯片的地址端、片选端和读写控制端相应并联，数据端分别引出。
字扩展是指增加存储器中字的数量，而位数不变。字扩展将芯片的地址线、数据线、读写控制线相应并联，而由片选信号来区分各芯片的地址范围。
实际上，存储器往往需要同时扩充字和位。字位同时扩展是指既增加存储字的数量，又增加存储字长。
两个端口对同一主存操作有以下4种情况：
当出现(3)(4)时，置“忙”信号为0，由判断逻辑决定暂时关闭一个端口（即被延时），未被关闭的端口正常访问，被关闭的端口延长一个很短的时间段后再访问。
多体并行存储器由多体模块组成。每个模块都有相同的容量和存取速度，各模块都有独立的读写控制电路、地址寄存器和数据寄存器。它们既能并行工作，又能交义工作。多体并行存储器分为高位交叉编址（顺序方式)和低位交叉编址（交叉方式)两种.
①高位交叉编址
②低位交叉编址
采用“流水线”的方式并行存取（宏观上并行，微观上串行）,连续取n个存储字耗时可缩短为
宏观上，一个存储周期内，m体交叉存储器可以提供的数据量为单个模块的m倍。存取周期为T，存取时间/总线传输周期为r，为了使流水线不间断，应保证模块数
单体多字系统的特点是存储器中只有一个存储体，每个存储单元存储m个字，总线宽度也为m个字。一次并行读出m个字，地址必须顺序排列并处于同一存储单元。
缺点：每次只能同时取m个字，不能单独取其中某个字；指令和数据在主存内必须是连续存放的
为便于Cache 和主存之间交换信息，Cache 和主存都被划分为相等的块，Cache 块又称Cache 行，每块由若干字节组成。块的长度称为块长(Cache 行长)。由于Cache 的容量远小于主存的容盘，所以Cache中的块数要远少于主存中的块数，它仅保存主存中最活跃的若干块的副本。因此 Cache 按照某种策略，预测CPU在未来一段时间内欲访存的数据，将其装入Cache.
将某些主存块复制到Cache中，缓和CPU与主存之间的速度矛盾
CPU欲访问的信息已在Cache中的比率称为命中率H。先访问Cache，若Cache未命中再访问主存，系统的平均访问时间t 为
同时访问Cache和主存，若Cache命中则立即停止访问主存系统的平均访问时间t 为
空间局部性：在最近的未来要用到的信息(指令和数据)，很可能与现在正在使用的信息在存储空间上是邻近的
时间局部性：在最近的未来要用到的信息，很可能是现在正在使用的信息
基于局部性原理，不难想到，可以把CPU目前访问的地址“周围”的部分数据放到Cache中
直接映射方式不需要考虑替换算法，仅全相联映射和组相联映射需要考虑
①随机算法(RAND):若Cache已满，则随机选择一块替换。实现简单，但完全没考虑局部性原理，命中率低，实际效果很不稳定
②先进先出算法(FIFO):若Cache已满，则替换最先被调入Cache的块。实现简单，依然没考虑局部性原理
③近期最少使用算法(LRU):为每一个Cache块设置一个“计数器”，用于记录每个Cache块已经有多久没被访问了。当Cache满后替换“计数器”最大的.基于“局部性原理”，LRU算法的实际运行效果优秀，Cache命中率高。
④最不经常使用算法(LFU):为每一个Cache块设置一个“计数器”，用于记录每个Cache块被访问过几次。当Cache满后替换“计数器”最小的.并没有很好地遵循局部性原理，因此实际运行效果不如LRU
现代计算机常采用多级Cache，各级Cache之间常采用“全写法+非写分配法”；Cache-主存之间常采用“写回法+写分配法”
写回法(write-back)：当CPU对Cache写命中时，只修改Cache的内容，而不立即写入主存，只有当此块被换出时才写回主存。减少了访存次数，但存在数据不一致的隐患。
全写法(写直通法，write-through)：当CPU对Cache写命中时，必须把数据同时写入Cache和主存，一般使用写缓冲(write buffer)。使用写缓冲，CPU写的速度很快，若写操作不频繁，则效果很好。若写操作很频繁，可能会因为写缓冲饱和而发生阻塞访存次数增加，速度变慢，但更能保证数据一致性
写分配法(write-allocate)：当CPU对Cache写不命中时，把主存中的块调入Cache，在Cache中修改。通常搭配写回法使用。
非写分配法(not-write-allocate)：当CPU对Cache写不命中时只写入主存，不调入Cache。搭配全写法使用。
页式存储系统：一个程序(进程)在逻辑上被分为若干个大小相等的“页面”， “页面”大小与“块”的大小相同 。每个页面可以离散地放入不同的主存块中。CPU执行的机器指令中，使用的是“逻辑地址”，因此需要通“页表”将逻辑地址转为物理地址。页表的作用：记录了每个逻辑页面存放在哪个主存块中
逻辑地址（虚地址）：程序员视角看到的地址
物理地址（实地址）：实际在主存中的地址
快表是一种“相联存储器”，可以按内容寻访，表中存储的是页表项的副本；Cache中存储的是主存块的副本
地址映射表中每一行都有对应的标记项
主存-辅存：实现虚拟存储系统，解决了主存容量不够的问题
Cache-主存：解决了主存与CPU速度不匹配的问题
2. 分布式基础-存储引擎
题目和文章内容有点不太符合,这里存储引擎是指单机存储引擎。对于分布式存储系统来说，存储引擎是必须的。存储引擎决定了数据在内存和磁盘中具体如何存储的，如何方便地拿出来的问题。可以说直接决定了存储系统的性能和可以干什么，不可以干什么的问题；本文参考《数据密集型应用系统的设计》 和《大规模分布式存储系统原理解析和架构实战》。
存储系统的功能做机制的简化就是存储和查询，如果从一般功能出发就是基础的增删改查。从最简单的开始想起，最简单的存储系统，无非就是把数据直接写入到文件中（可以按照K,V一行方式存储），需要的时候就顺序读取文件，找到可以需要查询的行。这在少量的数据的时候并没有问题，但是如果是大批量数据，几百MB或者几GB，甚至TB，PB的时候，顺序读取大量文件那速度慢的吓人。
顺序读取文件做遍历查找，速度很慢，我们第一想到的思路是建索引，索引最常用的就是哈希表了，如果我们对文件中的数据建个索引，Key 保存着我们下次要查询的值，Value对应这哪个文件的哪个位置。在内存中保存这个索引，下次查询的时候，我们通过哈希表快速定位到文件和位置，就可以迅速取到需要的值了。Bitcask折中日志型小型文件系统就采用这种存储方法，它可以提供高性能的读写，只需要经过一次磁盘的寻址就可以获取到所需要的数据。
作为日志型的存储系统，Bitcask的删除和修改是通过顺序记录到文件中，并不是对原来的文件进行修改，这减少了随机磁盘的读写操作。数据写入到文件中，如果一直写，显然文件越来越大，不便于操作，所以限制文件的大小，当大小达到一定规模后，重新写入一个文件。 对于更新和删除的数据，如果不处理，会产生大量的垃圾数据，占用了空间，所以后台会定时进行文件合并，合并的时候删除标记删除的具体数据。
Bitcask
哈希存储引擎的数据分为两份，一份是内存中的数据，一个是磁盘的文件，系统崩溃后，磁盘中的哈希表就没有了。如果恢复的时候通过读取文件的方式也是可以重建的，但是如果文件很多，很大，恢复的时间就会很长，Bitcask对每个段的文件的哈希表快照存储在文件中，下次恢复的时候可以快速恢复。
Bitcask只有一个写入线程追加，可以采用多个读取的线程并发读取，性能上还是很不错。
哈希存储引擎 因为采用哈希表，查找的性能不错，但是同样因为采用哈希存储引擎，会导致范围查询，只能通过遍历的方式去查询数据，范围查询慢。
刚才结构也说了，索引必须可以保存在内存中，才可以性能够好，但是如果数据量超大，内存中无法保存，保存到磁盘中，会产生大量的随机访问。另外哈希还存在着哈希冲突的问题。
刚才的哈希存储引擎的两个缺点，一是范围查询性能很差，我们要做范围查询，最好数据是有序的，有序的就可以不用遍历全部数据去做范围查询了。所以我们内存的数据不就不适合哈希索引，我们可以考虑改造成一个支持排序的数据结构。 另外刚才的哈希存储引擎，数据是按照顺序写入到数据文件中的，如果同一个key的多次更新，只保留最后一个数据的时候，是不是挺麻烦。
我们可以将文件中和内存中的数据都排序，这种格式称为排序字符串，在Level DB中叫SSTable。文件中的K-V结构排序后，好处是我们在做多文件合并的时候，可以按照多路归并的算法，快速排序，用多个指针依次比较和后移就可以办到。多个文件含有同一个值的时候，我们可以保留最新的字段值。
内存中的数据排序后，我们不一定对所有的数据的key都保存，可以只保存部分，根据key的排序特性，也可以很容易找到要找的值。 由于要对内存中的数据排队，而且数据要经常插入和删除，所以红黑树和AVL树是比较适合这种场合。对于存储在磁盘上的文件，也是有序的，用普通的AVL树或红黑树，保存到磁盘上后，数据多的话，树的层次会很高，这样通过多个指针需要多次随机读取，所以一般采用专门为大数据存储磁盘而设计的B+树，B+树的每个节点的分叉很多，一个节点可能有上千个分支。这样很少的层次就可以支持大量的数据了。
这种引擎如何写入数据：
如何读取数据：
这个存储引擎就是LSM 存储引擎的本质了，Level DB 就是采用这个存储引擎的。
类似的存储引擎还用于HBASE，以前还记得学习HBase的时候minor compaction（少量的HFile合适小文件合并，为提升性能同时减少IO压力）和major compaction（一个Node节点的所有文件合并），还比较迷茫。 从上图的Level DB存储引擎图可以看出，数据处理过程：
说明清单文件保存的是元数据信息，记录了每个SSTable文件所属的Level，文件中的key的最大值和最小值。同时由于SSTable文件经常变动的，所以增加个当前文件指向当前的清单文件这样操作起来就不用加锁了。
相对于以上两种引擎，B树存储引擎应用的最广泛，在关系型数据库中运用的很多。B树存储引擎不光支持随机查询，还很好地支持范围查询。像SSTable一样，B树引擎同样保持了对key的排序。在文件存储上，还是有很大的差异。LSM存储引擎的段文件大小不一，是顺序写入到磁盘的。B-Tree不像LSM树那样有内存表和SSTable，而只有一个B树，当然一些顶层块常在内存中。
B树是按照块存储数据库的数据的，它一般是一个多叉树，比如InnoDB引擎采用B+树存储，每个节点大概有1200个子分支。B树分为叶子节点和非叶子节点，叶子节点存储的是key和具体的数据，而非叶子节点存的是key和磁盘地址。
B树存储结构
以B+树为例说明查询和插入的基本流程
读取一个节点，如果对应的节点所在的数据页不在内存中，需要按照下面的过程从磁盘中读取，然后缓存在内存中。
插入和更新按照InnoDB引擎为例的话,还是比较复杂。
实际中还涉及到bin log日志。可以看到实际工程中，B-树引擎还是通过redo log这种WAL日志，用顺序磁盘读写替换了随机读写；change buffer 减少了随机读数据的过程，可以合并多条修改记录，一次性写，增加了性能。
B树和LSM树相比有以下特点： B-树引擎特点：
3. 数据 写入硬盘的顺序
简单来说：硬盘写入数据是从外向内写的。最外圈是0磁道。目前绝大多数硬盘是用温彻斯特（Winchester）技术制造的硬盘，所以也被称为温盘。所以个个厂家都是一样的。
具体的硬盘读写原理：
系统将文件存储到磁盘上时，按柱面、磁头、扇区的方式进行，即最先是第1磁道的第一磁头下（也就是第1盘面的第一磁道）的所有扇区，然后，是同一柱面的下一磁头（也就是第2盘面的第一磁道），……，一个柱面存储满后就推进到下一个柱面，直到把文件内容全部写入磁盘。如果中间有其他文件已经使用了一部分扇区，那就跳过。
系统也以相同的顺序读出数据。读出数据时通过告诉磁盘控制器要读出扇区所在的柱面号、磁头号和扇区号（物理地址的三个组成部分）进行。磁盘控制器则 直接使磁头部件步进到相应的柱面，选通相应的磁头，等待要求的扇区移动到磁头下。在扇区到来时，磁盘控制器读出每个扇区的头标，把这些头标中的地址信息与 期待检出的磁头和柱面号做比较（即寻道），然后，寻找要求的扇区号。待磁盘控制器找到该扇区头标时，根据其任务是写扇区还是读扇区，来决定是转换写电路， 还是读出数据和尾部记录。找到扇区后，磁盘控制器必须在继续寻找下一个扇区之前对该扇区的信息进行后处理。如果是读数据，控制器计算此数据的ECC码，然 后，把ECC码与已记录的ECC码相比较。如果是写数据，控制器计算出此数据的ECC码，与数据一起存储。在控制器对此扇区中的数据进行必要处理期间，磁 盘继续旋转。
温彻斯特（Winchester）技术：
硬盘停转时，磁头停留在启停区。当硬盘开始旋转后，旋转速度达到额定的高速时，磁头就会因盘片旋转产生的气流而抬起， 这时磁头才向盘片存放数据的区域移动。
盘片旋转产生的气流相当强，足以使磁头托起，并与盘面保持一个微小的距离。这个距离越小，磁头读写数据的灵敏度就越高，当然对硬盘各部件的要求也越 高。早期设计的磁盘驱动器使磁头保持在盘面上方几微米处飞行。稍后一些设计使磁头在盘面上的飞行高度降到约0.1μm～0.5μm，现在的水平已经达到 0.005μm～0.01μm，这只是人类头发直径的千分之一。
气流既能使磁头脱离开盘面，又能使它保持在离盘面足够近的地方，非常紧密地跟随着磁盘表面呈起伏运动，使磁头飞行处于严格受控状态。磁头必须飞行在盘面上方，而不是接触盘面，这种位置可避免擦伤磁性涂层，而更重要的是不让磁性涂层损伤磁头。
但是，磁头也不能离盘面太远，否则，就不能使盘面达到足够强的磁化，难以读出盘上的磁化翻转（磁极转换形式，是磁盘上实际记录数据的方式）。
4. QT存储日志用数据库还是txt文本
QT存储日志用数据库还是txt文本是需要具体问题具体分析的，因为如果小量的写数据库没事。如果是大量的，肯定写文件好。汇总后写程序导入数据库。还有一种方法是写redis等内存数据库，并累积数量后触发合并写入数据库操作。
并且如果这个日志是需要定期分析的，写在数据库里更方便处理；反之只是留档，就存文件里 但2种方式都要注意写操作的频率。
绝对不能产生一行写一行，中间加一个内存队列来过渡，比如memcache，有新日志就加入队列，然后做个定时器去批量写入文件并清空队列，同时也规避文件冲突了。
QT存储中大端模式和小端模式是：
对于long long a 和 struct{ char a;short b;int c;}二者同样占据了8个字节的空间，在存储上，后者则是先存储一个char，空一个字节，然后按照大端/小端模式存储short，最后按照大端/小端模式存储int。
在我们日常使用的x86架构的计算机中（其他类别的可能会采用大端模式或可配置模式，可以通过查阅资料或者用下文的代码进行测试），都是使用的小端模式，而网络字节序是大端模式的。
这就使得在网络通信时进行字节序的转换变得极为重要。比方说，通信双方规定了了通信头为一个4字节的魔数（Magic Number），而一方按着大端序的模式发送。
一方按着小端序的模式解读，那么两方的通信就会失败。如果没有这个魔数，而在内部的数据中出现这样的问题则会更加的麻烦。
5. sql Server日志作用以及为什么先写日志后写数据
今天在看Oracle的BackupGroundProcess，里边有一段是写到为什么先写日志后写数据的：LGWR, on the other hand, does lots of sequential writes to the redo log. This is an important distinction and one of the reasons that Oracle has a redo log and the LGWR process as well as the DBWn process. Scattered writes are significantly slower than sequential writes. By having the SGA buffer dirty blocks and the LGWR process do large sequential writes that can re-create these dirty buffers, we achieve an increase in performance. 其实SQL Server也是一样，每一个SQL Server的数据库都会按照其修改数据(insert,update,delete)的顺序将对应的日志记录到日志文件.SQL Server使用了Write-Ahead logging技术来保证了事务日志的原子性和持久性.而这项技术不仅仅保证了ACID中的原子性(A)和持久性(D),还大大减少了IO操作，把对数据的修改提交到磁盘的工作交给lazy-writer和checkpoint.预写式日志（Write-Ahead Logging (WAL)）SQL Server使用了WAL来确保了事务的原子性和持久性.实际上，不光是SQL Server,基本上主流的关系数据库包括oracle,mysql,db2都使用了WAL技术.WAL的核心思想是:在数据写入到数据库之前，先写入到日志.因为对于数据的每笔修改都记录在日志中，所以将对于数据的修改实时写入到磁盘并没有太大意义，即使当SQL Server发生意外崩溃时，在恢复(recovery)过程中那些不该写入已经写入到磁盘的数据会被回滚(RollBack),而那些应该写入磁盘却没有写入的数据会被重做(Redo)。从而保证了持久性(Durability)但WAL不仅仅是保证了原子性和持久性。还会提高性能.硬盘是通过旋转来读取数据,通过WAL技术，每次提交的修改数据的事务并不会马上反映到数据库中，而是先记录到日志.在随后的CheckPoint和lazy Writer中一并提交,如果没有WAL技术则需要每次提交数据时写入数据库:而使用WAL合并写入，会大大减少磁盘IO：也许你会有疑问，那每次对于修改的数据还是会写入日志文件.同样消耗磁盘IO。上篇文章讲过，每一笔写入日志的记录都是按照先后顺序，给定顺序编号的LSN进行写入的，日志只会写入到日志文件的逻辑末端。而不像数据那样，可能会写到磁盘的各个地方.所以，写入日志的开销会比写入数据的开销小很多。SQL Server修改数据的步骤SQL Server对于数据的修改,会分为以下几个步骤顺序执行:1.在SQL Server的缓冲区的日志中写入”Begin Tran”记录2.在SQL Server的缓冲区的日志页写入要修改的信息3.在SQL Server的缓冲区将要修改的数据写入数据页4.在SQL Server的缓冲区的日志中写入”Commit”记录5.将缓冲区的日志写入日志文件6.发送确认信息(ACK)到客户端(SMSS,ODBC等）可以看到,事务日志并不是一步步写入磁盘.而是首先写入缓冲区后，一次性写入日志到磁盘.这样既能在日志写入磁盘这块减少IO，还能保证日志LSN的顺序.上面的步骤可以看出，即使事务已经到了Commit阶段，也仅仅只是把缓冲区的日志页写入日志，并没有把数据写入数据库.那将要修改的数据页写入数据库是在何时发生的呢?Lazy Writer和CheckPoint上面提到，SQL Server修改数据的步骤中并没有包含将数据实际写入到磁盘的过程.实际上，将缓冲区内的页写入到磁盘是通过两个过程中的一个实现：这两个过程分别为:1.CheckPoint2.Lazy Writer任何在缓冲区被修改的页都会被标记为“脏”页。将这个脏页写入到数据磁盘就是CheckPoint或者Lazy Writer的工作.当事务遇到Commit时，仅仅是将缓冲区的所有日志页写入磁盘中的日志文件:而直到Lazy Writer或CheckPoint时，才真正将缓冲区的数据页写入磁盘文件:前面说过，日志文件中的LSN号是可以比较的，如果LSN2>LSN1,则说明LSN2的发生时间晚于LSN1的发生时间。CheckPoint或Lazy Writer通过将日志文件末尾的LSN号和缓冲区中数据文件的LSN进行对比，只有缓冲区内LSN号小于日志文件末尾的LSN号的数据才会被写入到磁盘中的数据库。因此确保了WAL（在数据写入到数据库之前，先写入日志)。Lazy Writer和CheckPoint的区别Lazy Writer和CheckPoint往往容易混淆。因为Lazy Writer和CheckPoint都是将缓冲区内的“脏”页写入到磁盘文件当中。但这也仅仅是他们唯一的相同点了。Lazy Writer存在的目的是对缓冲区进行管理。当缓冲区达到某一临界值时，Lazy Writer会将缓冲区内的脏页存入磁盘文件中，而将未修改的页释放并回收资源。而CheckPoint存在的意义是减少服务器的恢复时间(Recovery Time).CheckPoint就像他的名字指示的那样，是一个存档点.CheckPoint会定期发生.来将缓冲区内的“脏”页写入磁盘。但不像Lazy Writer,Checkpoint对SQL Server的内存管理毫无兴趣。所以CheckPoint也就意味着在这个点之前的所有修改都已经保存到了磁盘.这里要注意的是：CheckPoint会将所有缓冲区的脏页写入磁盘，不管脏页中的数据是否已经Commit。这意味着有可能已经写入磁盘的“脏页”会在之后回滚（RollBack).不过不用担心，如果数据回滚，SQL Server会将缓冲区内的页再次修改，并写入磁盘。通过CheckPoint的运作机制可以看出，CheckPoint的间歇(Recovery Interval)长短有可能会对性能产生影响。这个CheckPoint的间歇是一个服务器级别的参数。可以通过sp_config进行配置，也可以在SSMS中进行配置:恢复间歇的默认参数是0，意味着由SQL Server来管理这个回复间隔。而自己设置恢复间隔也是需要根据具体情况来进行界定。
6. 邮件服务器邮件存储和日志的介绍
本文以数据库的基本原理为基础，分析了EXCHANGE SERVER的存储系统，并说明了各部分的作用。
一、IS服务和ESE的层次关系
IS服务是EXCHANGE服务器中重要的服务之一，它控制着对邮箱和PF的存储操作请求，EXCHANGE服务器的存储实际上是由ESE的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，目前在微软的很多产品中都有广泛的应用，如：AD数据库、DHCP、WINS、SRS等等。
EXCHANGE的数据库是由EDB文件、STM文件和LOG文件组成。在这些文件里，微软使用了“B+树”的内部数据结构。ESE的引擎的任务之一，就是当IS服务请求访问数据库的时候，把这些请求转化为对内部数据结构的读写访问。B+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用“B+树”作为ESE的后台结构的主要原因，就是尽可能的提高访问数据时I/O性能。当然，这些结构对于EXCHANGE STORE来说是透明的。
另外，作为一个数据库系统，ESE有责任提供事务级别的操作的支持，并维护数据库的完整性和一致性。对数据库系统而言，我们提到事务时，一般用ACID来描述事务的特点。
A--Atomic（原子的）：事务必须是全或全无的操作，要么全部成功更新，要么全部不被更新
C--Consistent（一致的）：一个成功提交的事务必须使数据库处于一个一致的状态。
I--Isolated（孤立的）：所有未提交的更改都必须能够和其他事务孤立。
D--Durable（持久的）：当事务一旦提交，所做的更改必须存储到稳定的介质上，防止系统失败导致的数据库不一致。（此点非常重要！！）
二、EXCHANGE 2000/2003存储系统的新特点
在EX5.5中，ESE的版本为ESE97，而在EX2000/2003里，ESE版本已经升级ESE98了。ESE引起在以下方面得到了改进：
* I/O性能进一步提高和优化
* 对日志文件增加了计算校验操作
* 提高了ESEUTIL等工具的维护速度
而IS也在以下方面有了更新：
* 在每个SERVER上提供多个SG支持
* 数据库STM文件格式的引入，提高了INTERNET邮件的性能
* WSS的引入，用户可以使用多种协议访问数据库
三、EDB和STM的关系
常有人问，EDB文件是数据库，那STM文件是做什么用的？可以删除吗？
在EX5.5里，只有EDB文件，因为在EX5.5发布时，微软主推的是内部邮件系统，因此其主要协议为MAPI，这是微软的私有邮件西医，EDB文件是专门为此协议优化过的。因此在EX5.5中，为了支持INTERNET邮件，必须在每次处理INTERNET邮件时，做一个格式转换。这显然带来了性能的损失。
在EX2000里，微软加大了对INTERNET邮件的支持，这就是STM文件的来源。MAPI格式是RPC和二进制标准的，而STM是纯文本加上一些MIME编码格式，这样的区别使得它们不可能存储在同一数据库里。因此EX2000中，微软开始使用EDB和STM两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说，它的邮箱实际上是跨越了EDB和STM文件共同组成的。另外，需要注意的是，EDB文件中还保留着用户的邮箱结构。所以EDB文件更加重要。那么EDB和STM是怎么协同工作的呢？我们以几个情景来分析之。
情景一：用户使用OUTLOOK（MAPI）发送接收邮件
在该情景下，用户将邮件通过MAPI协议提交给数据库，直接被保存EDB文件中。当用户通过MAPI访问邮箱里的邮件时，如果被访问的邮件在EDB里，直接返回，如果在STM里（如外来邮件），则执行转换，将STM转换为EDB文件格式，再返回用户。
情景二：用户使用标准SMTP/POP3/IMAP4等协议访问
用户使用非MAPI协议提交的邮件，内容保存在STM文件里，但是由于EDB里有邮箱结构，STM没有，因此系统会把邮件的重要信息提取出来，放在EDB里。当用户用MAPI提取邮件时，过程同上，当用户通过标准协议访问时，同样需要进行格式转换，转换为STM文件格式返回。 这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是紧密联系的缺一不可。所以，在任何时间我们都不要单独操作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向EDB文件请求邮箱结构信息，这是需要注意的。
四、LOG文件的重大作用
在论坛里经常会看到有人说我的硬盘怎么很快就没了，一看原来是日志文件搞的鬼，于是就有人删除日志文件，甚至使用循环日志来强制减少日志，甚至有人提出这样的疑问，日志到底有什么用？是不是多余的'？那我们来看看日志的重大作用。
对于一个SG来说，系统会产生一系列的日志，这些日志的扩展名为LOG，前缀一般是E00、E01……除了这些连续的日志文件外，还有一些特殊的日志文件（res1.log,res2.log,e0x.chk））），它们又有什么用呢？我们的管理员通常不喜欢备份这一操作，因此对这些日志是痛恨不已啊。那么微软在EXCHANGE数据库系统中引入日志的作用难道真的是多此一举吗？我们从以下几个方面来考察一下日志的作用：
1、作为一个企业级的邮件系统，必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难，把数据损失降低到最小。
2、必须提供高性能的邮件处理能力，对数据库中的邮件的事务操作在完成后必须马上（或是说立即）被记录在存储介质上（见前面的事务持久性说明）
3、灾难发生后，使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态（这是至关重要的！！）
现在我们来更进一步的看一下，当用户要修改邮箱中的内容时，被修改的内容首先被提取出来放到内存中，实际的修改是发生在内存里的，这是众所周知的，当修改完成后，这些内容必须被尽快写回存储介质，这样才表示一个事务成功完成了。
从事务的描述中我们可以看到，事务是具有原子特性的，为了保证数据库的一致和完整，事务必须全部成功或全部失败，如果事务失败，则必须回滚到事务开始的状态。而当邮件在内存中修改完成后，此时事务并没有完成（为什么呢？）因为一旦系统崩溃，这些修改就丢失了。所以要确保事务修改完成，必须尽快将修改写回到数据库里去（也就是硬盘上）。这也是事务的持久性要求。注意，我们这里说的第一时间或是尽快，是一个什么样的概念。如果我们直接修改EDB文件，由于EDB
文件比较大，那么在硬盘上修改一个大文件，就 需要花费大量的时间在等待和寻找数据存储块上（见操作系统原理），当系统出现高负载的繁忙状态时，这将是一个非常大的瓶颈。也就无法做到“尽快”了。那怎么办呢？所以数据库系统使用了日志，而日志通常很小（EXCHANGE的日志只有5MB），向这些文件写入修改结果是很快速的，因此当内存的修改完成后，这些结果就会立即写入日志中，以保证了事务的持久性。当成功写入日志后，该事务就成功完成了（现在在硬盘上了，不会因为当机丢失了）接下来，ESE引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去（这对用户来说已经不是那么重要了），这就是日志的第一个作用：确保事务在第一时间（尽可能快的）保存到非易失存储器上（提供了事务持久性支持）。
根据上面的藐视，我们看到运行中的EXCHANGE数据库，是由三个部分组成的：
* 内存中已经完成处理还没有写会到日志里的内容（Dirt page）
* 还没有写到数据库文件里的日志内容
* EDB和STM数据库文件
对于第一个部分，一旦掉电就回丢失的，是最不安全的。而对于第二部分的内容，系统通过检查点文件（CHK）来标记哪些日志已经被写入数据库了，而哪些还没有。CHK文件类似一个指针。我们可以用“ESEUTIL /MK”来检查CHK文件里的内容，在该命令的输出中的checkpoint:<0x8,26d1,29>这样的东西就是检查点位置，它表示E0x00008的日志的页面序号已经被成功写入数据库了。大家可以自己看看。。：）
前面提到过，EXCHANGE系统在出现灾难时，应能恢复到灾难发生前的时刻的状态。这是非常重要的。但即使是最勤快的管理员，也只能在指定的预定时间内做系统备份，而不可能时时刻刻的都在备份。那么在备份完成后到灾难发生之前的这段数据该如何保护呢？是不是就任由它丢失呢？显然是不可能的。那答案是什么呢？就是日志文件。前面我们知道，任何对数据库的更改都先写入日志里，再由日志写入数据库，这样我们只要找到日志文件，就可以重新进行模拟的操作来完成备份后的数据库文件的更改了，我们举个例子来看看：
假设我们在凌晨3点完成了一次FULLBACKUP，备份完成后，系统正常运行，到下午4点的时候，系统突然崩溃。管理员用凌晨3点的数据恢复了数据库，那么从凌晨3点到下午4点这段时间的数据变更，就只能依赖于日志了。当完成数据库恢复后，系统会自动的跟踪到关联的日志文件，如果发现有比当前数据库还新的日志存在，系统就会自动的按照日志的顺序将更改写回到数据库中去。因此这样一来，从凌晨3点到下午4点的数据变更就被完整的恢复了。这就是日志的第二个作用：保证系统备份和恢复的完整性。当然前提是没有使用循环日志！！（看到了吧，使用循环日志的危害是相当大的，比起你的数据来说，多做几次备份不是没有意义的吧？
说到这里，有人可能要问，如果数据库和日志同时损坏，如何办？答案是：尽量避免这样的情况发生。首先数据库损坏的几率要大于日志，另外，微软建议将数据库和日志分别存储在不同的磁盘上，要是这样还会同时坏，那就没有办法了，呵呵。。对于管理员对日志文件的抱怨，合理的解决方法是定期做备份。启用循环日志是不正确的做法，当启用循环日志后，一旦系统发生灾难恢复，将有可能不能将系统恢复到灾难发生时的状态，磁盘和数据谁更重要，管理员自己要考虑考虑了。
五、ESE与IS服务的启动和关闭
ESE引擎在加载数据库文件时，会去检查数据库文件的标志。这个标志保留了上次关闭数据库的状态，当状态为正常关闭说，系统将直接加载该数据库，当数据库标志为非正常关闭时，系统将先进行一个软恢复过程（你可以在事件里看到它），然后再加载。
那么，正常关闭和非正常关闭有什么区别呢？一个正常关闭的数据库，表示所有的日志信息都已经正确的写入数据库了。反之一个非正常关闭的数据库，则表示至少有一部分数据未能正确的从日志写入数据库。要注意的是，非正常关闭的数据库并不等于已经被破坏的数据库。只表示有数据没有提交到数据库文件。
使用ESEUTIL/MH命令可以看到数据库的该状态，其中的STATE字段标记的就是这个状态，“CLEANSHUTDOWN”表示数据库正常关闭。当系统加载处于非正常关闭的数据库时，就会根据检查点文件确定日志文件的位置，并做重放操作。当检查点文件丢失或损坏时，系统将从最早的日志文件开始处理。有的时候，系统不能自动的修复数据库，这时我们也可以用“ESEUTIL /R”命令手工的恢复处于非正常关闭状态的数据库。强烈推荐在系统异常关闭后执行此命令。在执行前最好前确定数据库文件的状态确实为非正常关闭，不要对正常关闭的数据库执行该恢复命令！
由此可见，EXCHANGE系统对数据库有自我修复能力，能确保系统在发生意外后恢复正确的状态。但这并不是说我们可以随意的关闭系统，仍要UPS等必要的保护措施。
六、关于M盘
在EX2000里，有一个M盘的映射。这个映射只是提供开发人员通过API访问邮箱和邮件用的。因此对M盘的手工操作都可能带来数据库的破坏，请注意，另外，有一种观点认为备份了M盘就备份了邮件，这是绝对错误的。M盘虽然是数据库的映射，但已经去掉了很多的关联和内在联系。因此备份M盘是不能恢复数据库的。所有的EXCHANGE管理员必须按规定认真的备份系统状态和SG。切不可偷懒哦。
7. mysql 核心内容-上
1、SQL语句执行流程
MySQL大体上可分为Server层和存储引擎层两部分。
Server层：
连接器：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。
查询缓存：查询后的结果存储位置，MySQL8.0版本以后已经取消，因为查询缓存失效太频繁，得不偿失。
分析器：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。
优化器：多种执行策略可实现目标，系统自动选择最优进行执行。
执行器：判断是否有权限，将最终任务提交到存储引擎。
存储引擎层
负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎(经常用的也是这个)。
SQL执行顺序
2、BinLog、RedoLog、UndoLog
BinLog
BinLog是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。
STATEMENT 模式
内容：binlog 记录可能引起数据变更的 sql 语句
优势：该模式下，因为没有记录实际的数据，所以日志量很少 IO 都消耗很低，性能是最优的
劣势：但有些操作并不是确定的，比如 uuid() 函数会随机产生唯一标识，当依赖 binlog 回放时，该操作生成的数据与原数据必然是不同的，此时可能造成无法预料的后果。
ROW 模式
内容：在该模式下，binlog 会记录每次操作的源数据与修改后的目标数据，StreamSets就要求该模式。
优势：可以绝对精准的还原，从而保证了数据的安全与可靠，并且复制和数据恢复过程可以是并发进行的
劣势：缺点在于 binlog 体积会非常大，同时，对于修改记录多、字段长度大的操作来说，记录时性能消耗会很严重。阅读的时候也需要特殊指令来进行读取数据。
MIXED 模式
内容：是对上述STATEMENT 跟 ROW 两种模式的混合使用。
细节：对于绝大部分操作，都是使用 STATEMENT 来进行 binlog 没有记录，只有以下操作使用 ROW 来实现：表的存储引擎为 NDB，使用了uuid() 等不确定函数，使用了 insert delay 语句，使用了临时表
主从同步流程：
1、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。
2、从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件 。
3、主节点启动一个线程（mp Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。
4、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个）。
5、从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。
mysql默认的复制方式是异步的，并且复制的时候是有并行复制能力的。主库把日志发送给从库后不管了，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。
全同步复制
主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。
半同步复制
半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。
还可以延伸到由于主从配置不一样、主库大事务、从库压力过大、网络震荡等造成主备延迟，如何避免这个问题？主备切换的时候用可靠性优先原则还是可用性优先原则？如何判断主库Crash了？互为主备的情况下如何避免主备循环复制？被删库跑路了如何正确恢复？( o )… 感觉越来越扯到DBA的活儿上去了。
RedoLog
可以先通过下面demo理解：
饭点记账可以把账单写在账本上也可以写在粉板上。有人赊账或者还账的话，一般有两种做法：
1、直接把账本翻出来，把这次赊的账加上去或者扣除掉。
2、先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。
生意忙时选后者，因为前者太麻烦了。得在密密麻麻的记录中找到这个人的赊账总额信息，找到之后再拿出算盘计算，最后再将结果写回到账本上。
同样在MySQL中如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。而粉板和账本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术，它的关键点就是先写日志，再写磁盘。此时账本 = BinLog，粉板 = RedoLog。
1、 记录更新时，InnoDB引擎就会先把记录写到RedoLog（粉板）里面，并更新内存。同时，InnoDB引擎会在空闲时将这个操作记录更新到磁盘里面。
2、 如果更新太多RedoLog处理不了的时候，需先将RedoLog部分数据写到磁盘，然后擦除RedoLog部分数据。RedoLog类似转盘。
RedoLog有write pos 跟checkpoint
write pos ：是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。
check point：是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos和check point之间的是粉板上还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。
有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。 redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大致如下：
1 prepare阶段 --> 2 写binlog --> 3 commit
当在2之前崩溃时，重启恢复后发现没有commit，回滚。备份恢复：没有binlog 。一致
当在3之前崩溃时，重启恢复发现虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog. 一致
binlog跟redolog区别：
redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。
redo log是物理日志，记录的是在某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=2这一行的c字段加1。
redo log是循环写的，空间固定会用完；binlog是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
UndoLog
UndoLog 一般是逻辑日志，主要分为两种：
insert undo log
代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
update undo log
事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除
3、MySQL中的索引
索引的常见模型有哈希表、有序数组和搜索树。
哈希表：一种以KV存储数据的结构，只适合等值查询，不适合范围查询。
有序数组：只适用于静态存储引擎，涉及到插入的时候比较麻烦。可以参考Java中的ArrayList。
搜索树：按照数据结构中的二叉树来存储数据，不过此时是N叉树(B+树)。广泛应用在存储引擎层中。
B+树比B树优势在于：
B+ 树非叶子节点存储的只是索引，可以存储的更多。B+树比B树更加矮胖，IO次数更少。
B+ 树叶子节点前后管理，更加方便范围查询。同时结果都在叶子节点，查询效率稳定。
B+树中更有利于对数据扫描，可以避免B树的回溯扫描。
索引的优点：
1、唯一索引可以保证每一行数据的唯一性
2、提高查询速度
3、加速表与表的连接
4、显着的减少查询中分组和排序的时间
5、通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
索引的缺点：
1、创建跟维护都需要耗时
2、创建索引时，需要对表加锁，在锁表的同时，可能会影响到其他的数据操作
3、 索引需要磁盘的空间进行存储，磁盘占用也很快。
4、当对表中的数据进行CRUD的时，也会触发索引的维护，而维护索引需要时间，可能会降低数据操作性能
索引设计的原则不应该：
1、索引不是越多越好。索引太多，维护索引需要时间跟空间。
2、 频繁更新的数据，不宜建索引。
3、数据量小的表没必要建立索引。
应该：
1、重复率小的列建议生成索引。因为重复数据少，索引树查询更有效率，等价基数越大越好。
2、数据具有唯一性，建议生成唯一性索引。在数据库的层面，保证数据正确性
3、频繁group by、order by的列建议生成索引。可以大幅提高分组和排序效率
4、经常用于查询条件的字段建议生成索引。通过索引查询，速度更快
索引失效的场景
1、模糊搜索：左模糊或全模糊都会导致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。
2、隐式类型转换：比如select * from t where name = xxx , name是字符串类型，但是没有加引号，所以是由MySQL隐式转换的，所以会让索引失效 3、当语句中带有or的时候：比如select * from t where name=‘sw’ or age=14
4、不符合联合索引的最左前缀匹配：(A,B,C)的联合索引，你只where了C或B或只有B,C
关于索引的知识点：
主键索引：主键索引的叶子节点存的是整行数据信息。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。主键自增是无法保证完全自增的哦，遇到唯一键冲突、事务回滚等都可能导致不连续。
唯一索引：以唯一列生成的索引，该列不允许有重复值，但允许有空值(NULL)
普通索引跟唯一索引查询性能：InnoDB的数据是按数据页为单位来读写的，默认每页16KB，因此这两种索引查询数据性能差别微乎其微。
change buffer：普通索引用在更新过程的加速，更新的字段如果在缓存中，如果是普通索引则直接更新即可。如果是唯一索引需要将所有数据读入内存来确保不违背唯一性，所以尽量用普通索引。
非主键索引：非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）
回表：先通过数据库索引扫描出数据所在的行，再通过行主键id取出索引中未提供的数据，即基于非主键索引的查询需要多扫描一棵索引树。
覆盖索引：如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为覆盖索引。
联合索引：相对单列索引，组合索引是用多个列组合构建的索引，一次性最多联合16个。
最左前缀原则：对多个字段同时建立的组合索引(有顺序，ABC，ACB是完全不同的两种联合索引) 以联合索引(a,b,c)为例，建立这样的索引相当于建立了索引a、ab、abc三个索引。另外组合索引实际还是一个索引，并非真的创建了多个索引，只是产生的效果等价于产生多个索引。
索引下推：MySQL 5.6引入了索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，过滤掉不符合条件的记录，减少回表字数。
索引维护：B+树为了维护索引有序性涉及到页分裂跟页合并。增删数据时需考虑页空间利用率。
自增主键：一般会建立与业务无关的自增主键，不会触发叶子节点分裂。
延迟关联：通过使用覆盖索引查询返回需要的主键，再根据主键关联原表获得需要的数据。
InnoDB存储: * .frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。*.ibd文件则是该表的索引，数据存储文件，既该表的所有索引树，所有行记录数据都存储在该文件中。
MyISAM存储：* .frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。* .MYD文件是MyISAM存储引擎表的所有行数据的文件。* .MYI文件存放的是MyISAM存储引擎表的索引相关数据的文件。MyISAM引擎下，表数据和表索引数据是分开存储的。
MyISAM查询：在MyISAM下，主键索引和辅助键索引都属于非聚簇索引。查询不管是走主键索引，还是非主键索引，在叶子结点得到的都是目的数据的地址，还需要通过该地址，才能在数据文件中找到目的数据。
PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引
4、SQL事务隔离级别
ACID的四个特性
原子性（Atomicity）：把多个操作放到一个事务中，保证这些操作要么都成功，要么都不成功
一致性（Consistency）：理解成一串对数据进行操作的程序执行下来，不会对数据产生不好的影响，比如凭空产生，或消失
隔离性（Isolation，又称独立性）：隔离性的意思就是多个事务之间互相不干扰，即使是并发事务的情况下，他们只是两个并发执行没有交集，互不影响的东西；当然实现中，也不一定需要这么完整隔离性，即不一定需要这么的互不干扰，有时候还是允许有部分干扰的。所以MySQL可以支持4种事务隔离性
持久性（Durability）：当某个操作操作完毕了，那么结果就是这样了，并且这个操作会持久化到日志记录中
PS：ACID中C与CAP定理中C的区别
ACID的C着重强调单数据库事务操作时，要保证数据的完整和正确性，数据不会凭空消失跟增加。CAP 理论中的C指的是对一个数据多个备份的读写一致性
事务操作可能会出现的数据问题
1、脏读(dirty read)：B事务更改数据还未提交，A事务已经看到并且用了。B事务如果回滚，则A事务做错了
2、 不可重复读(non-repeatable read)：不可重复读的重点是修改: 同样的条件, 你读取过的数据, 再次读取出来发现值不一样了，只需要锁住满足条件的记录
3、 幻读(phantom read)：事务A先修改了某个表的所有纪录的状态字段为已处理，未提交；事务B也在此时新增了一条未处理的记录，并提交了；事务A随后查询记录，却发现有一条记录是未处理的造成幻读现象，幻读仅专指新插入的行。幻读会造成语义上的问题跟数据一致性问题。
4、 在可重复读RR隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在当前读下才会出现。要用间隙锁解决此问题。
在说隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。SQL标准的事务隔离级别由低到高如下： 上图从上到下的模式会导致系统的并行性能依次降低，安全性依次提高。
读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。
读已提交(Oracle默认)：别人改数据的事务已经提交，我在我的事务中才能读到。
可重复读(MySQL默认)：别人改数据的事务已经提交，我在我的事务中也不去读，以此保证重复读一致性。
串行：我的事务尚未提交，别人就别想改数据。
标准跟实现：上面都是关于事务的标准，但是每一种数据库都有不同的实现，比如MySQL InnDB 默认为RR级别，但是不会出现幻读。因为当事务A更新了所有记录的某个字段，此时事务A会获得对这个表的表锁，因为事务A还没有提交，所以事务A获得的锁没有释放，此时事务B在该表插入新记录，会因为无法获得该表的锁，则导致插入操作被阻塞。只有事务A提交了事务后，释放了锁，事务B才能进行接下去的操作。所以可以说 MySQL的RR级别的隔离是已经实现解决了脏读，不可重复读和幻读的。
5、MySQL中的锁
无论是Java的并发编程还是数据库的并发操作都会涉及到锁，研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想。
悲观锁：
优点：适合在写多读少的并发环境中使用，虽然无法维持非常高的性能，但是在乐观锁无法提更好的性能前提下，可以做到数据的安全性
缺点：加锁会增加系统开销，虽然能保证数据的安全，但数据处理吞吐量低，不适合在读书写少的场合下使用
乐观锁：
优点：在读多写少的并发场景下，可以避免数据库加锁的开销，提高DAO层的响应性能，很多情况下ORM工具都有带有乐观锁的实现，所以这些方法不一定需要我们人为的去实现。
缺点：在写多读少的并发场景下，即在写操作竞争激烈的情况下，会导致CAS多次重试，冲突频率过高，导致开销比悲观锁更高。
实现：数据库层面的乐观锁其实跟CAS思想类似， 通数据版本号或者时间戳也可以实现。
数据库并发场景主要有三种：
读-读：不存在任何问题，也不需要并发控制
读-写：有隔离性问题，可能遇到脏读，幻读，不可重复读
写-写：可能存更新丢失问题，比如第一类更新丢失，第二类更新丢失
两类更新丢失问题：
第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果
为了合理贯彻落实锁的思想，MySQL中引入了杂七杂八的各种锁：
锁分类
MySQL支持三种层级的锁定，分别为
表级锁定
MySQL中锁定粒度最大的一种锁，最常使用的MYISAM与INNODB都支持表级锁定。
页级锁定
是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁，表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
行级锁定
Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大行级锁不一定比表级锁要好：锁的粒度越细，代价越高，相比表级锁在表的头部直接加锁，行级锁还要扫描找到对应的行对其上锁，这样的代价其实是比较高的，所以表锁和行锁各有所长。
MyISAM中的锁
虽然MySQL支持表，页，行三级锁定，但MyISAM存储引擎只支持表锁。所以MyISAM的加锁相对比较开销低，但数据操作的并发性能相对就不高。但如果写操作都是尾插入，那还是可以支持一定程度的读写并发
从MyISAM所支持的锁中也可以看出，MyISAM是一个支持读读并发，但不支持通用读写并发，写写并发的数据库引擎，所以它更适合用于读多写少的应用场合，一般工程中也用的较少。
InnoDB中的锁
该模式下支持的锁实在是太多了，具体如下：
共享锁和排他锁 (Shared and Exclusive Locks)
意向锁（Intention Locks）
记录锁（Record Locks）
间隙锁（Gap Locks）
临键锁 （Next-Key Locks）
插入意向锁（Insert Intention Locks）
主键自增锁 (AUTO-INC Locks)
空间索引断言锁（Predicate Locks for Spatial Indexes）
举个栗子，比如行锁里的共享锁跟排它锁：lock in share modle 共享读锁：
为了确保自己查到的数据没有被其他的事务正在修改，也就是说确保查到的数据是最新的数据，并且不允许其他人来修改数据。但是自己不一定能够修改数据，因为有可能其他的事务也对这些数据使用了 in share mode 的方式上了S 锁。如果不及时的commit 或者rollback 也可能会造成大量的事务等待。
for update排它写锁:
为了让自己查到的数据确保是最新数据，并且查到后的数据只允许自己来修改的时候，需要用到for update。相当于一个 update 语句。在业务繁忙的情况下，如果事务没有及时的commit或者rollback 可能会造成其他事务长时间的等待，从而影响数据库的并发使用效率。
Gap Lock间隙锁：
1、行锁只能锁住行，如果在记录之间的间隙插入数据就无法解决了，因此MySQL引入了间隙锁(Gap Lock)。间隙锁是左右开区间。间隙锁之间不会冲突。
2、间隙锁和行锁合称NextKeyLock，每个NextKeyLock是前开后闭区间。
间隙锁加锁原则(学完忘那种)：
1、加锁的基本单位是 NextKeyLock，是前开后闭区间。
2、查找过程中访问到的对象才会加锁。
3、索引上的等值查询，给唯一索引加锁的时候，NextKeyLock退化为行锁。
4、索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，NextKeyLock退化为间隙锁。
5、唯一索引上的范围查询会访问到不满足条件的第一个值为止。