当前位置: 首页 > news >正文

MySQL概念简介

一.介绍

MySQL作为世界上最流行的开源关系型数据库之一,其强大的事务处理能力和高并发支持使其在各种复杂应用场景中得到广泛应用。MySQL的核心机制包括日志系统、锁机制和事务管理,这些机制共同确保了数据库的ACID特性,为应用程序提供了可靠的数据存储和处理环境。

MySQL日志系统

MySQL的日志系统是数据库可靠性、性能和一致性的重要保障。主要日志有redo log,bin log,error log,slow query log,general log,binary log,undo log等。

Redo Log:重做日志

Redo Log是InnoDB存储引擎独有的日志类型,它让MySQL拥有了崩溃恢复能力。当MySQL实例挂机或宕机时,重启时InnoDB存储引擎会使用Redo Log恢复数据,保证数据的持久性和完整性。
Redo Log记录了所有对数据库的修改操作,包括更新、插入和删除。这些修改首先被写入Redo Log buffer中,然后在事务提交结束前bin log写入后,我的redo log状态由 prepare —> commit,然后被刷新到磁盘。Redo Log的刷盘策略遵循以下规则:

  1. 当Redo Log缓冲区满时,必须将日志写入磁盘
  2. 当事务提交时,Redo Log会被写入磁盘
  3. 当InnoDB检查点(check point)生成时,Redo Log会被写入磁盘
    Redo Log的物理结构包括以下几个部分:
  • 文件头:包含日志组ID、文件起始LSN(日志序列号)、备份信息等元数据
  • 日志内容:按BLOCK为单位分割,每个BLOCK大小默认为512字节
  • 检查点信息:记录InnoDB check point信息,帮助恢复过程确定数据状态
    Redo Log采用环形缓冲区设计,由多个文件组成,使用双缓冲技术以提高写入性能。每个InnoDB存储引擎至少有一个重做日志文件组,每个文件组至少包含两个重做日志文件,如默认的iblogfile0和iblogfile1。通过合理配置Redo Log的大小和数量,可以显著提升数据库的写入性能。
innodb_log_file_size:指定每个redo日志文件的大小,通常建议设置为1G或更大
innodb_log_files_in_group:指定日志文件组中redo日志文件的数量,通常设置为2
innodb_log_group_home_dir:指定日志文件组所在路径

redo log工作机制:事务启动时,MySQL会为事务分配一个唯一标识符,在事务执行过程中,每次对于进行修改都会生成一个redo log,记录前后的数据状态。
首先写入redo log buffer中,事务提交时在将redo log buffer中的日志写入磁盘中的redo log文件中。只有redo log成功写入磁盘才算事务提交成功。
注:1.redo log文件大小是固定的,但是可以在配置文件中修改。
2.写入日志文件采用的是环形写入的方式。
3.当MySQL崩溃恢复时,会检查redo log,对于已经提交的事务会重放redo log中的记录。对于未提交的事务会通过undo log来恢复。
4. InnoDB 的崩溃恢复流程:
启动时读取 Redo Log(ib_logfile0/1)
找到最近的 Checkpoint LSN(Log Sequence Number)
从该 Checkpoint 开始 ,重放 Redo Log 中的记录(即“前滚”操作),将数据库恢复到最后一个一致性状态。

Bin Log:二进制日志(物理日志)

Bin Log是MySQL Server层维护的一种二进制日志,与InnoDB引擎中的Redo Log不同。Bin Log主要用于记录所有数据库表结构变更以及数据修改的操作(记录的是 SQL 或行级别的变更),不记录SELECT、SHOW等查询操作。
Bin Log以"事务"的形式保存在磁盘中,包含语句执行的消耗时间等元信息。Bin Log的主要应用场景包括:

  1. 主从复制:Bin Log是MySQL主从复制的基础,Master节点的Bin Log会被Slave节点拉取并执行
  2. 数据恢复:通过分析Bin Log,可以恢复到特定时间点的数据状态
    Bin Log有三种记录模式,可以根据具体需求进行选择:
  3. ROW模式:记录每一行数据被修改的情况,然后在Slave端对相同的数据进行修改。这种方式能够完全实现数据同步和数据恢复,但会产生大量的日志,消耗较多资源。(默认)
  4. STATEMENT模式:每一条被修改数据的SQL都会被记录到Master的Bin Log中,Slave在复制时会解析并执行相同的SQL。这种方式日志量少,减少了IO,提升了存储和恢复速度,但在某些情况下可能导致主从数据不一致。
  5. MIXED模式:以上两种模式的混用,MySQL会根据执行的SQL语句自动选择合适的写入模式。
    Bin Log的文件名默认采用"主机名-binlog-序列号"的格式,也可以在配置文件中指定名称。Bin Log文件的内容由各种Log Event组成,不同的修改操作对应不同的Log Event,常用的有Query Event、Row Event、Xid Event等。
log_bin:启用二进制日志,设置为ON(默认不启用log_bin,需要启用设置为mysql-bin)
binlog_format:指定二进制日志的格式,可选值包括ROW、STATEMENT、MIXED
max_binlog_cache_size:指定二进制日志缓存的最大大小
max_binlog_size:指定单个二进制日志文件的最大大小
expire_logs_days :设置bin log文件的过期时间
binlog-do-db:指定哪些数据库表的应该更新
sync_binlog:设置每多少次binlog写操作会触发一次磁盘同步操作。默认为0,即MySQL不会触发同步操作,依赖于操作系统的磁盘缓存策略。
show  variables  like '%log_bin%';查看binlog是否开启。

Undo Log:撤销日志(原子性)

Undo Log是InnoDB引擎用来处理事务的重要机制,它记录了数据的变更历史,以便在事务失败或需要回滚时恢复数据到原来的状态。
当开启一个事务但未提交时,事务中的修改操作可能会出现错误或异常,此时可以通过Undo Log将事务中的操作进行回滚。Undo Log只记录事务中的增删改操作,不记录查询操作,因为查询不会修改数据。
Undo Log的物理结构包括以下几个部分:

  1. Undo日志段:Undo日志的集合,包含在回滚段中
  2. 回滚段:包含Undo日志的存储区域,通常位于系统表空间中
  3. 活动事务的修改数据副本:保存在Undo Log中,用于回滚时恢复数据
    从MySQL 5.6开始,回滚段可以存储在 Undo 表空间中,从MySQL 5.7开始,回滚段也被分配到全局临时表空间。InnoDB最多支持128个回滚段,其中有1个回滚段用于系统表空间,32个回滚段位于临时表空间,剩余的95个用于Undo表空间。
innodb_rollback_segments:指定回滚段的个数
innodb_undo_tablespaces:指定Undo表空间的个数

slow query log(慢查询日志)

优化SQL语句,提升系统性能时需要使用。用于记录所有执行时间超过设定阈值的 SQL 语句。可以通过修改my.ini:

日志信息:

补:WAL机制(write ahead logging) yuxi+

MySQL锁机制

锁机制是数据库在并发访问时保证数据一致性和完整性的主要手段。MySQL的锁机制非常复杂,根据加锁的范围,MySQL中的锁大致可以分成全局锁、表级锁和行级锁三类。

全局锁

全局锁是对整个数据库实例加锁,最典型的全局锁是Flush Tables With Read Lock (FTWRL)命令。当你需要让整个库处于只读状态时,可以使用这个命令,之后其他线程的数据更新语句、数据定义语句和更新类事务的提交语句会被阻塞。
全局锁的典型应用场景是做全库逻辑备份。也就是把整库每个表都SELECT出来存成文本。全局锁的开销和加锁时间界于表级锁和行级锁之间,会出现死锁,锁定粒度也界于表级锁和行级锁之间,整体并发度一般。

表级锁

表级锁锁定整个表,主要用于MyISAM存储引擎。开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
表级锁的具体细分包括:

  1. 表锁:可以分为表共享读锁和表独占写锁
    • 共享锁:一旦某个客户端给表加了共享读锁,它只能够读不能写,且不会阻塞其他客户端的读操作
    • 排他锁:一旦某个客户端给表加了独占写锁,其他客户端既不能读也不能写,但不会阻塞其他客户端的锁请求
  2. 元数据锁:与表的结构变更相关,当执行ALTER TABLE等操作时会加元数据锁
  3. 意向锁:InnoDB存储引擎特有的锁类型,用于表示事务意图对某资源加锁
    • 意向共享锁(IS锁):表示事务意图对某资源加共享锁
    • 意向排他锁(IX锁):表示事务意图对某资源加排他锁

行级锁

行级锁是InnoDB存储引擎支持的最精细的锁类型,只有InnoDB引擎支持行级锁,而且锁是加在索引上的。行级锁的开销大,加锁慢;会出现死锁;锁定粒度小,发生锁冲突的概率低,并发度高。
注:select xxx for undate 排他锁(必须在事务中使用,否则锁立即释放;使用时需要注意是否命中索引,没有可以会锁全表退化为表锁)
select xxx lock in share mode 共享锁
行级锁的具体细分包括:

  1. 记录锁(Record Lock):锁定单个表中的单个行记录,这是最常见的行级锁类型
    • 共享锁(S锁):允许并发事务读取同一行,但阻止写入
    • 排他锁(X锁):阻止其他事务读取或修改同一行
  2. 间隙锁(Gap Lock):锁定一个范围(记录之间的间隙)内的所有记录,但不锁定记录本身
    • 主要用于防止幻读,确保事务在锁定范围内的记录不会被其他事务插入
  3. 临键锁(Next-Key Lock):是记录锁和间隙锁的组合,锁定记录本身及其前面的间隙(左开右闭)
    • 这是MySQL默认的行锁实现方式,可以防止幻读
      行级锁的具体行为受多种因素影响,包括隔离级别、锁模式和访问模式等。在可重复读隔离级别下,InnoDB默认使用临键锁来防止幻读。
-- 显示当前系统中的锁信息
SHOW ENGINE INNODB STATUS;

意向锁(表级锁)

当事务需要添加行锁时,会先在表上添加意向锁,这样当要添加表锁时,会先检查没有意向锁,判断是否存在冲突,无需逐行来检查。

乐观锁与悲观锁

MySQL事务隔离级别

事务隔离级别是数据库系统中用于控制事务之间相互影响程度的机制。MySQL提供了四种隔离级别,从低到高依次为:读未提交(Read Uncommitted)、读已提交(Read Committed)、可重复读(Repeatable Read)和串行化(Serializable)。默认情况下,MySQL使用可重复读隔离级别。

读未提交(Read Uncommitted)

这是最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。在这种隔离级别下,事务中的查询不会加任何锁,只在修改数据时加排他锁。
读未提交隔离级别主要适用于以下场景:

  • 读多写少的场景,且数据一致性要求不高
  • 需要尽可能高的并发度
  • 愿意容忍数据不一致的情况

读已提交(Read Committed)

允许读取并发事务已经提交的数据,可以阻止脏读,但幻读或不可重复读仍有可能发生。在这种隔离级别下,事务中的查询会加共享锁,读取完成后立即释放锁。
读已提交隔离级别是Oracle数据库的默认隔离级别,主要适用于以下场景:

  • 读多写少的场景,且数据一致性要求较高
  • 需要避免脏读的发生
  • 愿意接受一定程度的锁竞争

可重复读(Repeatable Read)

这是MySQL的默认隔离级别。可重复读保证对同一字段的多次读取结果都是一致的,除非数据是被事务自己所修改。它可以阻止脏读和不可重复读,但幻读仍有可能发生。
可重复读隔离级别主要适用于以下场景:

  • 标准的OLTP应用,需要较高的数据一致性
  • 需要避免脏读和不可重复读的发生
  • 愿意接受幻读的风险

串行化(Serializable)

这是最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰。这种隔离级别可以防止脏读、不可重复读以及幻读,但也会带来最大的锁竞争和并发性能损失。
串行化隔离级别主要适用于以下场景:

  • 对数据一致性要求极高的应用
  • 需要完全避免并发问题
  • 并发度较低的应用场景

不同隔离级别的特性对比:

隔离级别脏读不可重复读幻读
读未提交允许允许允许
读已提交防止允许允许
可重复读防止防止允许
串行化防止防止防止

MySQL事务的ACID特性

事务的ACID特性是数据库系统确保数据准确性和可靠性的四大支柱。这些特性共同构成了事务管理的基石,保障了数据的原子性、一致性、隔离性和持久性。

原子性(Atomicity)

原子性保证事务是一个原子操作单元,其对数据的修改要么全都执行,要么全都不执行。在MySQL中,原子性通过以下机制实现:

  1. 事务中的所有操作都必须记录在Redo Log中
  2. 事务提交时执行"两阶段提交"协议
    • 第一阶段:将提交请求写入Redo Log
    • 第二阶段:将数据修改写入数据文件
      如果在第一阶段完成后但第二阶段完成前系统崩溃,MySQL会在重启时回滚未完成的事务。

一致性(Consistent)

一致性保证在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性。
MySQL通过以下机制保证一致性:

  1. 外键约束:确保引用完整性
  2. 检查约束:确保行级数据有效性
  3. 事务隔离:防止并发访问导致的不一致状态

隔离性(Isolation)

隔离性保证数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的独立"环境"中执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。
MySQL通过以下机制实现隔离性:

  1. 锁机制:控制对数据的并发访问
  2. 多版本并发控制(MVCC):允许不同事务看到数据库的不同版本
  3. 事务隔离级别:控制不同事务之间的可见性规则

持久性(Durability)

持久性保证一旦事务提交,所做的修改将会永久保存到数据库中,即使系统发生故障也不会丢失。
MySQL通过以下机制保证持久性:

  1. Redo Log:记录所有修改操作,确保崩溃恢复时数据不丢失
  2. Checkpoint机制:定期将修改写入数据文件
  3. Fsync操作:确保数据被写入物理磁盘

MySQL的多版本并发控制(MVCC)

多版本并发控制(MVCC)是MySQL实现高并发读写的核心机制,特别是在InnoDB存储引擎中。MVCC允许不同事务看到数据库的不同版本,从而实现非锁定读,大大提高了系统的并发性能。

Read View与版本链

Read View是事务在启动时创建的一张快照,它记录了当前系统中所有活跃事务的ID。当事务访问数据时,会根据Read View判断数据版本的可见性。
版本链是与表相关的数据结构,它记录了表中所有行的多个版本。每个行版本包含以下信息:

  • 行数据的物理位置
  • 事务ID:创建该行版本的事务ID
  • 删除标志:指示该行是否被删除
    当一个事务修改一行数据时,InnoDB会创建一个新的行版本,而不是直接覆盖旧版本。旧版本会保留在版本链中,直到不再需要为止。

快照读与当前读

快照读(Snapshot Read)是基于Read View的读操作,它看到的是事务启动时数据库的状态,不会加锁。快照读主要用于普通的SELECT查询,是MySQL实现高并发读的关键。
当前读(Current Read)是直接读取最新版本数据的读操作,它会加锁以确保数据的一致性。当前读主要有以下几种情况:

  • 更新操作(UPDATE):需要读取当前最新版本的数据,然后进行修改
  • 插入操作(INSERT):需要检查主键或唯一索引是否存在冲突
  • 唯一性检查:在某些特定查询中,需要确保数据的唯一性
    快照读与当前读的主要区别在于:
    | 特性 | 快照读 | 当前读 |
    |—|—|—|
    | 加锁机制 | 不加锁 | 加锁 |
    | 可见性 | 基于Read View的快照 | 看到最新提交的数据 |
    | 一致性 | 不可重复读可能发生 | 不可重复读不会发生 |
    | 性能影响 | 高并发 | 低并发 |

MVCC与隔离级别的关系

MVCC的实现与事务隔离级别密切相关,不同隔离级别下,MVCC的行为有所不同:

  1. 读未提交:不使用MVCC,直接读取最新版本的数据
  2. 读已提交:使用MVCC,但Read View在每次查询时动态创建
  3. 可重复读:使用MVCC,Read View在事务开始时创建,整个事务期间保持不变
  4. 串行化:不使用MVCC,所有读操作都加锁
    在可重复读隔离级别下,MVCC通过以下机制防止脏读、不可重复读和幻读:
  • 防止脏读:通过Read View确保只能看到已提交的事务版本
  • 防止不可重复读:通过Read View在事务开始时创建,保持整个事务期间不变
  • 防止幻读:通过Next-Key Lock机制锁定记录之间的间隙,防止新记录插入

MySQL事务管理的实现机制

MySQL事务管理的实现涉及多个核心组件和机制,包括日志系统、锁机制和事务控制结构等。这些机制共同确保了事务的ACID特性。

事务日志机制

MySQL使用Redo Log和Undo Log来记录事务的修改操作,确保事务的原子性和持久性。
Redo Log记录了所有修改操作,确保在系统崩溃后可以重放这些修改。Undo Log记录了事务修改前的数据状态,支持事务的回滚。
当事务提交时,MySQL会执行两阶段提交:

  1. 第一阶段:将提交请求写入Redo Log
  2. 第二阶段:将修改写入数据文件
    如果在第一阶段完成后但第二阶段完成前系统崩溃,MySQL会在重启时回滚未完成的事务。

锁管理机制

MySQL的锁管理器负责维护和管理各种锁资源,包括全局锁、表级锁和行级锁。锁管理器需要处理以下任务:

  1. 锁的申请和释放
  2. 死锁检测和处理
  3. 锁超时管理
  4. 锁冲突的处理
    MySQL使用多种锁类型来实现事务的隔离性:
  • 共享锁(S锁):允许并发读取
  • 排他锁(X锁):阻止其他事务读取或修改
  • 意向锁:用于表示事务意图对某资源加锁
  • 间隙锁:锁定记录之间的间隙,防止幻读

事务控制结构

MySQL维护了多种事务控制结构,包括:

  1. 事务系统缓存:保存当前活动事务的信息
  2. 回滚段:保存事务的回滚信息
  3. 事务队列:管理事务的提交顺序
  4. 事务日志:记录事务的修改操作
    当事务提交时,MySQL会将修改操作记录到Redo Log和Bin Log中,并更新数据文件。当事务回滚时,MySQL会使用Undo Log将数据恢复到修改前的状态。

MySQL并发控制的实践建议

在实际应用中,合理配置和使用MySQL的并发控制机制至关重要。以下是一些实践建议:

日志配置建议

  1. Redo Log配置:
    • 增大innodb_log_file_size参数,建议设置为1G或更大
    • 调整innodb_log_files_in_group参数,通常设置为2
    • 将Redo Log文件放在独立的磁盘分区,提高IO性能
  2. Bin Log配置:
    • 合理选择binlog_format参数,根据具体需求选择ROW、STATEMENT或MIXED
    • 配置适当的max_binlog_cache_size和max_binlog_size参数
    • 定期清理旧的Bin Log文件,防止磁盘空间耗尽
  3. Undo Log配置:
    • 调整innodb_rollback_segments参数,增加回滚段数量
    • 配置innodb_undo_tablespaces参数,将Undo Log放在独立的表空间

锁管理建议

  1. 表结构设计:
    • 合理设计主键和索引,减少锁竞争
    • 避免热点数据,防止单点锁竞争
    • 使用合理的数据类型,减少数据更新操作
  2. 事务设计:
    • 缩小事务范围,减少锁定资源的数量
    • 尽量减少大事务,避免长时间持有锁
    • 合理设置隔离级别,平衡一致性与性能
  3. 查询优化:
    • 使用合适的索引,减少查询时间
    • 避免全表扫描,减少表级锁的使用
    • 优化事务中的SQL语句,减少资源竞争

隔离级别选择建议

  1. 读未提交(Read Uncommitted):
    • 适用于数据一致性要求低的场景
    • 适用于读多写少的场景
    • 注意脏读、不可重复读和幻读的风险
  2. 读已提交(Read Committed):
    • 适用于大多数OLTP应用
    • 能够避免脏读,但可能发生不可重复读和幻读
    • 比可重复读产生更多的锁竞争
  3. 可重复读(Repeatable Read):
    • MySQL默认隔离级别
    • 能够避免脏读和不可重复读,但可能发生幻读
    • 幻读问题可以通过Next-Key Lock机制解决
  4. 串行化(Serializable):
    • 适用于数据一致性要求极高的场景
    • 会导致大量的锁竞争,降低系统并发性能
    • 仅在特定场景下使用,如银行交易等高一致性要求场景
      感谢你看到这里,喜欢的可以点点关注哦!

相关文章:

  • C++ stl中的vector的相关用法 迭代器失效问题
  • 第4章 递推法
  • 1688拍立淘搜索相似商品API接口概述,json数据示例参考
  • 【编译原理】第五章 自下而上语法分析
  • HTML基础2-空元素,元素属性与页面的结构
  • 第35周Zookkeeper+Dubbo Dubbo
  • 力扣热题100之回文链表
  • CPU的基本认识
  • 企业数字化转型第二课:接受不完美(1/2)
  • 2025最新出版 Microsoft Project由入门到精通(二)
  • springboot国家化多语言实现
  • Python中的global与nonlocal关键字详解
  • AV1中的维纳滤波器
  • 数据管道的解耦艺术:Dagster I/O管理器实现存储与逻辑分离
  • Android开发-文本显示
  • 数通HCIE的通过率怎么样?
  • Linux 内核学习(7) --- 字符设备驱动
  • 蓝牙L2CAP协议概述
  • 前端日常 · 移动端网页调试
  • C——函数递归
  • 上海质子重离子医院二期项目启动,有望成为全世界最大粒子治疗中心
  • 首届上海老年学习课程展将在今年10月举办
  • 上海如何为街镇营商环境赋能?送政策、配资源、解难题、强活力
  • 中国电信财务部总经理周响华调任华润集团总会计师
  • 巴基斯坦外交部:印度侵略行径侵犯巴主权
  • 中演协:五一假期全国营业性演出票房收入同比增长3.6%