数据库	描述
mysql
TiDB
Aurora
PolarDB
TDSQL
MongoDB
OpenSearch
clickhouse
RocksDB

主从复制

• MySQL 集群的主从复制过程梳理成 3 个阶段：

  1. 写入 Binlog：主库写 binlog 日志，提交事务，并更新本地存储数据。
  2. 同步 Binlog：把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
  3. 回放 Binlog：回放 binlog，并更新存储引擎中的数据。

• 具体详细过程如下：

  1. MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。
  2. 从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
  3. 从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

UPDATE t_user SET name = 'x' WHERE id = 1

1. 执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id = 1 这一行记录：
   • 如果 id=1 这一行所在的数据页本来就在 buffer pool 中，就直接返回给执行器更新(id非唯一索引的前提下)；
   • 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
2. 执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样：
   • 如果一样的话就不进行后续更新流程；
   • 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；
3. 开启事务，InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
4. InnoDB 层开始更新记录，先生成对应redo log，并存入redo log buffer里面。当事务提交时，将该语句生成的redo log按组为单位，写入redo log file。然后更新buffer pool中的数据页，将其插入flush 链表（如果不在其中），标记为脏页、记录当前redo log对应的lsn到该页的oldest_modification。这个时候更新就算完成了。为了减少磁盘 I/O，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。（这就是 WAL 技术，MySQL 的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。但事务提交时必须要将redo log持久化）
5. 至此，一条记录更新完了。
6. 在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有 binlog 刷新到硬盘，然后进行第二阶段的提交。
7. 事务提交（为了方便说明，这里不说组提交的过程，只说两阶段提交）：
   • prepare 阶段：将 redo log 对应的事务状态设置为 prepare，然后将 redo log 刷新到硬盘；
   • commit 阶段：将 binlog 刷新到磁盘，接着调用引擎的提交事务接口，将 redo log 状态设置为 commit（将事务设置为 commit 状态后，刷入到磁盘 redo log 文件）；
8. 至此，一条更新语句执行完成。

buffer pool

常识：

• Buffer Pool 是一片连续的内存空间，通过innodb_buffer_pool_size在服务器运行过程中调整buffer pool大小，默认为128MB
• Free Page（空闲页），此页未被使用，位于 Free 链表；
• Clean Page（干净页），此页已被使用，但是页面未发生修改，位于 LRU 链表。
• Dirty Page（脏页），表示此页已被使用且已经被修改，其数据和磁盘上的数据已经不一致。
• 当脏页上的数据写入磁盘后，内存数据和磁盘数据一致，那么该页就变成了干净页。脏页同时存在于LRU链表和Flush链表。
• 提高读性能: 读取数据的时候，先从buffer pool LRU链表（干净页）读取数据，如果没有从磁盘读取并把它相邻的数据页一并加载进来。
• 提高写性能: 更新数据的时候，不需要每次都要写入磁盘，而是将 Buffer Pool 对应的缓存页标记为脏页，然后再由后台线程将脏页写入到磁盘

成本计算：

explain结果列说明：

explain 列名	描述
id	在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
select_type	SELECT关键字对应的那个查询的类型
table	表名
partitions	匹配的分区信息
type	针对单表的访问方法
possible_keys	可能用到的索引
key	实际上使用的索引
key_len	实际使用到的索引长度
ref	当使用索引列等值查询时，与索引列进行等值匹配的对象信息
rows	预估的需要读取的记录条数
filtered	某个表经过搜索条件过滤后剩余记录条数的百分比
Extra	一些额外的信息

连接的本质：

• 把各个连接表中的记录都取出来依次匹配的组合加入结果集并返回给用户

示意图：

连接的类型：

• 根据驱动表中的记录在被驱动表中无匹配时，是否加入到最后的结果集分为：

  • 内连接INNER JOIN：不加入结果集
  • 外连接：加入结果集

• 根据驱动表选择分为：

  • 左外连接 LEFT JOIN：选取左侧的表为驱动表
  • 右外连接 RIGHT JOIN：选取右侧的表为驱动表

索引合并 index merge：

• 含义：使用到多个索引来完成一次查询的执行方法
• explain 中 type 会显示index merge

核心思想：

• 读多个二级索引的操作是顺序IO（索引是有序的），只用一个索引，但是做回表操作是随机IO
• 索引合并优点：
  • 可以减少回表次数
  • 基于有序的主键回表 Rowid Ordered Retrieval，简称ROR。

索引：

1. 作用：提高查询效率
2. 索引不止存在内存中，还要写到磁盘上

常见的索引模型：

• 哈希表：适用于只有等值查询的场景（kv键值对）
• 有序数组：等值查询和范围查询场景（redis的有序集合）
• 搜索树：二叉树是搜索效率最高，大多数的数据库存储却并不使用二叉树

  [!TIP] 索引不止存在内存中，还要写到磁盘上。N 叉树（B+树）由于在读写上的性能优点，以及适配磁盘的访问模式

独立表空间：

• 表空间的是由若干个区组成的
• 区（extent）： 连续的64个页就是一个区extent，默认占用1MB空间大小。
  • 为什么要有区：同层的索引页之间以链表组织，物理距离可能会比较远，这样就会引起随机IO。使用区可以保证64个页的连续）
• 段（segment）：
  • 定义：某些零散的页以及一些完整的区的集合
  • innodb段分类：
    • 索引段：存放 B + 树的非叶子节点的区的集合；
    • 数据段：存放 B + 树的叶子节点的区的集合；
    • 回滚段：存放的是回滚数据的区的集合
• 碎片区(fragment)：
  • 背景：以完整的区为单位分配给某个段，对于数据量较小的表太浪费存储空间
  • 在一个碎片区中的页可以给不同的段分配页