mysql中的事务

mysql默认采用自动提交模式，也就是说，如果不是明显地开始一个事务，每个查询都会被当做一个事务执行提交操作，在当前连接中，可以通过设置AUTOCOMMIT变量来启动或者禁用自动提交模式，1表示启动。

事务的ACID特性

事务的原子性是指事务内的语句要么全部执行，要么全部执行失败。

事务的一致性是指数据库总是从一个一致性的状态转移到另外一个一致性的状态。

事务的隔离性是指一个事务在最终提交以前，对其他的事务是不可见的。

事务的持久性是指一旦事务被提交，则其所做的修改会永久保存到数据库中

事务的隔离级别

未提交读（Read Uncommitted）

读写均不使用锁，数据的一致性最差，也会出现许多逻辑错误。在未提交读级别中，事务中的修改，没有提交，对其他事务也都是可见的，事务可以读取未提交的数据，造成脏读。

提交读（Read Committed）

使用写锁，但是读会出现不一致，造成不可重复读（两次读取不一致）。提交读是大多数数据库系统默认的隔离级别，但MySQL不是，具体是指一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。举例说明就是对于一个数A由50修改成100，另一个事务在A提交修改之前，读取到了A是50，刚读取完，A就被修改成了100，再次读取就变成100。

可重复读（Repeatable Read）

使用读锁和写锁，解决不可重复读的问题，但会有幻读，幻读是指当某个事务在读取某个范围内的记录时另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。InnoDB通过加间隙锁的方式解决了幻读的问题。间隙锁就是锁住了所有的行避免其他的事务改变A 中的变量。总结来说就是在可重复读的隔离级别下存在幻读的可能性，但是MySQL的InnoDB通过加间隙锁的方式解决了幻读。MySQL引擎的默认级别是可重复读。

可串行化（Serializable）

可串行化是最高的隔离级别，它通过强制事务串行执行，避免了前面说的幻读的问题，简单说就是可串行化会在每一行的数据上都加锁，所以可能导致大量的超时和锁争用的问题。

隔离级别 脏读可能性 不可重复读可能性 幻读可能性

未提交读 YES YES YES

提交读 NO YES YES

可重复读 NO NO YES

串行化 NO NO NO

索引

索引一般是放在磁盘中的，索引是存储引擎用于快速找到记录的一种数据结构。索引优化应该是对查询优化最有效的手段了。索引能够轻易将查询性能提高几个数量级，创建一个最优的索引经常需要重写查询。索引可以包含一个或多个列的值，如果索引包含多个列，那么列的顺序也十分重要，因为MySQL只能高效地使用索引的最左前缀。创建一个包含两个列的索引，和创建两个包含只包含一列的索引是大不相同的。

哈希索引

哈希索引基于哈希表实现，只有精确匹配索引所有列的查询才有效。对于每一行的数据，存储引擎都会对所有的索引列计算一个哈希码，哈希码是较小的值，并且不同键值的计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每一个数据行的指针。

哈希索引的限制

哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。

哈希索引数据并不是按照索引值顺序存储的，所以也叫无法用于排序。

哈希索引也不支持部分索引列匹配查找。

哈希索引只支持等值比较查询，包括=、IN()、<=>。也不支持任何范围查询。

访问哈希索引的数据非常快，除非有很多哈希冲突。当出现哈希冲突的时候，存储引擎必须遍历链表中所有的行指针，进行比较，直到找到符合条件的行。

如果哈希冲突很多的话，一些索引维护操作的代价也会很高。

几种常见的哈希函数：

CRC32()函数、SHA1()和MD5()作为哈希函数。SHA1()和MD5()这两个函数计算出来的结果是非常长的字符串，会浪费大量的空间，比较时也会更慢。SHA1()和MD5()作为强加密函数，设计目标是最大限度消除冲突。而如果使用使用CRC32()函数在数据表非常大的情况会出现大量的哈希冲突，可以考虑自己实现一个简单的64位哈希函数。这个自定义的函数要返回整数，而不是字符串。

B+Tree索引

B+Tree索引是使用B+Tree数据结构来存储数据。存储引擎以不同的方式使用B+Tree索引，性能也各有不同，各有优劣。例如，MyISAM使用前缀压缩技术使得索引更小，InnoDB则按照原数据格式进行存储。再如MyISAM索引通过数据的物理位置引用被索引的行，而InnoDB则根据主键引用被索引的行。B+Tree索引之所以能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，取而代之的是从索引的根节点开始进行搜索。根节点的槽中存放了指向子节点的指针，存储引擎根据这些指针向下层查找。叶子节点比较特别，它们的指针指向的是被索引的数据，而不是其他的节点页。B+Tree对索引列是按照顺序组织存储的，所以适合查找范围数据。例如，在一个基于文本域的索引树上，按字母顺序传递连续的值进行查找是非常合适的，所以像“找出所有以I到K开头的名字”这样的查找效率会非常。索引对多个值进行排序的依据是CREATE TABLE语句中定义索引时列的顺序。B+Tree索引适应于全键值、键值范围或键前缀查找。其中键前缀查找只适用于根据最左前缀的查找。

B+Tree索引特性：

全值匹配全值匹配指的是和索引中所有的列进行匹配

匹配最左前缀指的是和索引中第一列进行匹配

匹配列前缀指的是只匹配某一列的值的开头部分

匹配范围值指的是匹配某一列的范围

精确匹配某一列并范围匹配另外一列精确匹配是指某一列的值已知，再范围匹配另一列

只访问索引的查询B-Tree通常可以支持“只访问索引的查询”，即查询只需要访问索引，而无需访问数据行。这种又称为“覆盖索引”。

索引树中的节点是有序的，所以除了按值查找以外，所以还有可以拥有查询中ORDER BY操作。

B+Tree索引的限制：

如果不是按照索引的最左列开始查找，则无法使用索引。

不能跳过索引的列。

如果查询中有某个列的范围查询，则其右边所有列都无法使用索引优化查询。

索引的顺序非常重要，这些限制都和索引的顺序有关。在性能优化的时候，可能需要使用相同的列但顺序不同的索引来满足不同类型的查询需求。

为什么选用B+树作为索引的底层结构（B+树比B树好在哪里，比哈希好在哪里）

B+树的特性是在B树的基础上进行改造。

B+树

B树是一个多路搜索树（多路排序树），每个节点都可以拥有多（M）个孩子节点，设计成多路是为了降低树的高度，减少查询时间。索引是存放在磁盘的，内存读取磁盘中的数据，内存是个瘦子一次只能读取很少的数据，先读取B树的根节点，在接着往下读取，直到找到那个值。

B+树叶子节点存储数据且叶子节点之间还加了指针形成链表，查找与树的高度有关，哈希查找的时间为O(1)。在实际的业务场景中，一般是一次性查询多条有序数据。比如说要查询最后10条id的数据，这时B+树存储的数据都是有序的，这种情况下B+树的查询效率比哈希要快。

申明：图片取自网络，如有侵权，请联系删除。

扫一扫，关注一波~