docker 配置加速器

这一讲中，我们就以当前8.0系列中最新的Release版本8.0.40为例，下载代码并解压。我们先简单看一下MySQL源码文件的组织（只是为了看结构，下面的输出中，把很多内容删减掉了）。...├── mysys├── plugin│ ├── auth......│ └── x......├── sql│ ├── auth│ ├── dd│ ├── gis│ ├── raii│ └── xa│ └── oci......└── vio我们先对源码中的一部分目录做一个简单的介绍。

监控是运维很重要的一部分工作。这一讲里我们介绍了MySQL中需要监控的一些关键指标。这一讲还介绍了几种监控MySQL的开源工具。真实环境中，要保证监控系统自身的可用性。而且采集的监控指标越多，监控的服务数量越多，监控系统的压力就越大。监控数据怎么存储、怎么处理，也是建设一个监控系统时需要重点考虑的。比如PMM，用VictoriaMetrics存储指标数据，用Clickhouse存储SQL信息。

在应用程序和后端MySQL之间，增加一层Proxy，可以向应用屏蔽掉后端MySQL主备切换的一些细节。这样对应用程序而言，使用起来更加方便。同时，Proxy还可以起到连接池的作用。这里，其实还有一个问题没有解决，就是后端的MySQL怎么切换？早期比较有名的是MHA工具。在云上，各个云厂商提供的RDS高可用版本，一般都标配了数据库自动切换的功能。如果是自建的环境，你可以调研下一些开源的工具，比如MHA、Orchestrator等。如果数据库的数量有一定的规模，你也可以考虑自己实现一个数据库自动切换的工具。

组复制技术通过Paxos算法，保证了事务在一个节点提交时，事务消息被集群中的大多数节点接收到。在读写分离的架构下，为了确保在备节点上能读到一致的数据，可以在备节点上将参数group_replication_consistency设置成BEFORE。虽然MGR集群支持多主模式，但是整个集群的写入能力受流控机制的限制。和单主模式相比，多主模式并没有特别大的优势。从架构的简单性考虑，如果使用MGR，建议使用单主模式。

MySQL 8.0.17版本引入了clone插件。使用Clone插件可以对本地或远程的mysql实例进行克隆操作。Clone插件会拷贝InnoDB存储引擎表，克隆得到的是数据库的一个一致的快照，可以使用这个快照数据来启动新的数据库实例。Clone插件还会记录数据库的Binlog位点，可以将克隆得到的实例作为源实例的备库。Clone插件支持本地克隆和远程克隆这两种模式。本地克隆将数据存放在源数据库所在主机上。

在备份系统的设计中，要把Binlog备份也考虑进去，有了完整的Binlog，你可以将数据库恢复到任意一个时间点。在有些场景下，使用Binlog回滚的方案，能加快数据恢复的速度，减少业务的故障时长。针对可能存在的数据丢失故障，你可以有计划地进行恢复演练，这不仅能验证备份和数据恢复方案的有效性，还能给恢复时长建立一个基线。这样，当需要紧急恢复数据时，你可以比较精确地估算出恢复需要多少时间。

数据库和服务器有时难免会出现异常，如果备库异常重启了，怎么保证数据复制还能正常进行下去呢？建议的做法是使用GTID Auto Position，这样，即使slave_master_info表里的位点信息没及时更新也没有影响，relay log损坏了也没有关系。否则，你需要将参数sync_source_info设置为1，确保读取主库Binlog的位点是准确的。使用多线程复制时，还要将参数sync_relay_log设置为1，保证Relay log及时刷新，这对性能会有比较大的影响。

使用MySQL的数据复制功能时，要监控好备库的状态和延迟情况。很多原因都会导致备库延迟，这一讲中提供了一些基本的方法。有一些延迟问题是可以避免的。如果是因为主库写入并发高引起的延迟，使用多线程复制能在一定程度上降低延迟。主库上参数binlog_transaction_dependency_tracking设置为WRITESET，能提升事务在备库的可并行度。如果你使用了级联复制架构，中间层的实例上，也要将 binlog_transaction_dependency_tracking设置为WRITESET。

好了，这一讲中，我们分析了MySQL事务的二阶段提交。使用默认的异步复制，在极端情况下，主备数据可能会出现不一致。sync_binlog设置为1时，可以保障主库的数据一致性。半同步可以部分提升主备之间的数据一致性，开启半同步会有一些性能开销，使用半同步需要做好监控。

数据复制是MySQL一直以来最受欢迎的功能之一。应用程序访问主库，对主库的修改操作都记录到Binlog中。备库从主库同步Binlog、执行Binlog，这样，备库和主库始终保持一致。基于数据复制，可以实现多种高可用架构。高可用应用程序只访问主库，备库作为主库的热备。当主库发生故障，或者主库需要停机维护时，将业务流量切到备库上，减少停机时间。在备库上进行数据库备份等运维操作。读写分离将应用的一部分读流量分发（select）到备库上执行。

锁是数据库中很重要的一个机制。MySQL中，我们主要会关注元数据锁和InnoDB的行锁。这一讲中，我们对行锁做了比较详细的介绍。REPEATABLE READ隔离级别下，使用了Gap锁、Next-key锁，锁的范围更大，因此也更容易引起死锁。应用程序遇到锁的问题时，首先要确定是锁超时还是死锁。你可以查询data_locks、data_lock_waits表来分析锁等待关系。

MVCC是InnoDB的一个重要机制，通过MVCC，MySQL实现了读不阻塞写，写不阻塞读。当然，由于MySQL的实现机制，如果事务一直没提交，Read View一直开着，会导致Undo一直不能清理，Undo表空间就会一直增长，影响数据库的性能，所以需要做好监控。

通过上一讲和这一讲，你应该已经知道MySQL中Undo的原理和作用了。在写入特别繁忙的数据库中，清理（Purge）Undo日志可能会成为制约数据库性能的一个重要因素。建议把History链表长度监控起来。有一些Purge相关的参数可以配置，具体信息可以参考官方文档。Undo还在事务的一致性读取（MVCC）中起到重要的作用，我们在下一讲中再介绍。

MySQL中，事务的行为受参数autocommit影响。如果autocommit设置为ON（这个参数默认就是ON），那么每个SQL语句会组成单独的事务，SQL语句执行完成时，InnoDB自动提交或回滚事务。autocommit设置为ON时，你也可以使用BEGIN或START TRANSACTION语句开启事务，开启事务后，可以在一个事务中执行多条SQL语句，你需要执行COMMIT语句提交事务，或使用ROLLBACK语句回滚事务。如果事务中的SQL执行时报错了，MySQL会怎么处理呢？

这一讲中我们对InnoDB的REDO机制做了一些基本的介绍，其中有几个参数需要注意。innodb_flush_log_at_trx_commit：设置为1的时候，才能保证数据不丢。innodb_log_buffer_size：Log Buffer一般设置几十M到几百M。

这一讲中，我们介绍了执行DROP TABLE、TRUNCATE TABLE、DROP INDEX等DDL操作时，InnoDB内部进行的一些处理，包括清理AHI、删除表空间、回收索引段的空间。如果你使用的版本小于8.0.23，那么执行这些DDL时对性能可能会有比较大的影响，特别是把Buffer Pool设置得比较大的实例。InnoDB还使用了自适应hash索引、Change Buffer来提升性能，我们也做了一些介绍。Double Write Buffer是用来保证数据一致性的，有一定的性能开销。

这一讲中我们对InnoDB Buffer的结构做了一些介绍。在实践中，要正确地设置相关的参数。对性能影响最大的参数应该是innodb_buffer_pool_size和innodb_buffer_pool_instances，你可以参考第4讲中的相关内容。为了保证数据库的事务ACID属性，修改Buffer Pool中的数据时，要生成REDO和UNDO日志，修改记录时还需要先获取行锁，这是接下来几节课要介绍的内容。

这一讲中，我们通过一个具体的例子，解析了InnoDB聚簇索引和二级索引的存储格式，你可以看到，我们之前关于InnoDB表和索引结构的描述，都是有依据的。我们还看到了InnoDB管理段和空间的一些数据结构，包括段描述符、区描述符、Inode页面。InnoDB数据文件中，藏着很多链表结构，有单向链表，还有双向链表，后续的课程中，还有更多的链表结构等我们去发现。

解读ibd文件的内容，需要借助一些工具，以十六进制的方式查看文件的内容。这类工具很多，比如UltraEdit。这里我使用了Mac系统下的Hex Fiend。下面这个图就是使用Hex Fiend打开t_dynamic.ibd文件后显示的内容。上面这个图里面，最左侧和最上方是地址栏，标注了文件内容的偏移量。右侧是提示区，以文本的形式展示文件内容。我们建的测试表里，存的都是文本数据，在提示区里能看到这些数据。

SQL优化是一项基本的技能。你需要掌握索引的特点，了解不同表连接算法的特点和适用场景，还需要了解优化器的一些工作原理。有的时候你可能需要改写SQL，或者使用SQL提示，来获得更好的性能。这两讲的十几个例子，都是从真实的业务场景中挑选出来的，当时使用的版本包括5.5、5.6、5.7。可以看到，在8.0中，有一些SQL实际上优化器已经能自动优化得更好了。这也是我们要使用新版本的一个重要的原因。