MySQL数据库进阶篇三（锁、InnoDB引擎、常用工具）

已于 2024-09-28 13:30:48 修改
阅读量993 收藏 27
点赞数 29
分类专栏： SQL 文章标签： 数据库 mysql
于 2024-04-25 17:19:19 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_45606619/article/details/138183456
版权

目录

一、锁

是计算机协调多个进程或线程并发访问某一资源的机制，用于保护并发访问数据的一致性和有效性

1.1、全局锁

对整个数据库实例加锁，加锁后整个实例处于只读状态，后续DML的写语句，DDL语句，更新操作的事务提交都将被阻塞
使用场景：全库逻辑备份（将数据库中的数据备份成一个SQL文件保存在磁盘中

  • 若执行备份过程中，还有数据的修改和插入，则备份的数据无法保证数据的一致性和完整性。

    例如表订单，表库存，表订单日志，逐个备份该表的过程（备份顺序：订单->库存->日志）中依然有下单的操作，即备份了订单 但库存已经减少等操作 会导致数据库的数据不一致

  • 加锁后，DML和DDL无法操作，DQL查询数据　依然可以使用

flush tables with read lock ; # 加全局锁
sudo mysqldump -h 127.0.0.1 -uroot -p123456 -d db01 > db01.sql # 数据备份 shell界面中执行
unlock tables; # 再登录到MySQL，释放锁

数据库中加全局锁，是一个比较重的操作，存在以下问题：

  • 如果在主库上备份，那么在备份期间都不能执行更新
  • 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导致主从延迟

在InnoDB引擎中，可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致性数据备份
sudo mysqldump -single-transaction -h 127.0.0.1 -uroot -p123456 -d db01 > db01.sql

1.2、表级锁

  • 表锁

    • 表共享读锁(read lock)
    • 表独占写锁(write lock)
      lock tables 表名... read/write  # 加锁
unlock tables / 客户端断开连接  # 释放锁
      在这里插入图片描述
      在这里插入图片描述

  • 元数据锁（meta data lock, MDL）

    MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上

    主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与 DDL冲突（增删改 DDL：数据库 表 表字段 ，DML：表中数据），保证读写的正确性。

    元数据就是表结构，元数据锁就是维护表结构一致性的锁

    • 当对一张表进行增删改查的时候 DML语句，加MDL读锁(共享)
    • 当对表结构进行变 更操作的时候 DDL语句，加MDL写锁(排他)

    在这里插入图片描述

查看元数据锁的加锁情况：
select object_type, object_schema, object_name,lock_type, lock_duration from performance_schema.metadata_locks ;

  • 意向锁

    若两个线程操作一张表，线程A对表加了行锁/表锁，之后 线程B要对表加表锁，线程B需要先遍历表 查看表是否已经被加行锁 或者 表锁。

    为了减少类似以上，DML执行时加的行锁与后来要加的表锁冲突的现象。InnoDB引入了意向锁，使表锁不用再检查每行是否被加锁，使用意向锁减少了表锁的检查。
    在这里插入图片描述

    • 意向共享锁(IS)：由语句select … lock in share mode添加
      ​ 与表锁共享锁 (read)兼容，与表锁排他锁(write)互斥

    • 意向排他锁(IX)由insert、update、delete、select…for update添加 。
      ​ 与表锁共 享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥

通过SQL查看意向锁和行锁的加锁情况：select object_schema, object_name, index_name, lock_type, lock_mode, lock_data from performance_schema.data_locks;

1.3、行级锁

行级锁每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突概率最低，并发度最高。

行级锁应用在 InnoDB存储引擎中，InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类：

  • 行锁（Record Lock )

    锁定单个行记录的锁，防止其他事务对此行进行update和delete。在 RC、RR隔离级别下都支持
    在这里插入图片描述

    • 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁

    • 排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁
      在这里插入图片描述
      在这里插入图片描述

注意：

  • 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁
  • InnoDB的行锁是针对于索引加的锁，若不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁

  • 间隙锁（Gap Lock）

    锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事 务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。
    在这里插入图片描述

举例：
在这里插入图片描述

# -----------------------------------------客户端1-----------------------------------------
begin;
update usr set age = 40 where id = 5; 
# 在客户端1 update了一个不存在的id=5后，加上了间隙锁 (3,8)
commit;
# -----------------------------------------客户端2-----------------------------------------
begin;
INSERT INTO usr VALUES (7,'安拉', '17799998819', 'jd1h@126.com', '城市规划', 51,'2', '0', '2001-09-15 00:00:00');  # 阻塞，被间隙锁，直到客户端1 commit
commit;

  • 临键锁（Next-Key Lock）

    行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。 在RR隔离级别下支持。

在这里插入图片描述

默认情况下，InnoDB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key 锁进行搜 索和索引扫描，以防止幻读

举例：

非唯一索引，为了其它事务向间隙中插入一条记录 出现幻读现象，因此会把（3，7）的间隙锁上，把3之前的这块间隙也锁住，3这行数据也锁住
在这里插入图片描述

注意：
索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁 。
索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询>需求时，next-key lock 退化为间隙锁。
索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止
举例：锁19这行的数据，邻键锁锁上（19，25）以及25这行记录，还有邻键锁锁上正无穷大 以及 (25,+∞) 的间隙
在这里插入图片描述
间隙锁锁间隙，不包含对应的数据记录，只锁定该数据记录之前的这部分间隙

临键锁即包含当前的数据记录，也会锁定该数据记录之前的这部分间隙

间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁不会 阻止另一个事务在同一间隙上采用间隙锁

锁总结

按照锁的粒度进行分类：

  • 全局锁：锁定数据库中的所有表（数据库备份
  • 表级锁：每次操作锁住整张表
    • 读锁/写锁 lock tables 表名... read/write; unlock tables;
    • 元数据锁 自动加 DML语句 数据的增删改查时 MDL读锁，DDL语句表结构变更 MDL写锁
      • MDL读锁：
        • shared_read：select, select … lock in share mode,
        • shared_write：insert ,update, select … for update
      • MDL写锁：alter table
    • 意向共享锁/意向排它锁 自动加
      • 加意向共享锁：shared_read：select, select … lock in share mode,
      • 加意向排它锁：shared_write：insert ,update, select … for update
  • 行级锁：每次操作锁住对应的行数据。只针对索引，如果不是索引 升级成表锁
    • 行锁：共享锁/排它锁
      • 排它：insert,update,delete, select … for update
      • 共享：select … lock in shared mode
      • select 不加任何锁
    • 间隙锁和邻键锁：间隙锁锁住间隙，邻键锁锁数据和间隙。
  • 乐观锁/悲观锁：
    • 乐观锁：查数据时不加锁，提交数据的时候检查是否有其它事务修改了同一条数据。没有修改则提交成功，否则通过undo log回滚或者重试。读多写少
    • 悲观锁：查数据加行级锁或者表级锁 share … lock in shared mode; 适合读少写多

二、InnoDB引擎

在这里插入图片描述

2.1、逻辑存储结构

在这里插入图片描述

  • 表空间（ibd文件），一个mysql实例可以对应多个表空间，用于存储记录、索引等数据
    在这里插入图片描述

  • 段，分为数据段、索引段、回滚段，InnoDB是索引组织表，数据段是B+树的叶子结点，索引段是B+树的非叶子结点段，用来管理多个区

  • 区，表空间的单元结构，每个区大小为1M，默认情况下InnoDB存储引擎页大小为16K，即一个区公共有64个连续的页

  • 页，是InnoDB存储引擎磁盘管理的最小单元，每个页的大小默认为16KB。为了保证页的连续性，每次InnoDB都会向磁盘申请4-5个区

  • 行，InnoDB存储引擎数据是按照行进行存放的

    • 记录中的每一列col1，col2，col3
    • 两个隐藏列
      • Trx id，最后一次操作该行的事务ID
      • Roll pointer，每次对改行记录进行改动时，会把旧版本写入undo日志中，该值是指针，通过它可以找到之前没有改动的旧版本

2.2、架构——内存结构

在这里插入图片描述

  • Buffer Pool缓冲池

    InnoDB存储引擎基于磁盘文件存储，在物理硬盘和在内存中的速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行非常慢的且大部分都是随机的磁盘I/O。

    在InnoDB的缓冲池中不仅缓存了索引页和数据页，还包含了undo页、插入缓存、自适应哈希索引以及 InnoDB的锁信息等等。
    在这里插入图片描述

  • Change Buffer 更改缓冲区（针对于非唯一的二级索引页）

    • 在执行DML（数据 增删改）语句时，如果这些数据Page 没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区 Change Buffer 中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据以一定频率刷新到磁盘中。

      意义：与聚集索引不同，二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引。同样，删除和更新 可能会影响索引树中不相邻的二级索引页，如果每一次都操作磁盘，会造成大量的磁盘IO。有了 ChangeBuffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO

  • Adaptive Hash Index 自适应哈希索引

    • 用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持 hash索引，但是提供功能，即自适应hash索引。

      hash索引对于等值匹配，一般性能高于B+树，因为hash索引一般只需要一次IO即可，而B+树可能需 要几次匹配，所以hash索引的效率要高，但hash索引又不适合做范围查询、模糊匹配等。

      因此InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在某条件下hash索引效率更高， 则建立hash索引，称为自适应hash索引。 自适应哈希索引无需人工干预，是系统根据情况自动完成。

  • Log Buffer 日志缓冲区

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

2.3、架构——磁盘结构

在这里插入图片描述

  • System Tablespace 系统表空间

    • 是更改缓冲区Change Buffer 的存储区域。如果表在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)

  • File-Per-Table Tablespaces

    • 每张表的独立表空间，则每个表的文件表空间包含单个InnoDB表的数据和索引 ，并存储在文件系统上的单个数据文件中。 一个.ibd 对应一个表

  • General Tablespaces 通用表空间

    • 需要通过 CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空间
      # 创建表空间
CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;
# 创建表时指定表空间
CREATE TABLE xxx ... TABLESPACE ts_name;
#-----------举例-----------
create tablespace ts_01 add datafile 'mydb01.ibd' engine = innodb;
# 创建表空间成功后，后续创建表时 可以指定把表创建至该表空间里
use db1;
create table t1(
    id int primary key auto_increment, 
	name varchar(10)) engine = innodb tablespace ts_01;

  • Undo Tablespaces 撤销表空间

    • 撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储 undo log日志，undo_001, undo_002
      在这里插入图片描述

  • Temporary Tablespaces 临时会话表空间

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

  • Doublewrite Buffer Files 双写缓冲区

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

  • Redo Log 重做日志

    • 用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲区（redo log buffer）（在内存结构的Log Buffer中）以及 重做日志文件（redo log），前者是在内存中，后者在磁盘中。

      当事务提交之后会把所有修改信息存到该日志中，用于在刷新脏页到磁盘 发生错误时，进行数据恢复使用。以循环方式写入重做日志文件，涉及两个文件
      在这里插入图片描述

内存中的数据和磁盘的数据 是怎么 写入和读取的呢？后台线程
在这里插入图片描述

  • Master Thread（核心后台线程）：是MySQL的一个核心后台线程，负责管理和协调其他后台线程的工作，并将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性；脏页的刷新、合并插入缓存、undo页的回收

  • IO Thread（读写线程）：异步非阻塞IO 极大地提高数据库的性能，这些线程负责处理InnoDB存储引擎的IO请求，包括读取和写入磁盘上的数据。
    在这里插入图片描述
    在这里插入图片描述

  • Purge Thread（清理线程）：Purge Thread负责回收已完成提交事务的undo log，将其释放以供后续事务使用。

  • Page Cleaner Thread（页清理线程）：该线程负责在InnoDB存储引擎中执行脏页的刷新操作，将脏页写回磁盘，以确保数据的持久性和一致性。协助Master Thread。

2.4、事务原理

事务：一组操作的集合，要么全部成功，要么全部失败：

事务的四大特性：（ACID）原子性，一致性，隔离性，持久性

  • A：事务是不可分割的最小操作单元，要么全部成功，要么全部失败

  • C：事务完成时，必须使所有的数据都保持一致状态

  • I：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行

  • D：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的

在这里插入图片描述
事务的隔离级别：读未提交，读已提交，可重复读，串行化

  • 持久性：redo log。重做日志

    • 记录事务提交时，对数据页的物理修改，实现事务的持久性
    • 包含两部分：重做日志缓冲（内存结构中的Log Buffer）与 磁盘的重做日志文件，提交后会把所有修改信息保存到该文件中，用于当刷新脏页到磁盘发生错误时 进行数据恢复使用
    • update/delete执行：
      • 先看内存的BufferPool中有没有该页，如果没有该页则通过后台线程从磁盘中把页读到Buffer Pool
      • 直接操作缓冲区中的数据，该页变成脏页
      • 首先把数据页的物理变化记录在内存中的RodoLogBuffer，commit 事务提交的时候，redologBuffer会直接把数据页变化刷新到磁盘当中，即ib_logfile0，ib_logfile1中
      • 在某个时机 该页以一定频率刷新到磁盘中进行持久化，若此时出错，则可以通过磁盘文件中的redo_log进行数据恢复
      • 若脏页顺利写入磁盘，则redolog文件就不再需要，因此每过一段时间就清理一次redo log日志，是循环性的，不是永久的

日志文件都是追加的，是顺序磁盘I/O，效率比数据在磁盘的随机存取快速的多WAL 先写日志 Write-Ahead Logging

在这里插入图片描述

  • 原子性：undo log。回滚日志

    • 用于记录被修改前的信息，作用包括两个：提供回滚 和 MVCC（多版本并发控制）

      undo log 和 redo log 记录的物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的 update记录（执行update之前 数据长的样子）。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚

    • Undo log 销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC

    • Undo log 存储：undo log采用段的方式进行管理和记录，存放在段中的rollback segment 回滚段中，内部包含1024个undo log segment

2.5、MVCC

  • 当前读：读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select … lock in share mode(共享锁)，select … for update、update、insert、delete(排他锁)都是一种当前读。

    • 客户端1使用select 语句，客户端2使用 update语句进行更新，因为当前隔离级别是可重复读，因此客户端1无法看到客户端2事务对数据的更改
      在这里插入图片描述
    • 当前读
      在这里插入图片描述

  • 快照读：简单的select（不加锁）就是快照读，快照读 读取的是记录数据的可见版本，有可能是历史数据， 不加锁，是非阻塞读

    • Read Committed 读已提交：每次select，都生成一个快照读
    • Repeatable Read 可重复高读：开启事务后第一个select语句才是快照读的地方。即第一次select查询产生快照读，后面的select查询直接使用前面的快照数据
    • Serializable 串行化：快照读会退化为当前读，每次读取都需要加锁

  • MVCC： Multi-Version Concurrency Control，多版本并发控制

    • 维护一个数据的多个版本， 使得读写操作没有冲突，快照读 为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现 依赖于数据库记录中的三个隐式字段、undo log日志、readView

MVCC实现原理：

  • 记录中的隐藏字段
    在这里插入图片描述
    在这里插入图片描述

  • undo log日志 回滚日志

    • 在insert、update、delete的时候产生的便于数据回滚的日志。

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

      update、delete时，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除

  • undo log 版本链

    最终不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条 记录版本链表。

    链表的头部是最新的旧记录，链表尾部是最早的旧记录。

    那么每次查询的时候，返回哪一个版本的记录呢？ReadView的作用
    在这里插入图片描述

  • readView 读视图 决定查询读取 的记录

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

    在这里插入图片描述

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

      • READ COMMITTED ：在事务中每一次执行快照读时生成ReadView在这里插入图片描述

      • REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView

        在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该 ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返 回的结果也是一样的
        在这里插入图片描述

因此，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。 而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证
在这里插入图片描述

常用工具

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

MySQL数据库进阶知识大全-InnoDB存储引擎-索引B+Tree数据结构-sql调优-InnoDB底层原理深入-锁-MVCC机制-事务CAID底层实现
2301_77557950的博客
10-08 2264
MySQL数据库进阶学习笔记分享-内容超级齐全-简单易懂！！
MySQL数据库进阶知识（五）《锁》
m0_62101200的博客
09-26 1092
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（CPU、RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。
mysql innodb恢复数据工具.rar
06-11
这是我从网上找到的mysql/mariadb对innodb表进行数据恢复的工具，实现从innodb的数据库文件中恢复数据，用于实现下面情况：1、直接下载了innodb数据库的文件，而不是导出其数据，想恢复数据时（需要有完整的文件，比如你必须对mysql数据文件目录完整下载） 2、innodb的数据库崩溃，没有做备份，需要恢复拯救数据时 工具是有效的，我已经验证过，不过不能保证100%恢复，有部分表可能操作不成功，但，可以试试啦~~
pymysql 数据库操控
weixin_30239339的博客
02-25 169
模块安装 pip install pymysql 执行sql语句 import pymysql #添加数据 conn = pymysql.connect(host='127.0.0.1', port=3306, user='root', passwd='', db='table_name') cursor = conn.cursor()#游标 # sq...
Mysql 加锁机制与死锁分析
nihao2q的博客
03-25 1018
一、锁的分类1、锁模式乐观锁：相对悲观锁而言，乐观锁假定数据一般不产生冲突。仅在提交更新时才检测数据冲突，若冲突则向用户返回错误信息，由用户决定后续操作。适用于读多写少的场景，大量写操作会增大写冲突几率，使业务层频繁重试，大幅降低系统性能。悲观锁：具有强烈独占和排他性，假设每次访问数据都会被他人修改，对数据修改持保守态度。故在整个数据处理过程中会先对数据加锁，适用于写操作多、数据竞争激烈、数据一致性要求高的场景。2、锁粒度2.1 全局锁在 MySQL 中，全局锁会锁定整个数据库实例，阻止其他会话对数据库进行
数据库进阶
Meng
03-09 987
目录 1、MySQL数据库操作 2、SQL的select语句完整的执行顺序 3、SQL查询处理的步骤序号 4、说一下数据库存储过程的优点 5、如何对查询命令进行优化 6、数据库的优化 7、SQL注入是如何产生的，应如何防止 8、关系型数据库中，表和表之间有左连接，内连接，外连接，分别解释下他们的含义和区别 1、MySQL数据库操作 1、修改表，修改字段，重命名： altertable表名change原名 新名 类型及约束； altertablestudentschang...
MySQL数据库进阶第六篇（InnoDB引擎架构，事务原理，MVCC）
Du_XiaoNan的博客
02-27 1473
本文将带您遍览 InnoDB 存储引擎的内部机制，深入其逻辑存储结构和内存架构，解析页、段、区至行的层级，揭秘索引与数据是如何存放的。深入缓冲池的秘密，发现 InnoDB 如何以 Buffer Pool 为纽带，缓解物理硬盘与内存间的速度差异，保持高效。掌握更改缓冲区的智慧，理解非唯一二级索引背后的故事。嗅探自适应哈希索引和日志缓冲区，探寻其提升查询与事务写入的神奇之处。 文章还展现了 InnoDB 独特的磁盘结构布局，包含一应俱全的系统表空间、表级空间和特有的回滚机制，为数据的持久化与安全性搭建了坚实的基
数据库-进阶
qq_60348787的博客
11-12 553
数据库-进阶篇
MySQL-进阶.pdf
05-04
### MySQL进阶知识点详解 #### 一、存储引擎 存储引擎是MySQL中非常重要的组成部分，它们决定了数据如何被存储...通过对上述知识点的学习和实践，可以有效地提高MySQL数据库的性能和安全性，满足不同应用场景的需求。
黑马程序员MySQL-进阶篇资料### MySQL 进阶技术总结. 存储
最新发布
04-14
内容概要：本文档《MySQL-进阶篇.pdf》深入探讨了MySQL数据库的高级特性，涵盖了存储引擎、索引、SQL性能优化、视图、存储过程、触发器、锁机制、InnoDB引擎内部原理以及MySQL管理工具等多个方面。首先，文档详细...
进阶篇07——InnoDB引擎介绍
什么时候才不是菜鸟....
06-25 904
InnoDB引擎简介
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值