Mysql存储引擎InnoDB

最新推荐文章于 2024-06-04 11:35:45 发布

snail9515

最新推荐文章于 2024-06-04 11:35:45 发布

阅读量268

点赞数

分类专栏： Mysql 文章标签： InnDB Mysql存储引擎

本文链接：https://blog.csdn.net/Lizhi_xu/article/details/100675024

版权

Mysql 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1.Mysql的存储引擎：

InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID）,支持行锁定和外键，是Mysql默认的存储引擎。InnoDB给Mysql提供了具有提交、回滚和崩溃恢复能力的事务安全（ACID）存储引擎，InnoDB锁定在行级，并且在select语句中提供了非锁定读。

2.InnoDB关键特性：

1.插入缓冲（Insert Buffer）：

面试官，你能跟我讲下InnoDB的插入缓冲嘛：

https://baijiahao.baidu.com/s?id=1626245917992508878&wfr=spider&for=pc

对于非聚簇索引，由于索引是非连续的，每次插入的数据，可能位于不同的数据页上，那么如果每次都进行磁盘写入，由于磁盘IO的耗时，可能会极其耗费性能，所以出现Insert Bufere，每次进行数据插入的时候，不急着把数据页加载到内存，而是把它暂时放入Insert Buffer中，等待很多和现在一样的非聚簇索引插入，等Insert Buffer差不多了，再将要插入的非聚集索引合并，比如，1，99，2，98，合并之前可能要四次插入，而现在，合并后1，2可能位于一个数据页上，98，99位于一个数据页，这样就减少为2次插入，提升效率。

Insert Buffer的条件：索引必须是辅助索引，（聚集索引就没有合并的必要了）；不能是唯一索引，（因为插入缓冲的时候，mysql不会判断数据的唯一性，如果要判断唯一性，就要离散读，失去了Insert Buffer的必要性）。

2.两次写（double write）

InnoDB关键特性之Double Write:

https://baijiahao.baidu.com/s?id=1626245917992508878&wfr=spider&for=pc

使用场景：当数据库发生宕机时，可能InnoDB存储引擎正在写入某个页到表中，而这个页只写了一部分，比如16KB的数据，只写了4k，就发生宕机了，这种称为部分写失效。这种是无法通过redo log去恢复的，因为重做日志记录的是对页的修改，如果页本身已经损坏，重做日志也无能为力。

工作流程：（double write由两部分组成，一部分是位于内存中的double write buffer，分为两个缓冲区，其大小为2M，另一部分是磁盘上共享的表空间（ibdata x）中连续的128个页，即2个区（extent），大小也是2M）。当一系列机制触发数据缓冲池中的脏页刷新时，并不直接写入磁盘数据文件中，而是先拷贝至内存中的doublewrite buffer中；接着从两个写缓冲区分两次写入磁盘共享表空间中（连续存储，顺序写，性能很高），每次写1M；待第二步完成后，再将doublewrite buffer中的脏页数据写入实际的各个表空间中文件（离散写），脏页数据持久化后，即标记对应的double write的数据可覆盖。

doublewrite的崩溃恢复：如果操作系统在将页写入磁盘的过程中发生崩溃，在恢复过程中，innoDB存储引擎可以从共享表空间的doublewrite buffer中找到该页的一个最近的副本，将其复制到表空间文件，再应用redo log，完成恢复过程。

3.自适应的哈希索引（Adaptive Hash Index）

特点：通过缓冲池中的B+树页构造而成，建立速度极快；InnoDB存储引擎自动根据访问的模式和频率来为某些热点数据建立哈希索引。

4.异步IO（Asynchronous IO，AIO）

与异步IO对应的是Sync IO，即没进行一次IO操作，需要等待此次操作执行完才能继续接下来的操作。但是当用户发出的是一条索引扫描的查询时，可能扫描多个索引页，等待上一个页扫描完，在进行下一次扫描是没有必要的。AIO就是用户可以在发出一个IO请求时，立即发出另一个IO请求，当全部请求发送完，等待所有IO操作的完成，这就是AIO。AIO的另一个优势是可以进行IO Merge操作，即可以将多个IO操作合并为一个IO请求，比如用户需要访问页的（space，page_no）为(8,6),(8,7),(8,8)，每个页的大小为16KB，由于页是连续的，所以AIO会从（8，6）开始，读取48KB的页。

5.刷新邻接页（Flush Neighbor Page）

工作原理：当刷新一个脏页时，InnoDB存储引擎会检测该页所在区（extend）的所有页，如果是脏页，那么一起进行刷新。这种方式通过AIO可以将多个IO写入操作合并为一个IO操作。

3.Mysql索引使用B+树，而不是B树，二叉树，AVL树？

https://blog.csdn.net/qq_36520235/article/details/94317993

1.先从二叉树说起：

二叉树查询的时间复杂度为O(log n)，但当二叉树的子节点完全位于一侧时，即变成链表，所以无法保证所有查询均为O(log n)的时间复杂度。因此演变平衡二叉树（AVL）。

2.平衡二叉树

平衡二叉树相对于二叉树，保证了每一个节点的左右子树高度差不大于1，即查找复杂度为O(log n)，

缺点：维护平衡的成本较高，每增加或删除一个节点时，需要一次或者多次的旋转来保证二叉树的平衡；查询的效率不稳定，最差为O(log n)；如果节点个数很多的话，树的高度依然很高，查找效率还是很低。

3.B树

定义：所有的叶子节点的高度是一致的，叶子节点之间使用双向链表链接。

特点：每个节点所含数据一致的，都包含data域，即数据的对应行数据，导致查询的效率不稳定，叶子节点上的数据查询效率较低，非叶子节点较高；

4.B+树

定义：专门为磁盘或其他直接存取的辅助设备设计的数据结构，B+树种，所有的数据都会位于叶子节点上，非叶子节点只包含键值，用于比较，叶子节点同样适用双向链表链接。

优点一：B+树的所有数据节点均位于叶子节点，每次查询的时间复杂度是固定的；因为叶子节点使用双向链表链接且数据均位于叶子界定，所以也支持范围查找。

优点二：B+树的每一个非叶子节点均不含data域，只有key值，所有的data都位于叶子节点，这样可以更好的利用了局部性原理（当一个数据被使用时，其周围的数据也通常会通常会马上被使用）与磁盘预读的特性（即磁盘每次IO读取的长度不是严格按需索取，而是从该位置起，读取一定的数据长度（通常16K）放入内存）；预读的长度一般为页的整数倍，页是计算机读取存储器的逻辑快，当程序读取的也不在内存中，触发缺页异常，此时系统向磁盘发生读盘信号，磁盘会找到数据的起始位置，读取一页或几页载入内存；另外，由于B+树的非叶子节点不含data与，只含有key值，每次磁盘IO页的大小是固定的，每次读取的若干个快中包含更多的节点，相当于一次IO请求包含了更多的信息量，效率更高。

4.索引

聚集索引：按照每张表的主键构建一棵B+树，同时叶子节点上存放的即为整张表的行记录数据

辅助索引：也叫非聚集索引，和聚集索引相比，叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点的索引行还包含了一个书签（bookmark），该书签用来告诉InnoDB在哪里可以找到与索引相对应的行数据。

覆盖索引：即为从辅助索引中就可以得到查询的记录，而不需要根据聚集索引进行回表操作才能取出对应数据。

联合索引：指对表上的多个列进行索引。

1.Mysql索引原理及查询优化：

https://www.cnblogs.com/bypp/p/7755307.html

（索引可以查询字段为索引字段，根据字段值最左的若干个字符的模糊匹配）

2.索引的最左匹配原则：

当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候，b+数是按照从左到右的顺序来建立搜索树的，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了，这个是非常重要的性质，即索引的最左匹配特性。

3.前缀索引：

选择varchar类型列的部分子串作为索引字段建立索引。

4.自适应哈希索引：

InnoDB存储引擎会监控对表上二级索引的查找，如果发现某二级索引被频繁访问，二级索引成为热数据，InnoDB会为其创建哈希索引带来速度上的提升。

哈希索引有可能产生冲突；且只支持等值搜索，不支持范围查询。

InnoDB关键特性值自适应哈希索引：https://www.cnblogs.com/geaozhang/p/7252389.html

5.Index Condition Pushdown（ICP）索引下推优化

6.Cardinality:

1.不重复记录的预估值.

2.InnoDB更新cardinality的策略：

表中1/16的数据发生变化，更新cardinality;

stat_modified_counter>2000 000 000;（如果对某一行频繁进行更新操作，这是发生变化的只有这一行，则无法触发第一个条件。在InnoDB存储引擎内部有一个计数器stat_modified_counter，用来表示发生变化的次数，当stat_modified_counter>2000 000 000时，满足第二个条件，更新cardinality）

3.统计cardinality的方式：

InnoDB通过采样方式计算cardinality，InnoDB随机抽取B+树索引叶子节点（Leaf Page）的个数，记为A，和8个叶子节点，统计每个页中的不同记录的个数，记为P1,P2,P3...P8，cardinality的值为（P1+P2+P3+...+P8）*A/8。

7.锁：

1.博客：

浅谈Mysql的七种锁：https://yq.aliyun.com/articles/646976

mysql的各种锁：https://blog.csdn.net/lzxlfly/article/details/85218926

2.Mysql中的lock与latch:

两者都可以成为锁，latch一般成为闩锁（轻量级的锁），因为其要求锁定的时间非常短，若持续时间长，应用性能极差。InnoDB存储引擎中，latch可以分为mutex（互斥锁）和rwlock（读写锁），其目的用来保证并发线程操作临界资源的正确性，无死锁检测的机制；lock的对象为事务，用来锁定的是数据库中的项，如表、页、行。并且一般lock对象仅在commit或rollback后进行释放（不同的事务隔离级别释放的时间可能不同），此外，lock是有死锁检测机制的。

latch:（对象）线程；（保护）内存数据结构；（持续时间）临界资源；（模式）读写锁，互斥锁；（死锁）无死锁检测与处理机制，仅通过应用程序加锁的顺序lock leveling保证无死锁的情况发生；（存在于）每个数据结构的对象中。

lock:（对象）事务；（保护）数据库内容；（持续时间）整个事务过程；（模式）行锁，表锁，意向锁；（死锁）通过waits-for graph、time out等机制进行死锁检测与处理；（存在于）Lock Manager的哈希表中。

3.锁问题：

脏读：脏数据是指事务对缓冲池中行记录的修改，并且还没有提交。违反了隔离性。

不可重复读：指在一个事务内多次读取同一数据集合，在这个事务还没有结束时，另外一个事务也访问该统一数据集合，并做了DML操作。因此，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一致的，即不可重复读。其违反了事务的一致性的要求。（重点在于update和delete，锁行即可解决）

幻读（Phantom Problem）：指在同一个事务中，连续执行两次同样的SQL语句可能会导致不同的结果，第二次可能会返回之前不存在的行。（重点在于insert，锁表才能解决）

不可重复读和幻读的区别：

https://www.jianshu.com/p/eba56c5b2532

4.InnoDB中存储引擎中的锁：

共享锁，排它锁均为行级锁，意向锁包括意向共享锁，意向排它锁均为表级锁含义为对表上的部分行数据加锁，

兼容级别：（共享锁，排它锁，意向共享锁，意向排它锁）

5.一致性非锁定读与一致性锁定读：

一致性非锁定读（Consistent nonlocking read）,指通过行多版本控制的方法来读取当前执行时间中数据库中行的数据，该方式为InnoDB默认的读取方式；对于read commited事务隔离级别，一致性的非锁定读的是当前最新的一份快照数据，对于repeatable read事务隔离级别，一致性的非锁定读的是事务开始时的行数据版本。

一致性锁定读（select *** for update）。

6.自增长与锁：

InnoDB对每个含有自增长的表都含有一个自增长的计数器，其实现方式成为Auto-inc locking，它采用一种特殊的表锁机制，为了提高插入的性能，它不是在事务提交的时候才释放锁，而是在完成对自增长值插入的sql语句后立即释放。

在InnoDB存储引擎中，自增长值的列必须是索引，同时必须是索引的第一个列，如果不是第一个列，那么InnoDB会抛出异常，而Myisam不会。

7.外键与锁：

外键主要用于用于引入完整性的约束检查，InnoDB存储引擎中，如果没有显示的为一个外键创建索引，InnoDB会自动为其创建索引，避免表锁。

对于外键值的插入或更新，首先查询父表的记录，即select操作，但是对于父表的select操作，不是采用的一致性非锁定读，因为这样会发生数据不一致的问题，因此采用的是select ... lock in share mode方式，主动对父表加一个共享锁。

8.行锁的三种算法：

Record Lock（单个行记录上的锁）、Gap Lock（间隙锁，锁定一个范围，但不包含记录本身）、Next-Key Lock（Gap Lock + Record Lock，锁定一个范围，并且锁定记录本身）。

RR事务隔离级别下，如果辅助索引为1，3，5，8，11，那么当select ... where =8 for update，由于InnoDB对于行的查询都是采用的Next-key lock算法，锁定的不是一个值，而是一个范围，为上一范围加next-key lock，以及会对下一辅助索引键值加间隙所，所以锁定的范围是（5，11）。

InnoDB对于行的查询都是采用next-key lock的算法，锁定的不是一个值，而是一个范围，但是，当查询的索引含有唯一属性时，next-key lock会进行优化，将其降级为record lock，即只锁定记录本身，而不是范围。

8.事务的基本知识

浅入深出，Mysql中事务的实现：

https://www.cnblogs.com/davygeek/p/7995072.html

Mysql中事务的分类：

https://www.cnblogs.com/olinux/p/5181550.html

1.定义：

一个最小的不能再分的工作单元，通常对应一个完整的业务。

事务只和DML语句有关，一个完整的业务需要批量的DML（insert、update、delete）语句共同完成。

2.四大特征（ACID）：

Automicity（原子性）：一个事务中的操作要么都完成，要么全部不完成，不会结束在某个中间环节，事务在执行过程中发生错误，会被回滚到事务前的状态，就像从来没发生一样；

Consistancy（一致性）：在事务开始之前和事务结束之后，事务的完整性没有被破坏。这表示写入的的资料必须完全符合所有的预设规则，这包括资料的精确度，串联性以及后续可以自发的完成预定的工作。

Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即使系统故障也不会丢失。

3.事务的分类:

扁平事务:（Flat Transaction），要么都执行，要么都结束。扁平事务也隐式存在一个保存点，该保存点为事务开始的地方。

带有保存点的扁平事务：(Flat Transaction with savepoint)，保存点为单调递增，rollBack不会影响保存点的计数。

链事务：（Chained Transaction）在提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式的传给下一个要开始的事务，提交一个事务操作和开始下一个事务操作将合并为一个原子操作，意味着下一个事务将看到上一个事务的结果，就好像一个事务中进行的一样。链事务与带有保存点的扁平事务不同的是，带有保存点的扁平事务能回滚到任意正确的保存点，而链事务只能回滚到最近的一个保存点，对于锁的处理也不同，链事务在执行commit之后，即释放了当前所持有的锁，而带有保存点的扁平事务不影响迄今为止所持有的锁。

嵌套事务：（Nested Transaction），嵌套事务时由若干事务组成的一棵树，子树既可以是嵌套事务也可以是扁平事务；处在叶节点的事务是扁平事务，但每个事务从根到叶节点的距离可以不同；位于根节点的事务称为顶层事务，其他为子事务，事务的前驱为父事务，事务的后继称为子事务；子事务既可以提交也可以回滚。但是它的提交操作并不会马上生效，除非父事务已经提交，因此，任何子事务都是在顶层事务提交后才真正的提交；树中的任何事务回滚都会。

分布式事务：（Distributed Transaction），通常是一个分布式环境下运行的扁平事务，因此需要根据数据所在位置访问网络中的不同节点。

InnoDB存储引擎支持扁平事务，带保存点的事务，链事务，分布式事务。对应嵌套事务，InnoDB原生不支持。

4.事务的隔离级别：

Read Uncommited：一个事务可以读取另一个事务未提交的修改。会出现脏读，幻读，不可重复读问题。（使用查询语句不会加锁）

Read Commited：一个事务可以读取另一个事务已经提交的修改。避免了脏读，但仍然存在不可重复读和幻读问题。（只对记录加记录锁，而不会在记录之间加间隙所，）

Repeatable Read：同一个事务中多次读取相同的数据返回的结果是一样的，避免了脏读和不可重复读问题，但幻读依然存在。（多次读取统一范围的数据会返回第一次查询的快照），Mysql默认支持的事务隔离级别是repeatable read，但是与标准SQL不同的是，InnoDB存储引擎在Repeatable Read的事务隔离级别下，使用next-key lock锁的算法，因此避免了幻读的产生，这与其他数据库系统（如SQL Server）是不一致的，所以说，InnoDB存储引擎在Repeatable Read的事务隔离级别下，已经完全保证了事务隔离性要求，即达到了SQL标准的Serializable的隔离级别。

Serializable：事务串行执行。避免以上所有问题

9.事务的实现方式：

Mysql事务的实现）——redo：

https://www.cnblogs.com/cuisi/p/6549757.html

详细分析Mysql的事务日志（redo log和undo log）：

https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html

InnoDB事务日志（undo Log 和 redo Log）详解：

https://github.com/royeo/awesome-programming-books

1.隔离性通过锁来实现；原子性和持久性通过redo log来实现；一致性通过undo log实现。

2.Redo log（重做日志）:

由易失的redo log buffer（重做日志缓冲）和持久的redo log file（重做日志文件）两部分组成，其保存的为物理日志。

InnoDB是支持事务的存储引擎，通过Flush Log at Commit机制保证事务的持久性，即当事务commit时，必须先将事务的redo log写入到redo log file中，进行持久化，待事务的commit完成才算完成。

【innodb_flush_method】参数控制InnoDB数据文件和redo log文件打开刷写模式；该参数为Null时，默认为fsync选项，redo log buffer会先写入文件系统缓存，在进行fsync()（将日志刷新到重做日志文件）操作，依赖磁盘的性能；该参数设置为O_DIRECT时，调用O_DIRECT打开数据文件，然后调用fsync()，将所有刷新到数据和log文件中，不经过操作系统，避免两次写操作。

可以通过设置非持久性来提高数据库性能；原理为事务提交时，日志不写入重做日志文件，而是等到一个周期后再执行fsync操作，不是强制每次提交都fsync，可以显著提高性能；弊端是当数据库发生宕机时，由于部分日志未刷新到磁盘，会丢失最后一段的事务；通过innodb_flush_log_at_trx_commit参数来控制重做日志刷新到磁盘的策略；默认为1，表示事务提交时都会将log buffer写入os buffer，并调用一次fsync刷新到磁盘，保证持久性；0时，在事务提交时，不会将log buffer日志写入到os buffer，即不进行重做日志的写磁盘操作，写的操作仅在master Thread完成，大概每隔1s写入os buffer，并执行一次fsync操作；2，每次提交时，重做日志文件仅写入文件系统缓存（os buffer）中，不进行fsync操作，然后每秒调用fsync()将os buffer中的日志写入到磁盘，仅数据库宕机操作系统正常，不会丢失数据；系统宕机，缓存中未刷新到重做日志文件中的那部分事务会丢失。

binlog(二进制日志)：redo log与binlog的区别：redo log是在InnoDB存储引擎产生，而binlog是在Mysql数据库的上层产生的，并且binlog不仅仅针对InnoDB存储引擎，MySQL数据库的任何存储引擎对于数据库的更该都会产生二进制日志。并且二进制日志是先于redo log记录的；日志记录的内容形式不同，二进制日志是逻辑日志，日记录的是对应的sql语句，而InnoDB的redo log记录的是物理格式的日志，即对于数据库中每个页的修改；两种日志写入磁盘的时间点不同，二进制日志只有在事务提交完成后进行一次写入，而InnoDB存储引擎的redo log是在事务进行中不断地被写入，redo log是在数据修改前写入缓存的redo log buffer中，然后再对缓存中的数据进行修改操作；

log block（日志块）：InnoDB存储引擎的redo log buffer和redo log都是以512字节的块进行存储的，即重做日志块。重做日志快的大小与磁盘扇区的大小一致，故写入是原子的，不需要double write技术。重做日志块包含12字节的头部，8字节的尾部，以及492字节的log body组成。

log group（重做日志组）:

redo log格式：

log sequence number:（lsn 日志序列号）

3.Undo log（回滚日志）：

undo log主要有提供回滚和多个版本并发控制（MVCC）两个作用，undo log保存的为逻辑日志，可以认为当delete一条记录时，undo log会记录一条对应的insert记录，当update一条记录时，undo log记录一条相反的update操作，总之，通过抵消记录来消除该语句的修改方式来做回滚处理。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容进行回滚，mvcc时，也是通过undo log来完成的，当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录之前的数据是什么，从而实现改行版本信息，让用户实现非锁定一致读。

undo log是采用（segment）段的方式来记录的，每个undo log操作在记录的时候占用一个undo log segment。另外，undo log也会产生redo log，因为undo log也需要持久化保护。

undo log的delete/update操作的内部机制：当事务提交时，innoDB不会立即删除undo log，因为后续可能还会用到，如事务的隔离级别为repeatable read，事务读取的都是开始事务时的最新提交行版本，即undo log不能删除。但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除，并且提交事务时，还会判断undo log的页是否可以重用，如果可以，将会分配给后面的事务。分析undo log的delete和update操作发现：delete操作不会直接删除，而是将该对象打上delete flag，标记为删除，最终的删除操作是通过purge线程完成的；update分为两种情况，如果update的是主键列，在undo log中直接反向记录如何update的，所以update是直接进行的，如果是非主键列，update分为两部分，先删除改行，在插入一条目标行。

4.Purge

InnoDB的delete操作，仅是将该记录delete_flag设置为1，记录并没有被删除，仍然存在与B+树中，update操作同样如此。真正完成delete和update的操作是在purge线程完成的。其目的为了满足多版本并发控制（MVCC）。

history list:按照事务提交的顺序记录undo log,将undo log进行链接，先提交的undo log总是在最后。在执行purge的过程中，InnoDB存储引擎会先在history list找到第一个需要清理的事务，清理之后在该事务所在的页中继续寻找下一个可以被清理的事务，当遇到不能清理的事务时，重新从history list剩余的事务中寻找可清理的事务，当一个页中的事务被清理完时，该undo page可以被重用。当InnoDB存储引擎的压力非常大时，并不能高效的进行purge操作时，那么history list会越来越长，全局动态参数innodb_max_purge_lag控制history list的长度，若长度大于该配置时，将延缓DML的操作，延缓时间算法

delay=((length(history_list) - innodb_max_purge_lag)*10)-5(ms)。

5.事务控制语句：

autoCommit = 0,自动提交；autoCommit = 1,手动提交，InnoDB默认为自动提交。

Start Transaction|Begin：显式开启一个事务；Commit = Commit Work，提交事务。

savepoint identifier：在事务中创建保存点；release savepoint identifier：删除一个事务的保存点，无该保存点，抛出异常

rollback：回滚；rollback to [savepoint] identifier：回滚到指定保存点

set transaction：设置事务的隔离级别

6.隐式提交的SQL语句

Mysql的部分DDL语句会产生隐式提交操作，即无法回滚。（sql server的DDL语句是可以回滚的，这与InnoDB存储引擎，Oracle这些数据库完全不同）。

（InnoDB的默认配置，sql语句是自动提交的，但当你set autocommit = 0，为手动提交，这些DDL语句依然隐式自动提交。）

7.对于事务操作的统计：

(com_commit + com_rollback) / time。

8.分布式事务（XA事务）

snail9515

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Mysql存储引擎InnoDB

1.Mysql的存储引擎：InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID）,支持行锁定和外键，是Mysql默认的存储引擎。InnoDB给Mysql提供了具有提交、回滚和崩溃恢复能力的事务安全（ACID）存储引擎，InnoDB锁定在行级，并且在select语句中提供了非锁定读。2.InnoDB关键特性：1.插入缓冲（Insert Buffer）：面试官，你能跟我讲下I...
复制链接

扫一扫

专栏目录