高性能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 00:00:00
- ISBN： 9787121442575
- 分类： 社会文化-社科
- 出版社： 电子工业出版社
这里的内容仅为读书笔记，如果您需要阅读原版书籍，请购买正版以支持原创。感谢您的理解和支持。
高亮划线
第1章 MySQL架构
-
📌 MySQL解析查询以创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。
- ⏱ 2023-05-01 22:19:16
-
📌 一个写锁既会阻塞读锁也会阻塞其他的写锁
- ⏱ 2023-04-03 11:04:25
-
📌 一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定包含需要修改的部分数据，而不是所有的资源。更理想的方式是，只对需要修改的数据片段进行精确的锁定。任何时候，让锁定的数据量最小化，理论上就能保证在给定资源上同时进行更改操作，只要被修改的数据彼此不冲突即可。问题是加锁也需要消耗资源。锁的各种操作，包括获取锁、检查锁是否空闲、释放锁等，都会增加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会受影响。
- ⏱ 2023-05-01 22:31:13
-
📌 锁定策略是锁开销和数据安全性之间的平衡，这种平衡会影响性能
- ⏱ 2023-04-21 09:54:30
-
📌 。锁是数据库实现一致性保证的方法
- ⏱ 2023-04-21 09:54:49
-
📌 表锁(table lock)是MySQL中最基本也是开销最小的锁策略
- ⏱ 2023-04-21 09:55:12
-
📌 当客户端想对表进行写操作（插入、删除、更新等）时，需要先获得一个写锁，这会阻塞其他客户端对该表的所有读写操作。只有没有人执行写操作时，其他读取的客户端才能获得读锁，读锁之间不会相互阻塞。
- ⏱ 2023-04-21 09:55:32
-
📌 写锁队列和读锁队列是分开的，但写锁队列的优先级绝对高于读队列
- ⏱ 2023-04-21 09:56:41
-
📌 使用行级锁(row lock)可以最大程度地支持并发处理（也带来了最大的锁开销）
- ⏱ 2023-04-21 09:57:07
-
📌 行级锁是在存储引擎而不是服务器中实现的
- ⏱ 2023-04-21 09:57:37
-
📌 。事务就是一组SQL语句，作为一个工作单元以原子方式进行处理
- ⏱ 2023-04-21 09:58:58
-
📌 死锁是指两个或多个事务相互持有和请求相同资源上的锁，产生了循环依赖
- ⏱ 2023-04-21 10:05:54
-
📌 InnoDB目前处理死锁的方式是将持有最少行级排他锁的事务回滚（这是一种最容易回滚的近似算法）。
- ⏱ 2023-04-21 10:06:38
-
📌 死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的
- ⏱ 2023-04-21 10:07:00
-
📌 事务日志有助于提高事务的效率
- ⏱ 2023-04-21 10:08:47
-
📌 存储引擎只需要更改内存中的数据副本，而不用每次修改磁盘中的表，这会非常快。然后再把更改的记录写入事务日志中，事务日志会被持久化保存在硬盘上。因为事务日志采用的是追加写操作，是在硬盘中一小块区域内的顺序I/O，而不是需要写多个地方的随机I/O，所以写入事务日志是一种相对较快的操作。最后会有一个后台进程在某个时间去更新硬盘中的表。因此，大多数使用这种技术（write-ahead logging，预写式日志）的存储引擎修改数据最终需要写入磁盘两次。如果修改操作已经写入事务日志，那么即使系统在数据本身写入硬盘之前发生崩溃，存储引擎仍可在重新启动时恢复更改。具体的恢复方法则因存储引擎而异。
- ⏱ 2023-04-21 10:09:14
-
📌 默认情况下，单个INSERT、UPDATE或DELETE语句会被隐式包装在一个事务中并在执行成功后立即提交，这称为自动提交(AUTOCOMMIT)模式。通过禁用此模式，可以在事务中执行一系列语句，并在结束时执行COMMIT提交事务或ROLLBACK回滚事务。
- ⏱ 2023-04-21 10:11:38
-
📌 在当前连接中，可以使用SET命令设置AUTOCOMMIT变量来启用或禁用自动提交模式
- ⏱ 2023-04-21 10:11:24
-
📌 当启用AUTOCOMMIT时，也可以使用关键字BEGIN或者START TRANSACTION来开始一个多语句的事务
- ⏱ 2023-04-21 10:12:15
-
📌 MySQL不在服务器层管理事务，事务是由下层的存储引擎实现的
- ⏱ 2023-04-21 10:15:39
-
📌 InnoDB使用两阶段锁定协议(two-phase locking protocol)。在事务执行期间，随时都可以获取锁，但锁只有在提交或回滚后才会释放，并且所有的锁会同时释放。
- ⏱ 2023-04-21 10:28:39
-
📌 MySQL的大多数事务型存储引擎使用的都不是简单的行级锁机制。它们会将行级锁和可以提高并发性能的多版本并发控制(MVCC)技术结合使用。
- ⏱ 2023-05-01 22:05:09
-
📌 MVCC的工作原理是使用数据在某个时间点的快照来实现的。
- ⏱ 2023-04-24 08:54:48
-
📌 这意味着，无论事务运行多长时间，都可以看到数据的一致视图，也意味着不同的事务可以在同一时间看到同一张表中的不同数据！
- ⏱ 2023-04-24 08:55:15
-
📌 InnoDB通过为每个事务在启动时分配一个事务ID来实现MVCC。该ID在事务首次读取任何数据时分配。在该事务中修改记录时，将向Undo日志写入一条说明如何恢复该更改的Undo记录，并且事务的回滚指针指向该Undo日志记录。这就是事务如何在需要时执行回滚的方法。
- ⏱ 2023-04-21 12:37:47
第7章 创建高性能的索引
-
📌 索引，在MySQL中也叫作键(key)，是存储引擎用于快速找到记录的一种数据结构。
- ⏱ 2023-05-13 17:38:33
-
📌 索引可以包含一列或多列的值。如果索引包含多列，那么列的顺序也十分重要，因为MySQL只能有效地使用索引的最左前缀列。
- ⏱ 2023-05-02 10:06:01
-
📌 在MySQL中，索引是在存储引擎层而不是服务器层实现的。
- ⏱ 2023-05-13 17:42:49
-
📌 NDB集群存储引擎虽然依然使用了BTREE标识，但在其内部实际上使用了T-tree结构存储这种索引，InnoDB则使用的是B+tree。
- ⏱ 2023-05-13 17:43:54
-
📌 B-tree索引能够加快数据访问的速度，这是因为有了索引，在查询某些条件的数据时，存储引擎不再需要进行全表扫描。而是从索引的根节点（图中并未画出）开始进行搜索，根节点的槽中存放了指向子节点的指针，存储引擎根据这些指针向下层查找。通过比较节点页的值和要查找的值可以找到合适的指针进入下层子节点，这些指针实际上定义了子节点页中值的上限和下限。最终存储引擎要么找到对应的值，要么该记录不存在。
- ⏱ 2023-05-13 17:48:15
-
📌 B-tree是按照索引列中的数据大小顺序存储的，所以很适合按照范围来查询。
- ⏱ 2023-05-02 10:11:12
-
📌 InnoDB存储引擎有一个被称为自适应哈希索引的特性。当InnoDB发现某些索引值被非常频繁地被访问时，它会在原有的B-tree索引之上，在内存中再构建一个哈希索引。
- ⏱ 2023-05-13 18:02:36
-
📌 B-tree索引适用于全键值、键值范围或键前缀查找。其中键前缀查找只适用于根据最左前缀的查找
- ⏱ 2023-05-13 18:11:38
读书笔记
第1章 MySQL架构
划线评论
-
📌 服务器维护了一个缓存区，用于存放已就绪的线程，因此不需要为每个新的连接创建或者销毁线程。
- 💭 线程池
- ⏱ 2023-05-01 22:17:42
划线评论
-
📌 所以在同一个事务中，混合使用多种存储引擎是不可靠的
- 💭 会使得数据库中的数据处于不一致的状态，事务变得没有意义了
- ⏱ 2023-04-21 10:27:27
划线评论
-
📌 所以在同一个事务中，混合使用多种存储引擎是不可靠的
- 💭 在事务中混用存储引擎会造成非事务表不可回滚
- ⏱ 2023-04-21 10:25:57