《MySQL技术内幕》MySQL 笔记

最新推荐文章于 2024-07-25 12:56:57 发布

佛系宅女

最新推荐文章于 2024-07-25 12:56:57 发布

阅读量266

点赞数

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/y159_4/article/details/107518737

版权

来源：《MySQL技术内幕：InnoDB存储引擎》

1.存储引擎

InnoDB：行锁设计，支持外键，MVCC获得高性能，聚集索引。MySQL5.5.8之后是默认的存储引擎。InnoDB1.0x之后支持压缩页。InnoDB1.2.x版本开始，InnoDB存储引擎支持全文检索，支持MyISAM存储引擎的全部功能。
MyISAM：不支持事务、表锁设计，支持全文索引，非聚簇索引。5.5.8之前是默认的存储引擎。
NDB：集群索引存储引擎，数据全部放在内存中。
Memory：数据全部放在内存中，适合存储临时数据的临时表。

2.InnoDB存储引擎

（1）架构

架构： 后台线程–>InnoDB存储引擎内存池–>文件
后台线程作用： 刷新内存池中的数据
内存： 缓冲池（数据页（默认16kb）、索引页、锁信息、数据字典信息、自适应哈希索引）、redo日志缓冲、额外内存池。
管理内存区域： LRU，优化，新读取的页放到5/8的位置处（保证热点数据不被刷出）。
缓冲池的目的： 协调CPU速度与磁盘速度的鸿沟。

（2）InnoDB关键特性

插入缓冲：性能的提升
满足条件：索引是辅助索引，索引不是唯一的。
对于非聚集索引的插入或更新，先判断插入的非聚集索引页是否在缓冲池中，如果在则直接插入；不在，放入Insert Buffer对象里，再合并Insert Buffer和辅助索引叶子节点，将多个插入合并到一个操作里。
缺点：使用了多次Insert Buffer，MySQL宕机，恢复需要很久。
两次写：数据页的可靠性
两次写由两部分组成：内存中的doublewrite buffer（2M）和物理磁盘上共享表空间中连续的128个页（2M）。写失效时，通过页的副本来还原该页，再进行重做。
自适应哈希索引（AHI）：速度提升
通过缓冲池的B+数页构造，InnoDB存储引擎自动根据访问的频率和模式自动地为某些热点页建立哈希索引。
只能用来搜索等值的查询。
InnoDB存储引擎使用哈希算法来对字典进行查找，其冲突机制采用链表方式，哈希函数采用除法散列方式。
异步IO：提高磁盘操作性能
用户发出一个IO请求后立即发出另一个IO请求，全部IO请求发送完毕后，等待所有IO操作的完成。IOMerge操作，提高IOPS的性能。
刷新邻接页
当刷新一个脏页时，该页所在区的所有页如果是脏页一起刷新。

3.文件

参数文件:告诉MySQL实例启动时在哪里可以找到数据库文件，并且指定某些初始化参数，这些参数定义了某种内存结构的大小等设置，还会介绍各种参数的类型。
日志文件:用来记录MySQL实例对某种条件做出响应时写人的文件，如错误日志文件、二进制日志文件、慢查询日志文件、查询日志文件等。
socket文件:当用UNIX域套接字方式进行连接时需要的文件。
pid文件: MySQL 实例的进程ID文件。
MySQL表结构文件:用来存放MySQL表结构定义文件。
存储引擎文件:因为MySQL表存储引擎的关系，每个存储引擎都会有自己的文件来保存各种数据。这些存储引擎真正存储了记录和索引等数据。

（1）日志文件

错误日志：对MySQL的启动、运行、关闭过程进行了记录。记录错误信息、警告信息或正确信息。当出现MySQL数据库不能正常启动时，第一个必须查找的文件应该是错误日志文件。
慢查询日志：帮助DBA定位可能存在问题的SQL语句，进行SQL语句层面的优化。默认不启动慢查询日志，需要手动设置log_slow_queries为On。
查询日志：查询日志记录了所有对MySQL数据库请求的信息，无论这些请求是否正确执行。查看一个查询日志：tail zhujiming.log
二进制日志：记录对Mysq数据库执行更改的所有操作，作用是恢复、复制、审计是否注入攻击。使用工具mysalbinlog查看。

（2）存储引擎文件

表空间文件（存储的数据按表空间存放）、重做日志文件（日志文件组数量默认为2，ib_logfile(),ib_logfile1）。

4.表

（1）索引组织表

表根据主键顺序组织存放的。如果没有显示选择/创建主键，先判断是否有非空唯一索引，有则选择这列，没有则自动创建一个6字节大小的指针。
表中有多个非空唯一索引，选择建表时第一个定义的非空唯一索引。
查询主键（用于查看单列为主键的情况）：select a,b,c,d,_rowid from table1

（2）InnoDB逻辑存储结构

表空间由段、区、页（块）组成。
表空间：所有数据存放在表空间中。默认情况下有一个共享表空间ibdata1，存放回滚、插入换成索引页。二次写缓冲，每张表的表空间放数据、索引和插入缓冲Bitmap页。
段：数据段（B+树的叶子节点）、索引段（非叶子节点）、回滚段。
区：连续页组成的空间，大小为1MB。默认页大小为16k，一共存放连续64个页。32个碎片页存完之后再申请64个连续页。
页：默认16k，InnoDB1.2x之后可更改4k,8k,16k，设置完成不可更改。分为数据页、undo页、系统页等。是InnoDB存储引擎管理数据库的最小磁盘单位。
行：InnoDB存储引擎是面向列的，数据是按行存放的，每页最多存放7992行记录。Compact行记录和Redundant行记录。

（3）视图

视图：没有实际物理存储，基于基表的虚拟表。
作用：一定程度上起到安全层的作用。
物化视图：是根据基表实际存在的实表，物化视图的数据存储在非易失的存储设备上。物化视图可以用于预先计算并保存多表的链接(JOIN) 或聚集(GROUP BY)等耗时较多的SQL操作结果。这样，在执行复杂查询时，就可以避免进行这些耗时的操作，从而快速得到结果。物化视图的好处是对于一些复杂的统计类查询能直接查出结果。物化视图的刷新是指当基表发送dml操作后，物化视图如何和基表同步。build immediate/build deferred建立物化视图

（4）分区表

分区：MySQL数据库在5.1版本时添加了对分区的支持。分区的过程是将一个表或索引分解为多个更小、更可管理的部分。就访问数据库的应用而言，从逻辑上讲，只有一个表或一个索引，但是在物理上这个表或索引可能由数十个物理分区组成。每个分区都是独立的对象，可以独自处理，也可以作为一个更大对象的一部分进行处理。
MySQL支持水平分区，不支持垂直分区。支持局部分区（一个分区中既放数据又放索引），不支持全局分区。
数据库的应用分为两类: 一类是OLTP (在线事务处理)，如Blog、电子商务、网络游戏等;另一类是OLAP (在线分析处理)，如数据仓库、数据集市。在一个实际的应用环境中，可能既有OLTP的应用，也有OLAP的应用。对于OLAP的应用，分区的确是可以很好地提高查询的性能， 因为OLAP应用大多数查询需要频繁地扫描一张很大的表。假设有一张1亿行的表，其中有一个时间戳属性列。用户的查询需要从这张表中获取一年的数据。如果按时间戳进行分区，则只需要扫描相应的分区即可。

5. 索引

InnoDB支持常见的索引：B+树索引、全文索引、哈希索引。
InnoDB存储引擎的支持的哈希索引是自适应的，不能人为干预是否在一张表中生成哈希索引。
B+树索引并不能找到一个给定键值的具体行。B+树索引能找到的只是被查找数据行所在的页。然后数据库通过把页读入到内存，再在内存中进行查找，最后得到要查找的数据。

（1）B+树

为什么用B+树？
二分查找比普通查找要快，二叉查找树会出现左斜树的情况，最优平衡二叉树维护代价高。
B+树是平衡查找树，记录的节点按照键值的大小顺序存放在同一层的叶子节点上，各叶子节点指针进行连接。
B+树的插入操作
（1）叶子节点、索引节点都未满：直接插入；
（2）叶子节点满，索引节点未满：拆分叶子节点，中间节点放入到索引节点中，小的放在左边，大于或等于放在右边；
（3）叶子节点、索引节点都满：拆分叶子节点，大于或等于放在左边，大的放在右边；拆分索引节点，小的放在左边，大于放在右边；中间节点放入上一层索引节点中。
为了保持平衡，对于新插入的键值可能要做拆分页的操作。B+树结构用于磁盘，所以应减少拆分。因此提供了旋转功能：叶子节点满了，左右兄弟未满，将记录转移到所在页的兄弟节点上。
B+树的删除操作
使用填充因子 控制树的删除变化，最小值为50%。
（1）叶子节点、索引节点都大于等于填充因子：直接删除，如果是索引节点，用右节点代替；
（2）叶子节小于填充因子，索引节点大于等于填充因子：合并叶子节点和它的兄弟节点，同时更新Index Page；
（3）叶子节点、索引节点都小于填充因子：合并叶子节点和它的兄弟节点；更新Index Page；合并Index Page和它的兄弟节点

（2）B+树索引

特点：高扇出性，一般2-4层。
数据库中的B+树索引可以分为聚集索引(clustered inex)和辅助索引( secondary index) ，其内部都是B+树的，即高度平衡的，叶子节点存放着所有的数据。
聚集索引与辅助索引（非聚集索引）不同的是，叶子节点存放的是否是一整行的信息。

聚集索引
按照每张表的主键构建一棵B+树，非叶子节点存放键值和指向数据页的偏移量。叶子节点存放的是整张表的行记录数据，将聚集索引的叶子节点称为数据页 。数据页通过双向链表链接。每张表只能有一个聚集索引。
聚集索引的存储不是物理连续的，是逻辑上连续的。
好处：对于主键的排序查找和范围查找速度很快。
辅助索引（非聚集索引）
叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点中的索引行中还包含了一个书签(bookmark)。该书签用来告诉InnoDB存储引擎哪里可以找到与索引相对应的行数据。由于InnoDB存储引擎表是索引组织表，因此InnoDB存储引擎的辅助索引的书签就是相应行数据的聚集索引键。
B+树索引的分裂
可能不总是从页中间记录开始，可以决定是向左还是向右分裂，同时决定分裂点记录为哪一个。
B+树索引的管理
alter table ,create/drop index,show index from
#show index from table1
#show table status from db1
select _rowid from table1
快速索引创建（FIC）
5.5之前，对于索引的删加DDL操作需要创建临时表，复制原表的数据到临时表中，删除原表，重命名临时表；
对于辅助索引的创建，InnoDB存储引擎会对创建索引的表加上一个S锁，不需要重建表，会阻塞DML操作。

（3）B+树索引的应用

OLTP、OLAP中需要表连接的复杂查询
联合索引
联合索引的内部结构：B+树，键值数量大于等于2.(a,b)，select *form table where a=xx and b=xx可以用到；select *form table where b=xx，则不可以使用这棵B+树索引。（最左前缀原则）
好处：已经对第二个键值进行了排序处理。例如，查询某用户的最近三次购买记录，会用到(userid)和(userid,buy_date)索引都存在的情况下，会用联合索引，因为不需要再对buy_date做一次额外的排序操作。
覆盖索引
从辅助索引中就可以查询的记录，不需要查询聚集索引中的记录。
好处：铺助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的IO操作。
优化器选择辅助索引：辅助索引能查到就不用去找聚集索引
优化器选择(a,b)的情况：统计操作且覆盖索引，例如：select count(*) form buy_log where buy_date>=‘xx’ and buy_date <=‘xx’
优化器不使用索引
多发生于范围查找，join连接。
范围查找时，例如select * form table where xx>100 and xx<200 ，用户选取整行信息，辅助索引是离散读，没有聚集索引顺序读快。因此此时会使用聚集索引查找。

（4）全文检索

倒排索引
在辅助表(auxiliary tabie)中存储了单词与单词自身在一个或多个文档中所在位置之间的映射。这通常利用关联数组实现，其拥有两种表现形式：
inverted file index：{单词，单词所在文档ID}
full inverted index：{单词，(单词所在文档ID，在具体文档中的位置)}

6. 锁

（1）共享锁和排他锁

两种锁：
共享锁(S Lock)，允许事务读一行数据。
排他锁(X Lock)，允许事务删除或更新一行数据。
InnoDB存储引擎支持意向锁设计比较简练，其意向锁即为表级别的锁。设计目的主要是为了在一个事务中揭示下一行将被请求的锁类型。支持两种意向锁：
1)意向共享锁(IS Lock), 事务想要获得一张表中某几行的共享锁
2)意向排他锁(IX Lock),事务想要获得一张表中某几行的排他锁
由于InnoDB存储引擎支持的是行级别的锁，因此意向锁其实不会阻塞除全表扫以外的任何请求。

（2）一致性非锁定读

事务的隔离级别为REPEATABLE READ模式下，InnoDB 存储引擎的SELECT操作使用一致性非锁定读。在READ COMMITTED事务隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据。而在REPEATABLEREAD事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本。
一致性非锁定读，就是通过多版本并发控制 的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因此去等待行上锁的释放。相反地，InnoDB 存储引擎会去读取行的一个快照数据。极大地提高了数据库的并发性，在默认配置下，事务的隔离级别为REPEATABLE READ。

（3）一致性锁定读

显式地对数据库读取操作进行加锁以保证数据逻辑的一致性。
要求数据库支持加锁语句，即使是对于SELECT的只读操作。InnoDB存储引擎对于SELECT语句支持两种一-致性的锁定读(locking read)操作：
SELECT…FOR UPDATE
SELECT…LOCK IN SHARE MODE
SELECT…FOR UPDATE对读取的行记录加一个X锁，其他事务不能对已锁定的行加上任何锁。
SELECT…LOCK IN SHARE MODE对读取的行记录加一个S锁，其他事务可以向被锁定的行加S锁，但是如果加X锁，则会被阻塞。

（4）锁的算法

Record Lock：单个行记录上的锁，锁住索引记录
Gap Lock：间隙锁，锁定一个范围，但不包含记录本身
Next-Key Lock ：Gap Lock+Record Lock,锁定一个范围，并且锁定记录本身。通过使用Next-Key Lock算法来避免不可重复读的问题。 与 SQL 标准不同的地方在于InnoDB 存储引擎在 REPEATABLE-READ（可重读）事务隔离级别下，允许应用使用 Next-Key Lock 锁算法来避免幻读的产生。

（5）锁问题

脏读： 脏读指的就是在不同的事务下，当前事务可以读到另外事务未提交的数据
不可重复读： 是指在一个事务内多次读取同一数据集合。在这个事务还没有结束时，另外一个事务也访问该同一数据集合，并做了一些DML操作。因此，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的情况，这种情况称为不可重复读。
丟失更新：是一个事务的更新操作会被另一个事务的更新操作所覆盖，从而导致数据的不一致。但是，在当前数据库的任何隔离级别下，都不会导致数据库理论意义上的丢失更新问题。
幻读： 倾向于删除和增加。Phantom Problem是指在同一事务下，连续执行两次同样的SQL语句可能导致不同的结果，第二次的SQL语句可能会返回之前不存在的行。

不可重复读和脏读的区别是：脏读是读到未提交的数据，而不可重复读读到的却是已经提交的数据，但是其违反了数据库事务一致性的要求。
脏数据和脏页的区别：脏页指的是在缓冲池中已经被修改的页，但是还没有刷新到磁盘中，即数据库实例内存中的页和磁盘中的页的数据是不-致的，当然在刷新到磁盘之前，日志都已经被写人到了重做日志文件中。而所谓脏数据是指事务对缓冲池中行记录的修改，并且还没有被提交(commit)。对于脏页的读取，是非常正常的。脏页是因为数据库实例内存和磁盘的异步造成的，这并不影响数据的一致性(或者说两者最终会达到一致性，即当脏页都刷回到磁盘)。并且因为脏页的刷新是异步的，不影响数据库的可用性，因此可以带来性能的提高。脏数据却截然不同，脏数据是指未提交的数据，如果读到了脏数据，即一个事务可以读到另外一个事务中未提交的数据，则显然违反了数据库的隔离性。

死锁
解决：
1.超时回滚，缺点：根据FIFO的顺序选择回滚对象。但若超时的事务所占权重比较大，如事务操作更新了很多行，占用了较多undo log,这时采用FIFO的方式，就显得不合适了，因为回滚这个事务的时间相对另一个事务所占用的时间可能会很多。
2.等待图的方式进行死锁检测：要求数据库保存锁的信息链表和事务等待链表，图中存在回路，代表死锁发生。
锁升级
将当前锁的粒度降低。比如把一个表的1000个行锁升级为一个页锁，或者将页锁升级为表锁。

7.事务

目的：把数据库从一种一致状态转换成另一种一致状态。提交工作时，确保要么所有修改都已保存，要么所有修改都不保存。

（1）基础

事务理论上需要满足ACID的特性：
A (Atomicity)，原子性：原子性指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作都执行成功，才算整个事务成功。事务中任何一个SQL语句执行失败，已经执行成功的SQL语句也必须撒销，数据库状态应该退回到执行事务前的状态。
C(consistency)，一致性。一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
I (isolation)，隔离性。隔离性还有其他的称呼，如并发控制(concurrency control)、可串行化(serializability)、锁(locking) 等。事务的隔离性要求每个读写事务的对象对其他事务的操作对象能相互分离，即该事务提交前对其他事务都不可见，通常这使用锁来实现。
D (durability), 持久性。事务一旦提交，其结果就是永久性的。即使发生宕机等故障，数据库也能将数据恢复。需要注意的是，只能从事务本身的角度来保证结果的永久性。保证事务的高可靠性。
分类：
扁平事务： 这可能是使用最为频繁的事务。在扁平事务中，所有操作都处于同一层次，其由BEGIN WORK开始，由COMMIT WORK或ROLLBACK WORK结束，其间的操作是原子的，要么都执行，要么都回滚。因此扁平事务是应用程序成为原子操作的基本组成模块。限制是不能提交或者回滚事务的某-部分，或分几个步骤提交。
带有保存点的扁平事务：支持扁平事务支持的操作，允许事务执行过程中回滚到同一事务中较早的一个状态。限制是系统崩溃时，保存点将消失，是非持久的。
链事务：提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式地传给下一个要开始的事务。而链事务中的回滚仅限于当前事务，即只能恢复到最近一个的保存点。
嵌套事务：（InnoDB不原生支持）层次结构的框架，顶层事务控制各层事务（子事务）。适用于并行需求。可以通过带有保存点的事务来模拟串行的嵌套事务。
分布式事务： 分布式环境下运行的扁平事务，需要根据数据所在的位置访问网络中的不同节点。

（2）事务的实现

redo log称为重做日志，用来保证事务的原子性和持久性。undo log用来保证事务的一致性。redo和undo的作用都可以视为是一种恢复操作。redo恢复提交事务修改的页操作，而undo回滚行记录到某个特定版本。因此两者记录的内容不同，redo 通常是物理日志，记录的是页的物理修改操作。undo 是逻辑日志，根据每行记录进行记录。

redo
重做日志记录了事务的行为，用来实现事务的持久性，即事务ACID中的D。
其由两部分组成: 一是内存中的重做日志缓冲(redo log buffer),其是易失的;二是重做日志文件( redo log file),其是持久的。
InnoDB是事务的存储引擎，其通过Force Logat Commit机制实现事务的持久性，即当事务提交(COMMIT)时，必须先将该事务的所有日志写入到重做日志文件进行持久化， 待事务的COMMIT操作完成才算完成。这里的日志是指重做日志，在InnoDB存储引擎中，由两部分组成，即redo log和undo log。redo log用来保证事务的持久性，undo log用来帮助事务回滚及MVCC的功能。redo log基本上都是顺序写的, 在数据库运行时不需要对redo log的文件进行读取操作。而undo log 是需要进行随机读写的。
InnoDB存储引擎在启动时不管上次数据库运行时是否正常关闭，都会尝试进行恢复操作。
fsync操作，重做日志缓冲先写入文件系统缓存，确保日志写入磁盘的操作，效率取决于磁盘的性能。
undo
（1）事务需要进行回滚操作，这时就需要undo。如果用户执行的事务或语句由于某种原因失败了，又或者用户用一条ROLLBACK语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。
redo存放在重做日志文件中，与redo不同，undo存放在数据库内部的一个特殊段(segment)中，这个段称为undo段(undo segment)。undo 段位于共享表空间内。
用户通常对undo有这样的误解：undo用于将数据库物理地恢复到执行语句或事务之前的样子，但事实并非如此。undo 是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。
（2）undo 的另一个作用是MVCC,即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。最后也是最为重要的一点是，undo log会产生redo log,也就是undo log的产生会伴随着redo log的产生，这是因为undo log也需要持久性的保护。
purge
delete操作并不直接删除记录，而只是将记录标记为已删除，也就是将记录的delete flag设置为1，而记录最终的删除是在purge操作中完成的。
purge用于最终完成delete和update操作。 这样设计是因为InnoDB存储引擎支持MVCC,所以记录不能在事务提交时立即进行处理。这时其他事物可能正在引用这行，故InnoDB存储引擎需要保存记录之前的版本。而是否可以删除该条记录通过purge来进行判断。若该行记录已不被任何其他事务引用，那么就可以进行真正的delete操作。可见，purge操作是清理之前的delete和update操作，将上述操作“最终”完成。而实际执行的操作为delete操作，清理之前行记录的版本。

（3）隔离级别

SQL标准定义的四个隔离级别为：
read uncommitted：浏览访问
read commited：游标稳定。在READ COMMITTED的事务隔离级别下，除了唯一性的约束检查及外键约束的检查需要gap lock, InnoDB 存储引擎不会使用gap lock的锁算法。在READ COMMITTED事务隔离级别下，事务没有使用gap lock进行锁定。
repearable read：通过使用Next-Key Lock算法来避免不可重复读的问题
serializable：在SERIALIABLE的事务隔离级别，InnoDB存储引擎会对每个SELECT语句后自动加上LOCK IN SHARE MODE，即为每个读取操作加一个共享锁。InnoDB 存储引擎在分布式事务的情况下一般会用到SERIALIZABLE(可串行化)隔离级别。

InnoDB存储引擎默认支持的隔离级别是REPEATABLEREAD，但是与标准SQL不同的是，InnoDB 存储引擎在REPEATABLE READ事务隔离级别下，使用Next-Key Lock锁的算法，因此避免幻读的产生。这与其他数据库系统(如Microsoft SQL Server数据库)是不同的。所以说，InnoDB 存储引擎在默认的REPEATABLE READ的事务隔离级别下已经能完全保证事务的隔离性要求，即达到SQL标准的SERIALIZABLE隔离级别。

（4）分布式事务

InnoDB存储引擎提供了对XA事务的支持，并通过XA事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源(transactional resources)参与到一个全局的事务中。
在使用分布式事务时，InnoDB 存储引擎的事务隔离级别必须设置为serializable。
XA事务由一个或多个资源管理器(Resource Managers)、一个事务管理器(Transaction Manager)以及一个应用程序(Application Program)组成。
（1）资源管理器:提供访问事务资源的方法。通常一个数据库就是一个资源管理器。
（2）事务管理器:协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信。
（3）应用程序:定义事务的边界，指定全局事务中的操作。
两阶段提交
分布式事务使用两段式提交(two-phase commit)的方式。在第一阶段，所有参与全局事务的节点都开始准备(PREPARE)，告诉事务管理器它们准备好提交了。在第二阶段，事务管理器告诉资源管理器执行ROLLBACK还是COMMIT。如果任何一个节点显示不能提交，则所有的节点都被告知需要回滚。可见与本地事务不同的是，分布式事务需要多一次的PREPARE操作，待收到所有节点的同意信息后，再进行COMMIT或是ROLLBACK操作。

（5）不好的事务习惯

在循环中提交，发生错误事，数据库会停留在一个未知的未知
使用自动提交。最好把事务的控制权限交给开发人员，即在程序端进行事务的开始和结束。
使用自动回滚，对于开发人员不知道发生了什么样的错误。

8.性能调优

选择合适的CPU：可以说OLAP是CPU密集型的操作，而OLTP是IO密集型的操作。.
内存的重要性：内存的大小是最能直接反映数据库的性能。通过之前各个章节的介绍，已经了解到InnoDB存储引擎既缓存数据，又缓存索引，并且将它们缓存于一个很大的缓冲池中，即InnoDB Buffer Pool。因此，内存的大小直接影响了数据库的性能。
硬盘对数据库性能的影响：当前大多数数据库使用的都是传统的机械硬盘。
机械硬盘有两个重要的指标: 一个是寻道时间，另一个是转速。
固态硬盘，更准确地说是基于闪存的固态硬盘，是近几年出现的一种新的存储设备，其内部由闪存(Flash Memory)组成。因为闪存的低延迟性、低功耗，以及防震性，闪存设备已在移动设备上得到了广泛的应用。
另一方面，闪存中的数据是不可以更新的，只能通过扇区(sector) 的覆盖重写，而在覆盖重写之前，需要执行非常耗时的擦除(erase) 操作。擦除操作不能在所含数据的扇区上完成，而需要在删除整个被称为擦除块的基础上完成，这个擦除块的尺寸大于扇区的大小，通常为128KB或者256KB。
合理地设置RAID：RAID (Redundant Array of Independent Disks,独立磁盘冗余数组)的基本思想就是把多个相对便宜的硬盘组合起来，成为一个磁盘数组，使性能达到甚至超过一个价格昂贵、容量巨大的硬盘。RAID的作用是：增强数据集成度、增强容错功能、增加处理量或容量。
操作系统的选择
不同文件系统对数据库的影响
选择合适的基准测试工具