高性能MySQL（第4版）

高性能MySQL（第4版）

• 作者: Silvia Botros Jeremy Tinley
• 简介: 《高性能 MySQL》一直是 MySQL 领域的经典之作，影响了一代又一代的 DBA 和技术人员，从第3 版出版到第 4 版出版过去了近十年，MySQL 也从 5.5 版本更新到了 8.0 版本。第 4 版中增加了大量对 MySQL 5.7 和 8.0 版本新特性的介绍，删除了一些在新版本中已经废弃或者不再常用的功能，还增加了对云数据库的介绍，减少了在官方文档中已有的基础使用和配置相关的内容。这些年，MySQL 经过在大量大规模互联网场景中的应用验证，使得本书在继续关注高性能之外，还用了较多的篇幅来介绍如何实现 MySQL 的大规模可扩展应用和合规性问题，这是相比第 3 版最大的不同，也是本书封面上所写的“经过大规模运维验证的策略”的体现。本书适合数据库管理员（DBA）阅读，也适合系统运维和开发人员参考学习。不管你是数据库新手还是专家，相信都能从本书中有所收获。
• 出版时间: 2022-09-01
• ISBN: 9787121442575
• 分类: 计算机-数据库
• 出版社: 电子工业出版社
• 字数: 245520
• 在线阅读: 微信读书
• 划线数量: 38
• 想法数量: 1
  

笔记

第1章 MySQL架构

📌 从MySQL 5.7.20版本开始，查询缓存已经被官方标注为被弃用的特性，并在8.0版本中被完全移除。

• ⏱ 2025-03-19 09:44:52 ^11-2884-2935

📌 并发控制这一经典问题的解决方案相当简单。处理并发读/写访问的系统通常实现一个由两种锁类型组成的锁系统。这两种锁通常被称为共享锁(shared lock)和排他锁(exclusive lock)，也叫读锁(read lock)和写锁(write lock)。

• ⏱ 2025-03-19 09:46:27 ^11-3958-4115

📌 锁定策略是锁开销和数据安全性之间的平衡，这种平衡会影响性能。

• ⏱ 2025-03-19 09:47:44 ^11-4823-4853

📌 表锁(table lock)

• ⏱ 2025-03-19 10:38:59 ^11-5242-5256

📌 行级锁(row lock)

• ⏱ 2025-03-19 10:39:16 ^11-5674-5687

📌 行级锁是在存储引擎而不是服务器中实现的。

• ⏱ 2025-03-19 10:39:47 ^11-5875-5895

📌 事务就是一组SQL语句，作为一个工作单元以原子方式进行处理。如果数据库引擎能够成功地对数据库应用整组语句，那么就执行该组语句。如果其中有任何一条语句因为崩溃或其他原因无法执行，那么整组语句都不执行。也就是说，作为事务的一组语句，要么全部执行成功，要么全部执行失败。

• ⏱ 2025-03-19 10:40:05 ^11-6236-6368

📌 银行应用是解释事务必要性的经典例子。[插图]假设一个银行的数据库有两张表：支票表(checking)和储蓄表(savings)。现在要从用户Jane的支票账户转移200美元到她的储蓄账户，那么需要至少三个步骤：
1.确保支票账户的余额高于200美元。
2.从支票账户的余额中减去200美元。
3.在储蓄账户的余额中增加200美元。

• ⏱ 2025-03-19 11:42:23 ^11-6485

📌 可以用START TRANSACTION语句启动事务，然后要么使用COMMIT提交事务将修改的数据持久保留，要么使用ROLLBACK撤销所有的修改。

• ⏱ 2025-03-19 10:46:51 ^11-6941-7015

📌 两阶段提交系统
💭 二阶段提交（英语：Two-phase Commit）是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议（Protocol）。

在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新后的数据写入磁盘等等）。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

需要注意的是，二阶段提交（英语：2PC）不应该与并发控制中的二阶段锁（英语：2PL）混淆。

• ⏱ 2025-03-19 11:03:30 ^19836794-7YL6KuvXF
  

📌 ACID代表原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)。

• ⏱ 2025-03-19 11:10:15 ^11-7577-7646

📌 原子性(atomicity)

• ⏱ 2025-03-19 11:10:36 ^11-7705-7719

📌 一个事务必须被视为一个不可分割的工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。

• ⏱ 2025-03-19 17:04:20 ^11-7748-7831

📌 一致性(consistency)

• ⏱ 2025-03-19 11:10:41 ^11-7860-7876

📌 数据库总是从一个一致性状态转换到下一个一致性状态。

• ⏱ 2025-03-19 17:04:13 ^11-7905-7930

📌 隔离性(isolation)

• ⏱ 2025-03-19 11:40:33 ^11-8043-8057

📌 通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的，这就是隔离性带来的结果。

• ⏱ 2025-03-19 17:04:07 ^11-8086-8131

📌 持久性(durability)

• ⏱ 2025-03-19 11:40:57 ^11-8283-8298

📌 一旦提交，事务所做的修改就会被永久保存到数据库中。此时即使系统崩溃，数据也不会丢失。

• ⏱ 2025-03-19 17:04:31 ^11-8327-8369

📌 持久性是一个有点模糊的概念，实际上持久性也分很多不同的级别。有些持久性策略能够提供非常强的安全保障，而有些则未必。而且不可能有100%的持久性保障（如果数据库本身就能做到真正的持久性，那么备份又怎么能增加持久性呢？）。
ACID事务和InnoDB引擎提供的保证是MySQL中最强大、最成熟的特性之一。虽然它们在吞吐量方面做了一定的权衡，但如果应用得当，就可以避免在应用层实现大量复杂逻辑。
隔离级别
隔离性在实际操作中比看起来复杂得多。ANSI SQL标准定义了4种隔离级别。如果你是数据库领域的新手，我们强烈建议你在阅读特定的MySQL实现之前先熟悉ANSI SQL[插图]的通用标准。这个通用标准的目标是定义在事务内外可见和不可见的更改的规则。较低的隔离级别通常允许更高的并发性，并且开销也更低。
[插图]每种存储引擎实现的隔离级别都不尽相同。如果你熟悉其他的数据库产品，可能会发现某些特性和你期望的会有些不一样（因此本节不打算讨论更详细的内容）。读者可以根据所选择的存储引擎，查阅相关的手册。
下面简单地介绍一下这4种隔离级别。
READ UNCOMMITTED（未提交读）

• ⏱ 2025-03-19 11:42:37 ^11-8369

📌 READ UNCOMMITTED（未提交读）

• ⏱ 2025-03-19 11:42:07 ^11-9337-9359

📌 READ COMMITTED（提交读）

• ⏱ 2025-03-19 11:42:59 ^11-9600-9619

📌 READ COMMITTED满足前面提到的隔离性的简单定义：一个事务可以看到其他事务在它开始之后提交的修改，但在该事务提交之前，其所做的任何修改对其他事务都是不可见的。

• ⏱ 2025-03-19 11:43:52 ^11-9689-9773

📌 REPEATABLE READ（可重复读）

• ⏱ 2025-03-19 11:43:03 ^11-9867-9888

📌 保证了在同一个事务中多次读取相同行数据的结果是一样的。

• ⏱ 2025-03-19 12:09:54 ^11-10080-10107

📌 幻读(phantom read)

• ⏱ 2025-03-19 12:10:00 ^11-10131-10147

📌 所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行(phantom row)。

• ⏱ 2025-03-19 12:10:12 ^11-10151-10234

📌 多版本并发控制(MVCC，Multiversion Concurrency Control)

• ⏱ 2025-03-19 12:10:22 ^11-10253-10299

📌 SERIALIZABLE（可串行化）

• ⏱ 2025-03-19 11:43:06 ^11-10411-10429

📌 简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。

• ⏱ 2025-03-19 14:26:33 ^11-10522-10573

📌 死锁是指两个或多个事务相互持有和请求相同资源上的锁，产生了循环依赖。

• ⏱ 2025-03-19 16:51:54 ^11-11024-11058

📌 InnoDB目前处理死锁的方式是将持有最少行级排他锁的事务回滚（这是一种最容易回滚的近似算法）。

• ⏱ 2025-03-19 14:30:43 ^11-11964-12012

第7章 创建高性能的索引

📌 当表有聚簇索引时，它的数据行实际上存放在索引的叶子页(leaf page)中。

• ⏱ 2024-02-20 19:08:08 ^17-18958-18997

📌 InnoDB根据主键聚簇数据。

• ⏱ 2024-02-20 19:08:56 ^17-19714-19729

📌 如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为覆盖索引。需要注意的是，只有B-tree索引可以用于覆盖索引。

• ⏱ 2024-02-20 19:07:41 ^17-27036-27100

📌 B-tree索引可能会产生碎片化，这会降低查询的效率。碎片化的索引可能会以很差或者无序的方式存储在磁盘上。

• ⏱ 2025-04-11 17:54:54 ^17-41755-41808

📌 行碎片(Row fragmentation)

• ⏱ 2025-04-11 17:55:00 ^17-42071-42121

📌 行间碎片(Intra-row fragmentation)

• ⏱ 2025-04-11 17:55:05 ^17-42232-42318

📌 剩余空间碎片(Free space fragmentation)

• ⏱ 2025-04-11 17:55:12 ^17-42431-42520

📌 可以通过执行OPTIMIZE TABLE或者导出再导入的方式来重新整理数据。

• ⏱ 2025-04-11 17:54:35 ^17-42595-42633