AI 助理
备案控制台
开发者社区 数据库 文章 正文

MySQL5.7杀手级新特性：GTID原理与实战

2016-07-15 27342
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
RDS MySQL Serverless 高可用系列，价值2615元额度，1个月
简介： MySQL5.7杀手级新特性：GTID原理与实战 一、理论篇 1.1 GTID是什么(what) 1.1.1 GTID组成和架构 GTID 架构 a) GTID = server_uuid:transaction_id b) server_uuid 来源于 auto.cnf c) G

MySQL5.7杀手级新特性：GTID原理与实战

一、理论篇

1.1 GTID是什么(what)

1.1.1 GTID组成和架构

  • GTID 架构

a) GTID = server_uuid:transaction_id
b) server_uuid 来源于 auto.cnf
c) GTID: 在一组复制中，全局唯一

gtid_set:
    uuid_set [, uuid_set] ...
    | ''

uuid_set:
    uuid:interval[:interval]...

uuid:
    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
    [0-9|A-F]

interval:
    n[-n]

    (n >= 1)

1.1.2 GTID和Binlog的关系

  • GTID在binlog中的结构

binlog_gtid

  • GTID event 结构

gtid_event

  • Previous_gtid_log_event
  1. Previous_gtid_log_event 在每个binlog 头部都会有
  2. 每次binlog rotate的时候存储在binlog头部
  3. Previous-GTIDs在binlog中只会存储在这台机器上执行过的所有binlog，不包括手动设置gtid_purged值。
  4. 换句话说，如果你手动set global gtid_purged=xx； 那么xx是不会记录在Previous_gtid_log_event中的。
  • GTID和Binlog之间的关系是怎么对应的呢

如何才能找到GTID=?对应的binlog文件呢？

* 假设有4个binlog: bin.001,bin.002,bin.003,bin.004
* bin.001 : Previous-GTIDs=empty; binlog_event有：1-40
* bin.002 : Previous-GTIDs=1-40;  binlog_event有：41-80
* bin.003 : Previous-GTIDs=1-80;  binlog_event有：81-120
* bin.004 : Previous-GTIDs=1-120;  binlog_event有：121-160

1. 假设现在我们要找GTID=$A，那么MySQL的扫描顺序为： 从最后一个binlog开始扫描（即：bin.004）
2. bin.004的Previous-GTIDs=1-120，如果$A=140 > Previous-GTIDs,那么肯定在bin.004中
3. bin.004的Previous-GTIDs=1-120，如果$A=88 包含在Previous-GTIDs中,那么继续对比上一个binlog文件 bin.003,然后再循环前面2个步骤，直到找到为止

1.1.3 重要参数的持久化

  • GTID相关参数
参数 comment
gtid_executed 执行过的所有GTID
gtid_purged 丢弃掉的GTID
gtid_mode gtid模式
gtid_next session级别的变量，下一个gtid
gtid_owned 正在运行的gtid
enforce_gtid_consistency 保证GTID安全的参数
  • 重要参数如何持久化

1) 如何持久化gtid_executed [ log-bin=on,log_slave_update=on ]

1. gtid_executed = mysql.gtid_executed 【normal】
or
2. gtid_executed = mysql.gtid_executed +  last_binlog中最后没写到mysql.gtid_executed中的gtid_event  【recover】

2) 如何持久化重置的gtid_purged值?

reset master; set global gtid_purged=$A:a-b;

1. 由于有可能手动设置过gtid_purged=$A:a-b, binlog.index中，last_binlog的Previous-GTIDs并不会包含$A:a-b
2. 由于有可能手动设置过gtid_purged=$A:a-b, binlog.index中，first_binlog的Previous-GTIDs肯定不会出现$A:a-b
3. 重置的gtid_purged = @@global.gtid_executed(mysql.gtid_executed:注意，考虑到这个表的更新触发条件，所以这里用@@global.gtid_executed代替) - last_binlog的Previous-GTIDs  - last_binlog所有的gtid_event
4. 下面就用 $reset_gtid_purged 来表示重置的gtid

3）如何持久化gtid_purged [ log-bin=on,log_slave_update=on ]

gtid_purged=binlog.index:first_binlog的Previous-GTIDs  + $reset_gtid_purged

1.1.4 开启GTID的必备条件

  • MySQL 5.6
gtid_mode=ON(必选)
log_bin=ON(必选)
log-slave-updates=ON(必选)
enforce-gtid-consistency(必选)
  • MySQL 5.7

MySQL5.7.13 or higher

gtid_mode=ON(必选)
enforce-gtid-consistency（必选）
log_bin=ON（可选）--高可用切换，最好设置ON
log-slave-updates=ON（可选）--高可用切换，最好设置ON

1.1.5 新的复制协议 COM_BINLOG_DUMP_GTID

  • Slave sends to master range of identifiers of executed transactions to master
  • Master send all other transactions to slave
  • 同样的GTID不能被执行两次，如果有同样的GTID，会自动被skip掉。

com_binlog_dump_gtid

slave1 : 将自身的UUID1:1 发送给 master，然后接收到了 UUID1:2,UUID1:3 event
slave2 : 将自身的UUID1:1,UUID1:2 发送给 master，然后接收到了UUID1:3 event

1.1.6 GTID重要函数和新语法

  • 重要函数
Name Description
GTID_SUBSET(subset,set) returns true (1) if all GTIDs in subset are also in set
GTID_SUBTRACT(set,subset) returns only those GTIDs from set that are not in subset
WAIT_FOR_EXECUTED_GTID_SET(gtid_set[, timeout]) Wait until the given GTIDs have executed on slave.
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set, timeout) Wait until the given GTIDs have executed on slave
  • 新语法
START SLAVE [thread_types] [until_option] [connection_options]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type:
    IO_THREAD | SQL_THREAD

until_option:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
          |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
          |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
          |   SQL_AFTER_MTS_GAPS  }


* 举个栗子：

1. START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

表示，当SQL_thread 执行到3E11FA47-71CA-11E1-9E33-C80AA9429562:10 的时候停止，下一个事务是11

2. START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

表示，当SQL_thread 执行到3E11FA47-71CA-11E1-9E33-C80AA9429562:56 的时候停止，56是最后一个提交的事务。

1.2 GTID有什么好处(why)

1.2.1 classic replication [运维之痛]

classic_rpl

1.2.2 GTID replication [so easy]

GTID_rpl

1.3 GTID的Limitation

  • 不安全的事务

设置enforce-gtid-consistency=ON

1. CREATE TABLE ... SELECT statements
2. CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statements inside transactions
3. 同时更新 事务引擎 和 非事务引擎。

1.4 MySQL5.7 GTID crash-safe

http://dev.mysql.com/doc/refman/5.7/en/replication-solutions-unexpected-slave-halt.html

关于crash safe ， 可以参考官方文档列出的安全配置

  • 单线程复制

Non-GTID 推荐配置： relay_log_recovery=1，relay_log_info_repository=TABLE，master_info_repository=TABLE
GTID 推荐配置：MASTER_AUTO_POSITION=on，relay_log_recovery=0

safe_1

  • 多线程复制

Non-GTID 推荐配置： relay_log_recovery=1, sync_relay_log=1,relay_log_info_repository=TABLE，master_info_repository=TABLE
GTID 推荐配置： MASTER_AUTO_POSITION=on, relay_log_recovery=0

safe_multi

二、实战篇(how)

2.1 使用GTID搭建Replication

2.1.1 从0开始搭建

  • step 1: 让所有server处于同一个点
mysql> SET @@global.read_only = ON;
  • step 2: 关闭所有MySQL
shell> mysqladmin -uusername -p shutdown
  • step 3: 重启所有MySQL，并开启GTID
shell> mysqld --gtid-mode=ON --log-bin --enforce-gtid-consistency &

当然，在my.cnf中配置好最佳

  • step 4: change master
mysql> CHANGE MASTER TO
     >     MASTER_HOST = host,
     >     MASTER_PORT = port,
     >     MASTER_USER = user,
     >     MASTER_PASSWORD = password,
     >     MASTER_AUTO_POSITION = 1;

mysql> START SLAVE;
  • step 5: 让master 可读可写
mysql> SET @@global.read_only = OFF;

2.1.2 从备份中恢复&搭建

  • step 1: 备份
mysqldump xx 获取并且记录gtid_purged值
or
冷备份 --获取并且记录gtid_executed值，这个就相当于mysqldump中得到的gtid_purged
  • step 2: 在新服务器上reset master，导入备份
reset master; --清空gtid信息
导入备份； --如果是逻辑导入，请设置sql_log_bin=off
set global gtid_purged=xx;
  • step 3: change master
mysql> CHANGE MASTER TO
     >     MASTER_HOST = host,
     >     MASTER_PORT = port,
     >     MASTER_USER = user,
     >     MASTER_PASSWORD = password,
     >     MASTER_AUTO_POSITION = 1;

mysql> START SLAVE;

2.2 如何从classic replication 升级成 GTID replication

2.2.1 offline 方式升级

offline 的方式升级最简单。全部关机，然后配置好GTID，重启，change master to MASTER_AUTO_POSITION=1。

2.2.2 online 方式升级

这里先介绍几个重要GTID_MODE的value

  • GTID_MODE = OFF : 不产生Normal_GTID，只接受来自master的ANONYMOUS_GTID
  • GTID_MODE = OFF_PERMISSIVE : 不产生Normal_GTID，可以接受来自master的ANONYMOUS_GTID & Normal_GTID
  • GTID_MODE = ON_PERMISSIVE : 产生Normal_GTID，可以接受来自master的ANONYMOUS_GTID & Normal_GTID
  • GTID_MODE = ON : 产生Normal_GTID，只接受来自master的Normal_GTID
  • master和slave的gtid_mode 组合搭配矩阵图

水平的GTID_MODE为：master ， 垂直的GTID_MODE为：slave

gtid_mode OFF(master) OFF_PERMISSIVE(master) ON_PERMISSIVE(master) ON(master)
OFF(slave) Y Y N N
OFF_PERMISSIVE(slave) Y Y Y Y(auto_position可以开启)
ON_PERMISSIVE(slave) Y Y Y Y(auto_position可以开启)
ON(slave) N N Y Y(auto_position可以开启)

归纳总结：
1） 当master产生Normal_GTID的时候（ON_PERMISSIVE，ON），如果slave的gtid_mode（OFF）不能接受Normal_GTID，那么就会报错
2） 当master产生ANONYMOUS_GTID的时候（OFF_PERMISSIVE，OFF），如果slave的gtid_mode（ON）不能接受ANONYMOUS_GTID，那么就会报错
3） 设置auto_position的条件： 当master gtid_mode=ON时，slave可以为OFF_PERMISSIVE，ON_PERMISSIVE，ON。除此之外，都不能设置auto_position = on

下面罗列下，如何online 升级为GTID模式。

  • step 1: 每台server执行

检查错误日志，直到没有错误出现，才能进行下一步

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
  • step 2: 每台server执行
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
  • step 3: 每台server执行

不用关心一组复制集群的server的执行顺序，只需要保证每个Server都执行了，才能进行下一步

SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
  • step 4: 每台server执行

不用关心一组复制集群的server的执行顺序，只需要保证每个Server都执行了，才能进行下一步

SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
  • step 5: 在每台server上执行，如果ONGOING_ANONYMOUS_TRANSACTION_COUNT=0就可以

不需要一直为0，只要出现过0一次，就ok

SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
  • step 6： 确保所有anonymous事务传递到slave上了
1. master

SHOW MASTER STATUS;

2. 每个slave

SELECT MASTER_POS_WAIT(file, position);


或者，等一段时间，只要不是大的延迟，一般都没问题
  • step 7: 每台Server上执行
SET @@GLOBAL.GTID_MODE = ON;
  • step 8: 在每台server上将my.cnf中添加好gtid配置
gtid_mode=ON(必选)
enforce-gtid-consistency（必选）
log_bin=ON（可选）--高可用切换，最好设置ON
log-slave-updates=ON（可选）--高可用切换，最好设置ON
  • step 9: change master
STOP SLAVE;
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
START SLAVE;

2.3 GTID failover

2.3.1 MySQL crash

配置好loss-less semi-sync replication，可以更可靠的保证数据零丢失。
以下说的都是crash 后，起不来的情况

  • binlog 在master还有日志没有传递到 slave
1. 选取最新的slave，change master to maseter_auto_position同步好
2. mysqlbinlog 将没传递过来的binlog在新master上replay
3. 打开新master的surper_read_only=off;
  • binlog 已经传递到slave
1. 选取最新的slave，change master to maseter_auto_position同步好
2. 打开新master的surper_read_only=off;

2.3.2 OS crash

1. 选取最新的slave，change master to maseter_auto_position同步好
2. 打开新master的surper_read_only=off;

以上操作，在传统模式复制下，只能通过MHA来实现，MHA比较复杂。
现在，在GTID模式下，实现起来非常简单，且非常方便。

2.4 GTID 运维和错误处理

  1. 使用GTID后，对原来传统的运维有不同之处了，需要调整过来。
  2. 使用Row模式且复制配置正确的情况下，基本上很少发现有复制出错的情况。
  3. slave 设置 super_read_only=on

2.4.1 错误场景: Errant transaction

出现这种问题基本有两种情况

  1. 复制参数没有配置正确，当slave crash后，会出现重复键问题
  2. DBA操作不正确，不小心在slave上执行了事务

对于第一个重复键问题

  • 传统模式
* skip transation;

SQL> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
SQL> START SLAVE;
  • GTID模式
SQL> SET GTID_NEXT='b9b4712a-df64-11e3-b391-60672090eb04:7';   --设置需要跳过的gtid event
SQL> BEGIN;COMMIT;
SQL> SET GTID_NEXT='AUTOMATIC';
SQL> START SLAVE;

对于第二种不小心多执行了事务

这种情况就比较难了，这样已经导致了数据不一致，大多数情况，建议slave重做
如何避免： slave 设置 super_read_only=on

重点： 当发生inject empty transction后，有可能会丢失事务

这里说下inject empty transction的隐患

  1. 当slave上inject empty transction，说明有一个master的事务被忽略了（这里假设是 $uuid:100）
  2. 事务丢失一：如果此时此刻master挂了，这个slave被选举为新master，那么其他的slave如果还没有执行到$uuid:100,就会丢失掉$uuid:100这个事务。
  3. 事务丢失二：如果从备份中重新搭建一个slave，需要重新执行之前的所有事务，而此时，master挂了， 又回到了事务丢失一的场景。

三、QA

3.1 如何重置gtid_executed，gtid_purged。

  • 设置gtid_executed
目前只能够reset master
  • 设置gtid_purged
* 当gtid_executed 非空的时候，不能设置gtid_purged
* 当gtid_executed 为空的时候（即刚刚备份好的镜像，刚搭建的mysql），可以直接SET @@GLOBAL.GTID_PURGED='0ad6eae9-2d66-11e6-864f-ecf4bbf1f42c:1-3';

3.2 如果auto.cnf 被删掉了，对于GTID的复制会有什么影响？

如果被删掉，重启后，server-uuid 会变

3.3 手动设置 set @@gtid_purged = xx:yy, mysql会去主动修改binlog的头么

不会

3.4 GTID和复制过滤规则之间如何协同工作？MySQL，test还能愉快的过滤掉吗？

可以，改过滤的会自己过滤，不用担心
文章标签：
云数据库 RDS MySQL 版
关系型数据库
MySQL
SQL
机器学习/深度学习
关键词：
云数据库 RDS MySQL 版原理
云数据库 RDS MySQL 版特性
云数据库 RDS MySQL 版实战
云数据库 RDS MySQL 版gtid
云数据库 RDS MySQL 版gtid实战
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL，然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
兰春
目录
相关文章
东阳马生架构
|
20天前
|
关系型数据库 MySQL Linux
MySQL原理简介—6.简单的生产优化案例
本文介绍了数据库和存储系统的几个主题： 1. **MySQL日志的顺序写和数据文件的随机读指标**：解释了磁盘随机读和顺序写的原理及对数据库性能的影响。 2. **Linux存储系统软件层原理及IO调度优化原理**：解析了Linux存储系统的分层架构，包括VFS、Page Cache、IO调度等，并推荐使用deadline算法优化IO调度。 3. **数据库服务器使用的RAID存储架构**：介绍了RAID技术的基本概念及其如何通过多磁盘阵列提高存储容量和数据冗余性。 4. **数据库Too many connections故障定位**：分析了MySQL连接数限制问题的原因及解决方法。
东阳马生架构
68 23
Shepherd
|
10天前
|
关系型数据库 MySQL 数据库
RDS用多了，你还知道MySQL主从复制底层原理和实现方案吗？
随着数据量增长和业务扩展，单个数据库难以满足需求，需调整为集群模式以实现负载均衡和读写分离。MySQL主从复制是常见的高可用架构，通过binlog日志同步数据，确保主从数据一致性。本文详细介绍MySQL主从复制原理及配置步骤，包括一主二从集群的搭建过程，帮助读者实现稳定可靠的数据库高可用架构。
Shepherd
39 9
RDS用多了，你还知道MySQL主从复制底层原理和实现方案吗？
东阳马生架构
|
18天前
|
SQL 存储 关系型数据库
MySQL原理简介—9.MySQL索引原理
本文详细介绍了MySQL索引的设计与使用原则，涵盖磁盘数据页的存储结构、页分裂机制、主键索引设计及查询过程、聚簇索引和二级索引的原理、B+树索引的维护、联合索引的使用规则、SQL排序和分组时如何利用索引、回表查询对性能的影响以及索引覆盖的概念。此外还讨论了索引设计的案例，包括如何处理where筛选和order by排序之间的冲突、低基数字段的处理方式、范围查询字段的位置安排，以及通过辅助索引来优化特定查询场景。总结了设计索引的原则，如尽量包含where、order by、group by中的字段，选择离散度高的字段作为索引，限制索引数量，并针对频繁查询的低基数字段进行特殊处理等。
东阳马生架构
60 18
MySQL原理简介—9.MySQL索引原理
东阳马生架构
|
16天前
|
存储 关系型数据库 MySQL
MySQL底层概述—6.索引原理
本文详细回顾了：索引原理、二叉查找树、平衡二叉树(AVL树)、红黑树、B-Tree、B+Tree、Hash索引、聚簇索引与非聚簇索引。
东阳马生架构
70 11
MySQL底层概述—6.索引原理
东阳马生架构
|
18天前
|
SQL 监控 关系型数据库
MySQL原理简介—12.MySQL主从同步
本文介绍了四种为MySQL搭建主从复制架构的方法：异步复制、半同步复制、GTID复制和并行复制。异步复制通过配置主库和从库实现简单的主从架构，但存在数据丢失风险；半同步复制确保日志复制到从库后再提交事务，提高了数据安全性；GTID复制简化了配置过程，增强了复制的可靠性和管理性；并行复制通过多线程技术降低主从同步延迟，保证数据一致性。此外，还讨论了如何使用工具监控主从延迟及应对策略，如强制读主库以确保即时读取最新数据。
东阳马生架构
47 4
MySQL原理简介—12.MySQL主从同步
东阳马生架构
|
20天前
|
SQL 缓存 关系型数据库
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容： 1. redo日志的意义：确保事务提交后数据不丢失，通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成：记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制：redo日志先写入Redo Log Buffer，再批量刷入磁盘文件，减少随机写以提高性能。 4. Redo Log Buffer解析：描述Redo Log Buffer的内存结构及刷盘时机，如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理：用于事务回滚，记录插入、删除和更新前的数据状态，确保事务可完整回滚。
东阳马生架构
95 22
东阳马生架构
|
19天前
|
SQL 缓存 关系型数据库
MySQL原理简介—8.MySQL并发事务处理
这段内容深入探讨了SQL语句执行原理、事务并发问题、MySQL事务隔离级别及其实现机制、锁机制以及数据库性能优化等多个方面。
东阳马生架构
52 13
东阳马生架构
|
18天前
|
SQL 关系型数据库 MySQL
MySQL原理简介—11.优化案例介绍
本文介绍了四个SQL性能优化案例，涵盖不同场景下的问题分析与解决方案： 1. 禁止或改写SQL避免自动半连接优化。 2. 指定索引避免按聚簇索引全表扫描大表。 3. 按聚簇索引扫描小表减少回表次数。 4. 避免产生长事务长时间执行。
东阳马生架构
39 8
东阳马生架构
|
18天前
|
SQL 存储 关系型数据库
MySQL原理简介—10.SQL语句和执行计划
本文介绍了MySQL执行计划的相关概念及其优化方法。首先解释了什么是执行计划，它是SQL语句在查询时如何检索、筛选和排序数据的过程。接着详细描述了执行计划中常见的访问类型，如const、ref、range、index和all等，并分析了它们的性能特点。文中还探讨了多表关联查询的原理及优化策略，包括驱动表和被驱动表的选择。此外，文章讨论了全表扫描和索引的成本计算方法，以及MySQL如何通过成本估算选择最优执行计划。最后，介绍了explain命令的各个参数含义，帮助理解查询优化器的工作机制。通过这些内容，读者可以更好地理解和优化SQL查询性能。
东阳马生架构
65 6
拉丁解牛说技术
|
20天前
|
存储 缓存 关系型数据库
MySQL进阶突击系列(08)年少不知BufferPool核心原理 | 大哥送来三条大金链子LRU、Flush、Free
本文深入探讨了MySQL中InnoDB存储引擎的buffer pool机制，包括其内存管理、数据页加载与淘汰策略。Buffer pool作为高并发读写的缓存池，默认大小为128MB，通过free链表、flush链表和LRU链表管理数据页的存取与淘汰。其中，改进型LRU链表采用冷热分离设计，确保预读机制不会影响缓存公平性。文章还介绍了缓存数据页的刷盘机制及参数配置，帮助读者理解buffer pool的运行原理，优化MySQL性能。
拉丁解牛说技术
45 1

热门文章

最新文章

  • 1
    MySQL底层概述—2.InnoDB磁盘结构
  • 2
    MySQL底层概述—1.InnoDB内存结构
  • 3
    MySQL原理简介—1.SQL的执行流程
  • 4
    SpringBoot 通过集成 Flink CDC 来实时追踪 MySql 数据变动
  • 5
    嵌入式C++、STM32、MySQL、GPS、InfluxDB和MQTT协议数据可视化
  • 6
    如何实现 MySQL 的读写分离？
  • 7
    MySQL原理简介—3.生产环境的部署压测
  • 8
    Docker Compose V2 安装常用数据库MySQL+Mongo
  • 9
    MySQL进阶突击系列(07) 她气鼓鼓递来一条SQL | 怎么看执行计划、SQL怎么优化?
  • 10
    MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
  • 1
    数据管理服务DMS支持MySQL数据库的无锁结构变更
    13
  • 2
    如何解决 MySQL 数据库服务器 CPU 飙升的情况
    61
  • 3
    join查询可以⽆限叠加吗？MySQL对join查询有什么限制吗？
    43
  • 4
    MySQL日志
    22
  • 5
    图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
    19
  • 6
    图解MySQL【日志】——两阶段提交
    19
  • 7
    图解MySQL【日志】——Redo Log
    21
  • 8
    MySQL和SQLSugar百万条数据查询分页优化
    36
  • 9
    【YashanDB 知识库】MySQL 迁移至崖山 char 类型数据自动补空格问题
    16
  • 10
    【YashanDB 知识库】如何将 mysql 含有 group by 的 SQL 转换成崖山支持的 SQL
    21

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • 搭建电商项目架构连接MySQL
  • 搭建4层电商项目架构，实战连接MySQL
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布

    • 相关实验场景

    更多
  • MySQL基础-学生管理系统数据库设计
  • 如何快速连接云数据库RDS MySQL
  • MySQL数据库快速部署实践
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 使用CloudLens采集RDS日志并进行审计分析

    • 推荐镜像

    更多
  • mysql
  • postgresql
  • mariadb
    • 下一篇
    通义万相：视觉生成大模型再进化