高性能MySQL第四版-1

主要列出与第三版的区别

第一章、MySQL架构

MySQL逻辑架构

左右分别是第三和第四版。

第四版架构图里把第二层的“查询缓存”去掉了，也去掉了对应的文字描述。

连接管理和安全

“每个 客户 端 连接 都会 在 服务器 进程 中 拥有 一个 线程” 

第四版对这句话增加了一个前提 “默认情况下”

优化与执行

第三版中说“对于 SELECT 语句， 在 解析 查询 之前， 服务器 会 先 检查 查询 缓存。。。。”

第四版指出，由于并发的增加，缓存反而会成为瓶颈。因此在5.7.20版本，查询缓存被作为废弃特性。到了8.0版本，查询缓存完全被移除。应用程序可以自己用memcached或Redis缓存查询结果。

并发控制

第三版使用“ Unix 系统 的 email box ”为例。

第四版改用spreadsheet（Google的excel）做例子。

表锁

第三版这段被删了：“尽管 存储 引擎 可以 管理 自己的 锁， MySQL 本身 还是 会使 用 各种 有效 的 表 锁 来 实现 不同 的 目的。。。。。。”

行锁

第三版说“服务器 层 完全 不了解 存储 引擎 中的 锁 实现。”

第四版改成 “服务器 层 几乎 不了解 存储 引擎 中的 锁 实现。” 并增加了注解，说明有元数据锁，以及“应用层锁功能”。

事务

隔离级别

第四版在批注里给了两篇文章的链接，供数据库新人了解SQL的隔离级别：A Critique of ANSI SQL Isolation Levels | the morning paper (acolyer.org)，Consistency Models (jepsen.io)。

MySQL中的事务

第三版谈到了其他存储引擎如  和 NDB Cluster， XtraDB 和 PBXT。 

第四版只讲 InnoDB

在事务中混合使用存储 引擎

第四版增加了一个警告：在应用程序中最好不要混合使用多引擎。

隐式和显式锁定

第三版为  SELECT…LOCK IN SHARE MODE

第四版改成8.0版本的写法  SELECT…FOR SHARE

多版本并发控制

第三版说每个记录后面有两个隐藏列，并分了增删改查四种情况来描述InnoDb的mvcc操作

第四版把这部分描述全部重写了，并增加了一幅图来说明

每个事务开始时会分配一个事务ID，当该事务改写了一条记录，就会往Undo日志里面写一条Undo记录，其中带有该事务的ID，而回滚指针会指向这条Undo记录。这个机制也是事务回滚所需要的。

当另一个会话事务来读取记录时，InnoDb会比较这个会话里面的事务ID和记录里面的事务ID。如果记录状态对该事务应当不可见（比如修改记录的事务还没提交），那就会一直跟踪UndoLog记录，直到这条记录里面的事务ID符合对本会话事务可见的条件。这个跟踪过程可能会一直循环，循环结束的条件有可能是发现这条记录已经被删了。

事务中删除记录是通过设置记录中“info flag”的“删除位”来实现的。在UndoLog中被记录为“清除删除掩码”。

另外第四版还给了两篇博客链接来了解InnoDb的数据结构和mvcc。

The physical structure of records in InnoDB – Jeremy Cole (jcole.us)

The basics of the InnoDB undo logging and history system – Jeremy Cole (jcole.us)

感觉第四版这里写的也不是很清晰。

复制

第三版没有这一节，属于第四版新增内容。

这里简单介绍了复制，第9章会详细说明。

在源节点上，每个复制节点对应一个复制客户端的线程，并在发生写操作时被唤醒并发送新数据。

生产环境必须配置复制而且最少三个，最好还是不同地理位置的（云上的话就是不同区域）。

这些年的主要更新有：全局事务标识、多源复制、并行复制、半同步复制。

数据文件结构

第三版没有这一节，属于第四版新增内容。

8.0表的元数据被重新设计，放到数据字典表中。表的结构信息支持事务和原子定义修改。还增加了字典对象缓存，减少了服务器获取表元数据时的IO操作，更加高效。

InnoDB引擎

第三版除了InnoDB引擎之外还介绍了好几个其他的引擎。

第四版只介绍了InnoDB，其他引擎内容都删了。

此外还删除了“InnoDB的历史”这一节。

删除了这段  “在 MySQL 4. 1 以后 的 版本 中， InnoDB 可以 将 每个 表 的 数据 和 索引 存放 在 单独 的 文件 中。 InnoDB 也可以 使用 裸 设备 作为 表 空间 的 存储 介质， 但 现代 的 文件 系统 使得 裸 设备 不再 是 必要 的 选择。”

删除了这段 InnoDB 的 存储 格式 是 平台 独立 的， 也就是说 可以 将 数据 和 索引 文件 从 Intel 平台 复制 到 PowerPC 或者 Sun SPARC 平台。

增加了一段：5.6版本开始引入了在线DDL，刚开始仅有限的使用场景，在5.7和8.0有扩展。某些特定的表变更不需要全表锁也不需要外部工具，第6章会介绍。

JSON文档支持

为第四版新增内容

5.7引入JSON类型，支持自动校验和存储优化。还引入了支持JSON文档操作的SQL函数。8.0.7还支持在JSON数组上建立多值索引。第6章会介绍

数据字典变更

为第四版新增内容

8.0的另一个大变化是表的元信息存储，不再是保存到文件里面，而是移到数据字典里面，使用InnoDB表存储。这样在崩溃-恢复场景下，表的变更也也能通过事务化的方式来处理了。以前备份时需要依赖表的元数据文件来获取表的定义，现在也改成查新的数据字典来获取。

原子DDL

8.0引入。这样多个ddl语句就可以保证一起成功或者一起回滚。

版本变迁和开发模式

第三版有这两节，第四版全删了。

总结

第四版删除了第三版的这两段：

MySQL 最初 基于 ISAM 构建（ 后来 被 MyISAM 取代）， 其后 陆续 添加 了 更多 的 存储 引擎 和 事务 支持。 MySQL 有 一些 怪异 的 行为 是由 于 历史 遗留 导致 的。。。

当然， 存储 引擎 API 的 架构 也有 一些 缺点。 有时候 选择 多 并非 好事， 而在 MySQL 5. 0 和 MySQL 5. 1 中有 太多 的 存储 引擎 可以 选择。 InnoDB 对于 95％ 以上 的 用户 来说 都是 最佳 选择。。。

并增加说明InnoDB是主要的发展方向，而且本书也主要讲InnoDB。