超详细图解！【MySQL进阶篇】MySQL架构原理_mysql图文详解

③解析器（Parser）将客户端发送的SQL进行语法解析，生成"解析树"。预处理器根据一些MySQL

规则进一步检查“解析树”是否合法，例如这里将检查数据表和数据列是否存在，还会解析名字和别

名，看看它们是否有歧义，最后生成新的“解析树”。

④查询优化器（Optimizer）根据“解析树”生成最优的执行计划。MySQL使用很多优化策略生成最

优的执行计划，可以分为两类：静态优化（编译时优化）、动态优化（运行时优化）。

• 等价变换策略

• 5=5 and a>5 改成 a > 5

• a < b and a=5 改成b>5 and a=5

• 基于联合索引，调整条件位置等

• 优化count、min、max等函数

• InnoDB引擎min函数只需要找索引最左边

• InnoDB引擎max函数只需要找索引最右边

• MyISAM引擎count(*)，不需要计算，直接返回

• 提前终止查询

• 使用了limit查询，获取limit所需的数据，就不在继续遍历后面数据

• in的优化

• MySQL对in查询，会先进行排序，再采用二分法查找数据。比如where id in (2,1,3)，变

成 in (1,2,3)

⑤查询执行引擎负责执行 SQL 语句，此时查询执行引擎会根据 SQL 语句中表的存储引擎类型，以

及对应的API接口与底层存储引擎缓存或者物理文件的交互，得到查询结果并返回给客户端。若开

启用查询缓存，这时会将SQL 语句和结果完整地保存到查询缓存（Cache&Buffer）中，以后若有

相同的 SQL 语句执行则直接返回结果。

• 如果开启了查询缓存，先将查询结果做缓存操作

• 返回结果过多，采用增量模式返回

MySQL存储引擎

---

存储引擎在MySQL的体系架构中位于第三层，负责MySQL中的数据的存储和提取，是与文件打交道的

子系统，它是根据MySQL提供的文件访问层抽象接口定制的一种文件访问机制，这种机制就叫作存储引

擎。

使用show engines命令，就可以查看当前数据库支持的引擎信息。

在5.5版本之前默认采用MyISAM存储引擎，从5.5开始采用InnoDB存储引擎。

• InnoDB：支持事务，具有提交，回滚和崩溃恢复能力，事务安全

• MyISAM：不支持事务和外键，访问速度快

• Memory：利用内存创建表，访问速度非常快，因为数据在内存，而且默认使用Hash索引，但是

一旦关闭，数据就会丢失

• Archive：归档类型引擎，仅能支持insert和select语句

• Csv：以CSV文件进行数据存储，由于文件限制，所有列必须强制指定not null，另外CSV引擎也不

支持索引和分区，适合做数据交换的中间表

• BlackHole: 黑洞，只进不出，进来消失，所有插入数据都不会保存

• Federated：可以访问远端MySQL数据库中的表。一个本地表，不保存数据，访问远程表内容

• MRG_MyISAM：一组MyISAM表的组合，这些MyISAM表必须结构相同，Merge表本身没有数据，

对Merge操作可以对一组MyISAM表进行操作。

InnoDB和MyISAM对比

InnoDB和MyISAM是使用MySQL时最常用的两种引擎类型，我们重点来看下两者区别。

• 事务和外键

InnoDB支持事务和外键，具有安全性和完整性，适合大量insert或update操作

MyISAM不支持事务和外键，它提供高速存储和检索，适合大量的select查询操作

• 锁机制

InnoDB支持行级锁，锁定指定记录。基于索引来加锁实现。

MyISAM支持表级锁，锁定整张表。

• 索引结构

InnoDB使用聚集索引（聚簇索引），索引和记录在一起存储，既缓存索引，也缓存记录。

MyISAM使用非聚集索引（非聚簇索引），索引和记录分开。

• 并发处理能力

MyISAM使用表锁，会导致写操作并发率低，读之间并不阻塞，读写阻塞。

InnoDB读写阻塞可以与隔离级别有关，可以采用多版本并发控制（MVCC）来支持高并发

• 存储文件

InnoDB表对应两个文件，一个.frm表结构文件，一个.ibd数据文件。InnoDB表最大支持64TB；

MyISAM表对应三个文件，一个.frm表结构文件，一个MYD表数据文件，一个.MYI索引文件。从

MySQL5.0开始默认限制是256TB。

• 适用场景

MyISAM

• 不需要事务支持（不支持）

• 并发相对较低（锁定机制问题）

• 数据修改相对较少，以读为主

• 数据一致性要求不高

InnoDB

• 需要事务支持（具有较好的事务特性）

• 行级锁定对高并发有很好的适应能力

• 数据更新较为频繁的场景

• 数据一致性要求较高

• 硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，减少磁盘IO

总结

• 两种引擎该如何选择？

• 是否需要事务？有，InnoDB

• 是否存在并发修改？有，InnoDB

• 是否追求快速查询，且数据修改少？是，MyISAM

• 在绝大多数情况下，推荐使用InnoDB

• 扩展资料：各个存储引擎特性对比

InnoDB存储结构

从MySQL 5.5版本开始默认使用InnoDB作为引擎，它擅长处理事务，具有自动崩溃恢复的特性，在日

常开发中使用非常广泛。下面是官方的InnoDB引擎架构图，主要分为内存结构和磁盘结构两大部分。

一、InnoDB内存结构

内存结构主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件。

• Buffer Pool：缓冲池，简称BP。BP以Page页为单位，默认大小16K，BP的底层采用链表数

据结构管理Page。在InnoDB访问表记录和索引时会在Page页中缓存，以后使用可以减少磁

盘IO操作，提升效率。

• Page管理机制

Page根据状态可以分为三种类型：

• free page ： 空闲page，未被使用

• clean page：被使用page，数据没有被修改过

• dirty page：脏页，被使用page，数据被修改过，页中数据和磁盘的数据产生了不

一致

针对上述三种page类型，InnoDB通过三种链表结构来维护和管理

• free list ：表示空闲缓冲区，管理free page

• flush list：表示需要刷新到磁盘的缓冲区，管理dirty page，内部page按修改时间

排序。脏页即存在于flush链表，也在LRU链表中，但是两种互不影响，LRU链表负

责管理page的可用性和释放，而flush链表负责管理脏页的刷盘操作。

• lru list：表示正在使用的缓冲区，管理clean page和dirty page，缓冲区以

midpoint为基点，前面链表称为new列表区，存放经常访问的数据，占63%；后

面的链表称为old列表区，存放使用较少数据，占37%。

• 改进型LRU算法维护

普通LRU：末尾淘汰法，新数据从链表头部加入，释放空间时从末尾淘汰

改性LRU：链表分为new和old两个部分，加入元素时并不是从表头插入，而是从中间

midpoint位置插入，如果数据很快被访问，那么page就会向new列表头部移动，如果

数据没有被访问，会逐步向old尾部移动，等待淘汰。

每当有新的page数据读取到buffer pool时，InnoDb引擎会判断是否有空闲页，是否足

够，如果有就将free page从free list列表删除，放入到LRU列表中。没有空闲页，就会

根据LRU算法淘汰LRU链表默认的页，将内存空间释放分配给新的页。

• Buffer Pool配置参数

show variables like ‘%innodb_page_size%’; //查看page页大小

show variables like ‘%innodb_old%’; //查看lru list中old列表参数

show variables like ‘%innodb_buffer%’; //查看buffer pool参数

建议：将innodb_buffer_pool_size设置为总内存大小的60%-80%，

innodb_buffer_pool_instances可以设置为多个，这样可以避免缓存争夺。

• Change Buffer：写缓冲区，简称CB。在进行DML操作时，如果BP没有其相应的Page数据，

并不会立刻将磁盘页加载到缓冲池，而是在CB记录缓冲变更，等未来数据被读取时，再将数

据合并恢复到BP中。

ChangeBuffer占用BufferPool空间，默认占25%，最大允许占50%，可以根据读写业务量来

进行调整。参数innodb_change_buffer_max_size;

当更新一条记录时，该记录在BufferPool存在，直接在BufferPool修改，一次内存操作。如

果该记录在BufferPool不存在（没有命中），会直接在ChangeBuffer进行一次内存操作，不

用再去磁盘查询数据，避免一次磁盘IO。当下次查询记录时，会先进性磁盘读取，然后再从

ChangeBuffer中读取信息合并，最终载入BufferPool中。

写缓冲区，仅适用于非唯一普通索引页，为什么？

如果在索引设置唯一性，在进行修改时，InnoDB必须要做唯一性校验，因此必须查询磁盘，

做一次IO操作。会直接将记录查询到BufferPool中，然后在缓冲池修改，不会在ChangeBuffer操作。

• Adaptive Hash Index：自适应哈希索引，用于优化对BP数据的查询。InnoDB存储引擎会监

控对表索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以

称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。

• Log Buffer：日志缓冲区，用来保存要写入磁盘上log文件（Redo/Undo）的数据，日志缓冲

区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘，当遇到BLOB

或多行更新的大事务操作时，增加日志缓冲区可以节省磁盘I/O。

LogBuffer主要是用于记录InnoDB引擎日志，在DML操作时会产生Redo和Undo日志。

LogBuffer空间满了，会自动写入磁盘。可以通过将innodb_log_buffer_size参数调大，减少

磁盘IO频率。

innodb_flush_log_at_trx_commit参数控制日志刷新行为，默认为1

• 0 ： 每隔1秒写日志文件和刷盘操作（写日志文件LogBuffer–>OS cache，刷盘OS

cache–>磁盘文件），最多丢失1秒数据

• 1：事务提交，立刻写日志文件和刷盘，数据不丢失，但是会频繁IO操作

• 2：事务提交，立刻写日志文件，每隔1秒钟进行刷盘操作

二、InnoDB磁盘结构

InnoDB磁盘主要包含Tablespaces，InnoDB Data Dictionary，Doublewrite Buffer、Redo Log

和Undo Logs。

• 表空间（Tablespaces）：用于存储表结构和数据。表空间又分为系统表空间、独立表空间、

通用表空间、临时表空间、Undo表空间等多种类型；

• 系统表空间（The System Tablespace）

包含InnoDB数据字典，Doublewrite Buffer，Change Buffer，Undo Logs的存储区

域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表空

间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数

innodb_data_file_path控制，默认值是ibdata1:12M:autoextend(文件名为ibdata1、

12MB、自动扩展)。

• 独立表空间（File-Per-Table Tablespaces）

默认开启，独立表空间是一个单表表空间，该表创建于自己的数据文件中，而非创建于

系统表空间中。当innodb_file_per_table选项开启时，表将被创建于表空间中。否则，

innodb将被创建于系统表空间中。每个表文件表空间由一个.ibd数据文件代表，该文件

默认被创建于数据库目录中。表空间的表文件支持动态（dynamic）和压缩(commpressed）行格式。

• 通用表空间（General Tablespaces）

通用表空间为通过create tablespace语法创建的共享表空间。通用表空间可以创建于mysql数据目录外的其他表空间，其可以容纳多张表，且其支持所有的行格式。

SQL

`CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //创建表空间ts1

CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //将表添加到ts1表空间`

• 撤销表空间（Undo Tablespaces）

撤销表空间由一个或多个包含Undo日志文件组成。在MySQL 5.7版本之前Undo占用的

是System Tablespace共享区，从5.7开始将Undo从System Tablespace分离了出来。

InnoDB使用的undo表空间由innodb_undo_tablespaces配置选项控制，默认为0。参

数值为0表示使用系统表空间ibdata1;大于0表示使用undo表空间undo_001、

undo_002等。

• 临时表空间（Temporary Tablespaces）

分为session temporary tablespaces 和global temporary tablespace两种。session

temporary tablespaces 存储的是用户创建的临时表和磁盘内部的临时表。global

temporary tablespace储存用户临时表的回滚段（rollback segments ）。mysql服务

器正常关闭或异常终止时，临时表空间将被移除，每次启动时会被重新创建。

• 数据字典（InnoDB Data Dictionary）

InnoDB数据字典由内部系统表组成，这些表包含用于查找表、索引和表字段等对象的元数

据。元数据物理上位于InnoDB系统表空间中。由于历史原因，数据字典元数据在一定程度上

与InnoDB表元数据文件（.frm文件）中存储的信息重叠。

• 双写缓冲区（Doublewrite Buffer）

位于系统表空间，是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置前，会先

将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存储子系统或

mysqld进程崩溃，InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找到页面的一个好

备份。在大多数情况下，默认情况下启用双写缓冲区，要禁用Doublewrite 缓冲区，可以将

innodb_doublewrite设置为0。使用Doublewrite 缓冲区时建议将innodb_flush_method设

置为O_DIRECT。

MySQL的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、

刷写模式。有三个值：fdatasync(默认)，O_DSYNC，O_DIRECT。设置O_DIRECT表示

数据文件写入操作会通知操作系统不要缓存数据，也不要用预读，直接从Innodb

Buffer写到磁盘文件。

默认的fdatasync意思是先写入操作系统缓存，然后再调用fsync()函数去异步刷数据文

件与redo log的缓存信息。

• 重做日志（Redo Log）

重做日志是一种基于磁盘的数据结构，用于在崩溃恢复期间更正不完整事务写入的数据。

MySQL以循环方式写入重做日志文件，记录InnoDB中所有对Buffer Pool修改的日志。当出

现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时须redo，重新把数

据更新到数据文件。读写事务在执行的过程中，都会不断的产生redo log。默认情况下，重

做日志在磁盘上由两个名为ib_logfile0和ib_logfile1的文件物理表示。

• 撤销日志（Undo Logs）

撤消日志是在事务开始之前保存的被修改数据的备份，用于例外情况时回滚事务。撤消日志

属于逻辑日志，根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表

空间中。

三、新版本结构演变

• MySQL 5.7 版本

• 将 Undo日志表空间从共享表空间 ibdata 文件中分离出来，可以在安装 MySQL 时由用

户自行指定文件大小和数量。

• 增加了 temporary 临时表空间，里面存储着临时表或临时查询结果集的数据。

• Buffer Pool 大小可以动态修改，无需重启数据库实例。

• MySQL 8.0 版本

• 将InnoDB表的数据字典和Undo都从共享表空间ibdata中彻底分离出来了，以前需要

ibdata中数据字典与独立表空间ibd文件中数据字典一致才行，8.0版本就不需要了。

• temporary 临时表空间也可以配置多个物理文件，而且均为 InnoDB 存储引擎并能创建

索引，这样加快了处理的速度。

• 用户可以像 Oracle 数据库那样设置一些表空间，每个表空间对应多个物理文件，每个

表空间可以给多个表使用，但一个表只能存储在一个表空间中。

• 将Doublewrite Buffer从共享表空间ibdata中也分离出来了。

InnoDB线程模型

• IO Thread

在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在

InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来

版本将read thread和write thread分别增大到了4个，一共有10个了。

• read thread ： 负责读取操作，将数据从磁盘加载到缓存page页。4个

• write thread：负责写操作，将缓存脏页刷新到磁盘。4个

• log thread：负责将日志缓冲区内容刷新到磁盘。1个

• insert buffer thread ：负责将写缓冲内容刷新到磁盘。1个

• Purge Thread

事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分配的undo

页。

show variables like '%innodb_purge_threads%';

• Page Cleaner Thread

作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能

达到redo log循环使用的目的。会调用write thread线程处理。

show variables like '%innodb_page_cleaners%';

• Master Thread

Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数

据异步刷新到磁盘 ，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页

回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别

是每隔1秒和10秒处理。

每1秒的操作：

• 刷新日志缓冲区，刷到磁盘

• 合并写缓冲区数据，根据IO读写压力来决定是否操作

• 刷新脏页数据到磁盘，根据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，

innodb_io_capacity）

每10秒的操作：

• 刷新脏页数据到磁盘

• 合并写缓冲区数据

• 刷新日志缓冲区

• 删除无用的undo页

InnoDB数据文件【参考文献】

一、InnoDB文件存储结构

InnoDB数据文件存储结构：

分为一个ibd数据文件–>Segment（段）–>Extent（区）–>Page（页）–>Row（行）

• Tablesapce

表空间，用于存储多个ibd数据文件，用于存储表的记录和索引。一个文件包含多个段。

• Segment

段，用于管理多个Extent，分为数据段（Leaf node segment）、索引段（Non-leaf node

segment）、回滚段（Rollback segment）。一个表至少会有两个segment，一个管理数

据，一个管理索引。每多创建一个索引，会多两个segment。

• Extent

区，一个区固定包含64个连续的页，大小为1M。当表空间不足，需要分配新的页资源，不会

一页一页分，直接分配一个区。

• Page

页，用于存储多个Row行记录，大小为16K。包含很多种页类型，比如数据页，undo页，系

统页，事务数据页，大的BLOB对象页。

• Row

行，包含了记录的字段值，事务ID（Trx id）、滚动指针（Roll pointer）、字段指针（Field

pointers）等信息。

Page是文件最基本的单位，无论何种类型的page，都是由page header，page trailer和page

body组成。如下图所示，

二、InnoDB文件存储格式

通过 SHOW TABLE STATUS 命令

一般情况下，如果row_format为REDUNDANT、COMPACT，文件格式为Antelope；如果

row_format为DYNAMIC和COMPRESSED，文件格式为Barracuda。

通过 information_schema 查看指定表的文件格式

select * from information_schema.innodb_sys_tables;

三、File文件格式（File-Format）

在早期的InnoDB版本中，文件格式只有一种，随着InnoDB引擎的发展，出现了新文件格式，用于

支持新的功能。目前InnoDB只支持两种文件格式：Antelope 和 Barracuda。

• Antelope: 先前未命名的，最原始的InnoDB文件格式，它支持两种行格式：COMPACT和

REDUNDANT，MySQL 5.6及其以前版本默认格式为Antelope。

• Barracuda: 新的文件格式。它支持InnoDB的所有行格式，包括新的行格式：COMPRESSED

和 DYNAMIC。

通过innodb_file_format 配置参数可以设置InnoDB文件格式，之前默认值为Antelope，5.7版本

开始改为Barracuda。

四、Row行格式（Row_format）

表的行格式决定了它的行是如何物理存储的，这反过来又会影响查询和DML操作的性能。如果在

单个page页中容纳更多行，查询和索引查找可以更快地工作，缓冲池中所需的内存更少，写入更

新时所需的I/O更少。

InnoDB存储引擎支持四种行格式：REDUNDANT、COMPACT、DYNAMIC和COMPRESSED。

DYNAMIC和COMPRESSED新格式引入的功能有：数据压缩、增强型长列数据的页外存储和大索引

前缀。

每个表的数据分成若干页来存储，每个页中采用B树结构存储；

如果某些字段信息过长，无法存储在B树节点中，这时候会被单独分配空间，此时被称为溢出页，

该字段被称为页外列。

• REDUNDANT 行格式

使用REDUNDANT行格式，表会将变长列值的前768字节存储在B树节点的索引记录中，其余

的存储在溢出页上。对于大于等于786字节的固定长度字段InnoDB会转换为变长字段，以便

能够在页外存储。

• COMPACT 行格式

与REDUNDANT行格式相比，COMPACT行格式减少了约20%的行存储空间，但代价是增加了

某些操作的CPU使用量。如果系统负载是受缓存命中率和磁盘速度限制，那么COMPACT格式

可能更快。如果系统负载受到CPU速度的限制，那么COMPACT格式可能会慢一些。

• DYNAMIC 行格式

使用DYNAMIC行格式，InnoDB会将表中长可变长度的列值完全存储在页外，而索引记录只

包含指向溢出页的20字节指针。大于或等于768字节的固定长度字段编码为可变长度字段。

DYNAMIC行格式支持大索引前缀，最多可以为3072字节，可通过innodb_large_prefix参数

控制。【参考文献】

• COMPRESSED 行格式

COMPRESSED行格式提供与DYNAMIC行格式相同的存储特性和功能，但增加了对表和索引

数据压缩的支持。

在创建表和索引时，文件格式都被用于每个InnoDB表数据文件（其名称与*.ibd匹配）。修改文件

格式的方法是重新创建表及其索引，最简单方法是对要修改的每个表使用以下命令：

SQL

`ALTER TABLE 表名 ROW_FORMAT=格式类型;

Undo Log

Undo Log介绍

Undo：意为撤销或取消，以撤销操作为目的，返回指定某个状态的操作。

Undo Log：数据库事务开始之前，会将要修改的记录存放到 Undo 日志里，当事务回滚时或者数

据库崩溃时，可以利用 Undo 日志，撤销未提交事务对数据库产生的影响。

Undo Log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo

log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进

行回收处理。Undo Log属于逻辑日志，记录一个变化过程。例如执行一个delete，undolog会记

录一个insert；执行一个update，undolog会记录一个相反的update。

Undo Log存储：undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollback

segment回滚段，内部包含1024个undo log segment。可以通过下面一组参数来控制Undo log存

储。

show variables like '%innodb_undo%';

Undo Log作用

实现事务的原子性

Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中，如果出现了错误或者用户执

行了 ROLLBACK 语句，MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

实现多版本并发控制（MVCC）

Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前，Undo Log

保存了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快

照读。

事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到 Undo Buffer 中。

事务B手动开启事务，执行查询操作，会读取 Undo 日志数据返回，进行快照读

Redo Log和Binlog

Redo Log日志

Redo Log介绍

Redo：顾名思义就是重做。以恢复操作为目的，在数据库发生意外时重现操作。

Redo Log：指事务中修改的任何数据，将最新的数据备份存储的位置（Redo Log），被称为重做

日志。

Redo Log 的生成和释放：随着事务操作的执行，就会生成Redo Log，在事务提交时会将产生

Redo Log写入Log Buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入

到磁盘之后，Redo Log 的使命也就完成了，Redo Log占用的空间就可以重用（被覆盖写入）。

Redo Log工作原理

Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点，尚有脏页未写入表

的 IBD 文件中，在重启 MySQL 服务的时候，根据 Redo Log 进行重做，从而达到事务的未入磁盘

数据进行持久化这一特性。

Redo Log写入机制

Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

读者福利

分享一份自己整理好的Java面试手册，还有一些面试题pdf

不要停下自己学习的脚步

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

Redo Log写入机制

Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。[外链图片转存中…(img-S7vOHB7m-1712995407046)]

[外链图片转存中…(img-f98imThu-1712995407047)]

[外链图片转存中…(img-L28v1tz7-1712995407047)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

读者福利

分享一份自己整理好的Java面试手册，还有一些面试题pdf

不要停下自己学习的脚步

[外链图片转存中…(img-U0JmHfS9-1712995407047)]

[外链图片转存中…(img-Z7WfQi66-1712995407047)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！