InnoDB引擎

于 2024-07-28 20:29:14 发布
阅读量734 收藏 5
点赞数 27
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_53946852/article/details/140755788
版权

文章目录

InnoDB存储引擎

MySQL5.5 版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，在日常开发中使用非常广泛。下面是MySQL8.0的InnoDB架构图，左侧为内存结构，右侧为磁盘结构

在这里插入图片描述

1. 内存结构

在这里插入图片描述

在左侧的内存结构中，主要 分为这么四大块：Buffer Pool、Change Buffer、Adaptive
Hash Index、Log Buffer

  1. Buffer Pool

    • InnoDB存储引擎基于磁盘文件存储，访问物理硬盘和内存中进行访问，速度相差很大，为了尽可能弥补两者之间的I/O的差距，就需要把一些经常使用的数据加载到缓冲池中，避免每次访问都进行磁盘I/O
    • 在InnoDB的缓冲池中不仅缓存了索引页和数据页，还包含undo页、插入缓存、自适应哈希索引以及InnoDB的锁信息等
    • 缓冲池 Buffer Pool，是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池没有数据，则从磁盘加载并缓存），然后再以一定频率刷新到磁盘，从而减少磁盘IO，加快处理速度
    • 缓冲池以Page页为单位，底层采用链表数据结构管理Page。根据状态，将Page分为三种类型：
      • free page：空闲page，未被使用
      • clean page：被使用page，数据没有被修改过
      • dirty page：脏页，被使用page，数据被修改过，也中数据与磁盘的数据产生了不一致

  2. Change Buffer

    • Change Buffer，更改缓冲区（针对于非唯一二级索引页，也就说是针对非唯一索引生效），在执行INSERT、UPDATE、DELETE语句时，如果这些数据Page没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区 Change Buffer中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。
    • 与聚集索引不同，二级索引通常是非唯一的，并且相对随机的顺序插入二级索引，同样，删除和更新可能会影响索引树中不相邻的二级索引页，如果每一次都操作磁盘，会造成大量的磁盘IO。有了ChangeBuffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO。

  3. Adaptive Hash Index

    • 自适应hash索引，用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持hash索引，但是给我们提供了一个功能就是这个自适应hash索引。因为前面我们讲到过，hash索引在进行等值匹配时，一般性能是要高于B+树的，因为hash索引一般只需要一次IO即可，而B+树，可能需要几次匹配，所以hash索引的效率要高，但是hash索引又不适合做范围查询、模糊匹配等。
    • InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在特定的条件下hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。
    • **自适应哈希索引，无需人工干预，是系统根据情况自动完成 **
    • 参数：adaptive_hash_index

  4. Log Buffer

    • 日志缓冲区，用来保存要写入到磁盘中的log日志数据（redo log 、undo log）
    • 默认大小为 16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘 I/O
    • 参数
      • innodb_log_buffer_size：缓冲区大小
      • innodb_flush_log_at_trx_commit：日志刷新到磁盘时机，取值主要包含以下三个
        • 1: 日志在每次事务提交时写入并刷新到磁盘，默认值。
        • 0: 每秒将日志写入并刷新到磁盘一次
        • 2: 日志在每次事务提交后写入，并每秒刷新到磁盘一次

2. 磁盘结构

在这里插入图片描述

  1. System Tablespace

    • 系统表空间是更改缓冲区的存储区域。如果表是在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)
    • 在MySQL通过show variables like 'innodb_data_file_path'; ，命令可以查看对于的系统表空间信息

  2. File-Per-Table Tablespaces

    • 如果开启了innodb_file_per_table开关 ，则每个表的文件表空间包含单个InnoDB表的数据和索
      引 ，并存储在文件系统上的单个数据文件中，也就是说每一张表都会生成一个表空间文件
    • 如果没有开启则会将表空间文件存放在系统表空间文件中也就是System Tablespace
    • 开关参数：innodb_file_per_table ，该参数默认开启
    • 那也就是说，我们每创建一个表，都会产生一个表空间文件

  3. General Tablespaces

    • 通用表空间，需要通过 CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空
      间

      -- CREATE TABLESPACE 表空间名 ADD DATAFILE '表空间关联文件名' ENGINE = 存储引擎;
CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;

  4. Undo Tablespaces

    • 撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储
      undo log日志

  5. Temporary Tablespaces

    • InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据

  6. Doublewrite Buffer Files

    • 双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件
      中，便于系统异常时恢复数据

  7. Redo Log

    • 重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo logbuffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。当事务提交之后会把所
      有修改信息都会存到该日志中, 用于在刷新脏页到磁盘时,发生错误时, 进行数据恢复使用

3. 后台线程

在InnoDB的后台线程中，分为4类，分别是：Master Thread 、IO Thread、Purge Thread、
Page Cleaner Thread。

  1. Master Thread

    • 核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性，还包括脏页的刷新、合并插入缓存、undo页的回收 。

  2. IO Thread

    • 在InnoDB存储引擎中大量使用了异步IO来处理IO请求, 这样可以极大地提高数据库的性能，而IOThread主要负责这些IO请求的回调

      线程类型默认个数职责
      Read thread4负责读操作
      Write thread4负责写操作
      Log thread1负责将日志缓冲区刷新到磁盘
      Insert buffer thread1负责将写缓冲区内容刷新到磁盘

      可以通过下面这条命令，查看InnoDB的状态信息，其中就有IO的信息

      show engine innodb status \G;

  3. Purge Thread

    • 主要用于回收事务已经提交了的undo log，在事务提交之后，undo log可能不用了，就用它来回收

  4. Page Cleaner Thread

    • 协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻 Master Thread 的工作压力，减少阻塞

4. 事务原理

事务原理其实关注的就是InnoDB引擎是如何保证事务的四大特性的。

  • 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
  • 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。
  • 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
  • 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的

对于事务的四大特性实际上可以分为两个部分，其中的原子性、一致性、持久化，实际上是由InnoDB中的两份日志来保证的，一份是redo log日志，一份是undo log日志。 而持久性是通过数据库的锁，加上MVCC来保证的。

redoLog

redoLog(重做日志)，记录的是事务提交时数据页的物理修改，用来实现事务的持久性。

该日志文件由两部分组成：重做日志缓冲(redo log buffer)以及重做日志文件(redo log file)，前这是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中，用于刷新脏页到磁盘，发生错误时，进行数据恢复时使用。

在这里插入图片描述

  • 客户端发起多条update、delete语句执行事务操作
  • 在一个事务中执行多个增删改查操作的时候InnoDB会先操作缓冲池（BufferPool）的数据
  • 如果缓冲池中没有要操作的数据，会通过后台线程将磁盘中的数据加载到缓冲池中
  • 然后对缓冲池中的数据进行修改，修改后的数据被称为脏页，因为该数据和磁盘中的数据不一致
  • 在内存结构中还有一个RedologBuffer日志缓冲区，会先将操作的数据页的变化记录在RedologBuffer中
  • 这个内存中的RedologBuffer缓冲区为记录数据页的变化，在事务提交的时候，会将数据页变化的日志永久记录到磁盘的日志文件中
  • 后续将BufferPool的脏页刷新到磁盘中的时候，如果出现异常刷新失败，就可以通过redoLog重做日志进行数据恢复，保证事务的持久性
  • 而如果脏页成功刷新到磁盘 或 或者涉及到的数据已经落盘，此时redolog就没有作用了，就可以删除了，所以存在的两个redolog文件是循环写的

那为什么每一次提交事务，要刷新redo log 到磁盘中呢，而不是直接将buffer pool中的脏页刷新
到磁盘呢 ?
因为在业务操作中，我们操作数据一般都是随机读写磁盘的，而不是顺序读写磁盘。 而redo log在往磁盘文件中写入数据，由于是日志文件，所以都是进行追加内容，也就是顺序写的。顺序写的效率，要远大于随机写。 这种先写日志的方式，称之为 WAL

undoLog

undoLog（回滚日志），用于记录数据被修改前的信息 , 作用包含两个 :

  • 提供回滚(保证事务的原子性)
  • MVCC(多版本并发控制)

undoLog和redoLog记录物理日志不一样，它是逻辑日志。

  • redoLog记录的是物理日志，可以理解为记录了该条命令里面的数据是什么样子的
  • undoLog则可以理解为它记录了的是一条SQL

当delete一条记录时:，undoLog中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

  • undoLog销毁：undoLog在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些
    日志可能还用于MVCC。
  • undoLog存储：undoLog采用段的方式进行管理和记录，存放在前面介绍的 rollback segment
    回滚段中，内部包含1024个undoLog segment

5. MVCC

MVCC全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

  1. 当前读

    • 读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select … lock in share mode(共享锁)，select …
      for update、update、insert、delete(排他锁)都是一种当前读。
    • MySQL的默认隔离级别是读可重复读，一个事务是读取不到另外一个事务的修改的，也就是读取不到当前的最新版本的数据，但如果在查询语句后面上加上lock in share mode 共享锁，此时就变成了当前读操作，当然，当我们加排他锁的时候，也是当前读操作 。

    在这里插入图片描述

  2. 快照读

    • 普通的select(不加锁)就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
    • 读以提交隔离级别：开启事务后每次select操作，都会生成一个快照
    • 可重复读隔离级别(默认隔离级别)：开启事务后的第一个select操作才是生成快照的地方，后续的select读取的都是第一次select生成的快照数据
    • 行化隔离级别：快照读会退化成当前读，每次读取操作都会加锁

隐藏字段

当我们在MySQL中创建了一张数据表，会包含三个隐藏字段。

隐藏字段含义
DB_TRX_ID最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID
DB_ROLL_PTR回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本
DB_ROW_ID隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段

而上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB_ROW_ID，得看当前表有没有主键，如果没有主键，或这没有合适的唯一索引，如果有，则不会添加该隐藏字段

undoLog版本链

回滚日志，是在执行insert、update、delete的时候产生，便于数据回滚的日志。

当执行insert的时候，产生的undoLog日志只在回滚时需要，在事务提交后，可被立即删除。

而update、delete的时候，产生的undoLog日志不仅在回滚时需要，在快照读也需要，所以不会被立即删除。

假设一张表的原始数据如下：

idnameageDB_TRX_IDDB_ROLL_PTR
1lisi281null
  • DB_TRX_ID : 代表最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID，是
    自增的。
  • DB_ROLL_PTR ： 由于这条数据是才插入的，没有被更新过，所以该字段值为null。

undoLog版本链指的是一个条记录被多个事务修后，都会记录修改前的记录，使用一个链表来进行维护

  • 链表头记录的是最新一次修改前的记录
  • 而链表的尾节点记录的是第一个事务修该前的旧记录
  • 如下图的0x111就是事务最新一次修改前的记录

在这里插入图片描述

那么问题来了，在我们进行查询该条数据的时候，到底该返回哪一个版本的数据呢？

这并不是undoLog版本链所决定的，而是MVCC 中的readview所决定的。

readview

ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。

ReadView中包含了四个核心字段：

  • m_ids ：当前活跃的事务ID集合
  • min_trx_id ：最小活跃事务ID
  • max_trx_id ：预分配事务ID，当前最大事务ID+1（因为事务ID是自增的）
  • creator_trx_id ：ReadView创建者的事务ID

前面说了readview中就规定了版本链数据的访问规则：

trx_id 代表当前undolog版本链对应事务ID。

条件是否可以访问说明
trx_id ==creator_trx_id可以访问该版本成立，说明数据是当前这个事务更改的
trx_id < min_trx_id可以访问该版本成立，说明数据已经提交了。
trx_id > max_trx_id不可以访问该版本成立，说明该事务是在ReadView生成后才开启
min_trx_id <= trx_id<= max_trx_id如果trx_id不在m_ids中，是可以访问该版本的成立，说明数据已经提交。

不同的隔离级别，生成ReadView的时机不同：

  • 读已提交：在事务中每一次执行快照读时生成ReadView。
  • 可重复读：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。
读以提交

在读以提交的隔离级别下，在事务中每一次执行快照读时生成ReadView

假设一下操作都是对id为1的用户进行操作

在这里插入图片描述

  • 在事务5中，进行两次查询操作，由于隔离级别是读已提交，所以每一次进行快照读都会生成一个ReadView，那么两次生成的ReadView如下

    • 事务4的第一次查询操作，对应的事务id如下

      • m_ids: [ 3 , 4 , 5 ] [3,4,5] [3,4,5]
      • min_trx_id： 3 3 3
      • max_trx_id： 6 6 6
      • creator_trx_id： 5 5 5

      事务5的第一次读取过程如下，结合下面的版本链图片理解：

      • 从undoLog版本链的头节点j记录开始访问判断

      • trx_id ：当前链表节点的事务id，creator_trx_id：当前访问该节点的事务id

      • trx_id ==creator_trx_id：头节点记录事务id是4，和当前访问id5不相等，不符合要求继续下一条判断条件

      • trx_id < min_trx_id：当前访问id大于最小事务id，不符合条件

      • trx_id > max_trx_id：5不大于6，也不符合

      • min_trx_id <= trx_id<= max_trx_id，并且trx_id不在m_ids中，是可以访问该版本的：虽然5在指定范围内，但是因为5处于m_ids中所以无法访问。

      • 所以说明头结点也就是第一条记录无法访问，需要继续判断下一个节点

      • 事务5的第一次访问，查询到的数据是事务id(DB_TRX_ID)为2的数据，因为其符合对应要求

在这里插入图片描述

因为在读以提交的隔离级别下，在事务中每一次执行快照读时生成ReadView ，事务5的第二次查询操作生成的readview如下

  • m_ids： [ 4 , 5 ] [4,5] [4,5]
  • min_trx_id： 4 4 4
  • max_trx_id： 6 6 6
  • creator_trx_id： 5 5 5

同样可以根据版本链的访问规则来判断，最终访问的是哪一条数据。

可重复读

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。

在这里插入图片描述

所以说在可重复读隔离级别下，事务5两次查询到的结果是一样的，因为后面的读取是复用第一执行快照读(普通select语句)时生成的读视图。

爱敲代码的三毛
关注
  • 27
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
innodb引擎redo文件维护方法
09-09
下面将详细介绍InnoDB引擎redo文件的维护方法。 1. **redo log的作用** - 数据恢复：当数据库意外关闭或系统崩溃时，InnoDB可以通过redo log中的内容回放未写入磁盘的数据，恢复到一致性的状态。 - 提高性能：...
MyISAM和InnoDB引擎优化分析
09-11
相反，InnoDB引擎提供事务处理、行级锁定和外键约束，适合需要高度一致性的应用。其优化要点包括： 1. **innodb_buffer_pool_size**: 这是InnoDB最重要的参数，用于缓存数据和索引，减少磁盘I/O。一般建议设置为...
Innodb引擎详解
weixin_65837469的博客
03-23 1061
Innodb是MySQL数据库中常用的一种存储引擎，它具有以下特点和优势：
mysql InnoDB 存储引擎
一路向前
03-28 975
MySQL提供了多个不同的存储引擎，包括处理事务安全表的引擎和处理非事务安全表的引擎。在 MySQL 中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。MySQL 5.7支持的存储引擎有： InnoDB，MyISAM，Memory,Merge，Archive，Federated，CSV，BLACKHOLE等。
innodb引擎的4大特性
959
09-24 2597
文章目录1.插入缓冲（insert buffer)2.二次写(double write)3.自适应哈希索引(ahi)4.预读(read ahead)4.1 线性预读4.2 随机预读 1.插入缓冲（insert buffer) 插入缓冲（Insert Buffer/Change Buffer）：提升插入性能，change buffering是insert buffer的加强，insert buffer只针对insert有效，change buffering对insert、delete、update(dele.
mysql查看引擎状态_Innodb引擎状态查看
weixin_42099151的博客
01-21 1391
我们的MySQL数据库内的表一般都是Innodb表类型的。mysql>showengine innodb status;(低版本用：show innodb status;)=====================================09071015:54:36 INNODB MONITOR OUTPUT===================================...
InnoDB 引擎底层事务的原理
lmj3732018的博客
05-12 9403
MySQL 中事务的原子性是通过 undo log 来实现的，事务的持久性是通过 redo log 来实现的，事务的隔离性是通过读写锁+MVCC 来实现的。事务的一致性通过原子性、隔离性、持久性来保证。也就是说 ACID 四大特 性之中，C(一致性)是目的，A(原子性)、I(隔离性)、D(持久性)是手段，是为了保 证一致性，数据库提供的手段。数据库必须要实现 AID 三大特性，才有可能实现 一致性。同时一致性也需要应用程序的支持，应用程序在事务里故意写出违反约 束的代码，一致性还是无法保证的，...
MySQL数据库InnoDB引擎下服务器断电数据恢复方法
09-10
MySQL数据库在InnoDB引擎下运行时，由于其事务处理机制和数据存储方式，当服务器意外断电时，可能会导致数据不一致或者丢失。在这种情况下，恢复数据需要特别注意，因为简单地复制数据库文件可能无法成功。以下是...
mysql5.5与mysq 5.6中禁用innodb引擎的方法
09-10
本篇文章将详细介绍在MySQL 5.5和5.6版本中如何禁用InnoDB引擎，以减少内存和硬盘资源的消耗。 InnoDB引擎是MySQL的一个核心组件，它提供了事务处理、行级锁定以及外键支持等功能，这些都是MyISAM引擎所不具备的。...
MySQL禁用InnoDB引擎的方法
09-10
MySQL的InnoDB引擎是默认支持事务处理和行级锁定的存储引擎，广泛应用于高并发、数据一致性的场景。然而，在某些特殊情况下，如系统资源有限、仅需要简单表结构或不涉及事务处理时，可能需要禁用InnoDB引擎，转而...
MYSQL
maoqiwei的博客
07-23 268
1.修改student 表中年龄(sage)字段属性，数据类型由int 改变为smallint 2.为Course表中Cno 课程号字段设置索引,并查看索引 3.为SC表建立按学号(sno)和课程号(cno)组合的升序的主键索引，索引名为SC_INDEX4.创建一视图 stu info,查询全体学生的姓名，性别，课程名，成绩5.删除所有索引
MySql 主从同步会不会影响到SQL执行速度？
weixin_44892327的博客
07-24 779
作用：负责将主库的二进制日志（binary log）数据传输到从库。工作方式：当从库连接到主库时，主库会为每个连接的从库开启一个 Binlog Dump 线程。这个线程从主库的二进制日志中读取日志记录，并将其发送给从库。Binlog Dump 线程：将二进制日志传输给从库。Binlog Dump GTID 线程（在启用 GTID 模式时）：处理 GTID 相关的复制任务。
MySQL字段设置的varchar长度小于数据长度自动截取丢弃超出的长度而不是报错？
weixin_43831997的博客
07-23 366
当MySQL数据库设置为==严格模式（STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES）==时，如果尝试插入或更新超过设定长度的数据，将会导致错误，并阻止该事务进行。在默认情况下，或者在非严格模式（NO_STRICT）下，当插入长度超出 VARCHAR 字段定义的字符串时，MySQL会自动截断超出的部分，并发出一个警告，而不是错误。
MySQL中的CREATE EVENT 语句详解
u011565038的博客
07-24 543
CREATE EVENT语句在 MySQL 中用于创建一个事件调度器（Event Scheduler）的事件。事件调度器允许你安排数据库任务（如查询、数据更新等）在将来的某个时间点自动执行，或者根据特定的时间间隔重复执行。这对于需要定期执行的任务特别有用，比如数据清理、报表生成等。
MySQL的MHA
最新发布
2402_84844434的博客
07-24 801
高可用模式下的故障切换，基于主从复制。单点故障和主从复制不能切换的问题。至少需要3台。奇数台故障切换的过程0~30秒。根据vip地址所在的主机，确定主备。主和备不是靠优先级决定的，主从复制的时候就确定了主，备是在MHA的过程中确定的。
Mysql (五)
qq_64410777的博客
07-23 536
以左边的表为基础，接收左表的所有行，以左表的记录与右表的记录进行匹配，匹配左表的所有，以及右表中符合条件的行，不符合的显示null值。表和列的别名 在实际工作中，表和列名可能很长，写起来不方便，如果需要多次声明表和列时，全部展示太复杂，设置别名使书写简化。这里只是判断，结果为空 则不执行 ，如果不为空则执行前面的 结果是7 只要不为空就是7 执行的是count(*)SELECT i.name 姓名,i.score 成绩 from info as i;
[Mysql-DML数据操作语句]
2301_78794952的博客
07-23 1042
insert into student (sid,sname,birthday,ssex,classid) values(9,'张三','2007-1-1','男',1);insert into student(sname,ssex) values('某某1','男'),('某某2','女'),('某某3','男');insert into student values(9,'张三','2007-1-1','男',1);-- 将姓名为某某的生日改为1888-1-1。
Mysql - 索引
m0_69594200的博客
07-23 958
存储引擎、SQL优化工具、SQL优化，索引的分类、语法和使用规则等【笔记】内容
深入MySQL中的IF和IFNULL函数
一起coding，一起嗨。
07-23 420
深入MySQL中的IF和IFNULL函数
数据库innodb引擎使用
05-13
InnoDB是MySQL数据库的一种存储引擎，它是一种事务安全的、支持行锁定和外键约束的存储引擎。 使用InnoDB引擎，可以实现以下优点： 1. 支持事务：InnoDB是一个支持事务的存储引擎，它支持ACID（原子性、一致性、隔离性、持久性）特性，可以确保数据的完整性和一致性。 2. 支持行锁定：InnoDB支持行级锁定，这意味着在处理高并发读写操作时，只有需要锁定的行会被锁定，其他行不受影响，这可以提高并发性能。 3. 支持外键约束：InnoDB支持外键约束，它可以确保数据的完整性和一致性，避免了数据的不一致性。 4. 支持MVCC：InnoDB支持多版本并发控制（MVCC），这意味着在处理读写操作时，不会出现读写冲突，可以提高并发性能。 5. 支持崩溃恢复：InnoDB支持崩溃恢复，可以确保数据的安全性和可靠性，即使在系统崩溃的情况下，也可以恢复数据。 综上所述，使用InnoDB引擎可以提高数据库的性能和可靠性，特别是在处理高并发读写操作和数据完整性方面。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

爱敲代码的三毛

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值