ProSayJ-优快云博客

原创 12-LRU链表中尾部的缓存页磁盘

例如，当数据被加载到缓存页时，这个缓存页会从free链表中移除，并被放入LRU链表冷数据区域的头部。事实上，LRU链表的热数据区域内的缓存页也经常会被修改，这些修改过的数据如果不及时写入磁盘，可能会导致数据丢失或者缓存占满。当所有空闲缓存页都已用尽，并且flush链表中还存在修改过的缓存页，而LRU链表中又存放了大量缓存页时，我们就面临了没有空闲缓存页的情况。这个任务会在特定的时间间隔内，把LRU链表冷数据区域尾部的一些缓存页刷写到磁盘，并清空这些缓存页，然后将它们重新加入到free链表中。

2025-06-03 15:23:59 1015

原创 11-MySQL的LRU算法极致优化

在LRU链表的冷数据区域里，存放的通常是什么样的数据呢？这里大多数都是通过预读机制加载进来的缓存页，加载后如果在1秒钟内没有再次被访问，就会被放入冷数据区域。此外，像全表扫描或者某些大查询语句也会把大量数据加载到缓存中，虽然这些数据在1秒钟内被访问过，但之后就不再被使用。这些数据，基本都会被归类到冷数据区域。

2025-05-30 11:07:29 352

原创 10-MySQL的LRU算法优化

冷数据区域的缓存页会在加载后至少1秒钟才会根据访问情况考虑迁移到热数据区域。这样避免了短期访问就造成不必要的迁移，确保了缓存区域的稳定性和性能。这就是LRU链表冷热数据分离的一套机制。通过这些学习，我们已经深入理解了LRU链表的设计机制以及冷热数据分离的原理。冷数据区域的设计当数据页刚被加载到缓存中时，它会首先进入冷数据区域的链表头部。如果在加载后1秒内没有被访问，它会留在冷数据区域，成为冷数据。热数据区域的设计。

2025-03-26 01:12:08 1958

原创 09-LRU算法

使用简单的 LRU 链表机制存在一定的缺陷。因为预读机制或全表扫描可能会将大量数据页一次性加载到缓存中，这些数据页虽然被加载进来，但往往不会被频繁访问。这样一来，LRU 链表的前面就会充斥着这些“未来可能不常被访问”的缓存页。与此同时，原本一直被频繁访问的缓存页，可能被推到 LRU 链表的尾部。如果此时需要腾出空间来加载新的数据页，LRU 链表尾部的那些频繁访问的缓存页就可能会被错误地刷入磁盘，造成缓存效率的浪费。

2025-03-24 14:04:40 631

原创 08-Flush链表

接下来，我们来探讨一个关键问题。当你在执行增、删、改操作时，如果发现数据页尚未缓存，系统就会通过 free 链表找到一个空闲的缓存页，并将数据页从磁盘读取到该缓存页中。当更新缓存页时，可以通过调整缓存页描述数据块中的 flush 链表指针，将所有脏页的描述数据块串联成一个双向链表，即 flush 链表。然而，当你对缓存页中的数据进行修改后，会导致缓存页中的数据与磁盘上的数据页内容出现不一致的情况。它的本质同样是利用缓存页的描述数据块中的两个指针，将所有被修改过的缓存页的描述数据块串联成一个双向链表。

2025-03-15 00:41:17 425

原创 07-Free链表

Free 链表在 Buffer Pool 中扮演着至关重要的角色，主要负责管理内存中的空闲缓存页。在从磁盘读取数据页到 Buffer Pool 时，free 链表确保了系统能够快速、有效地分配和重用缓存页，而不需要频繁进行内存分配操作。这种机制不仅提高了性能，也降低了内存碎片的风险，帮助数据库在高负载情况下保持良好的性能表现。

2025-03-11 11:42:35 707

原创 06-Buffer Pool

每个缓存页不仅存储了数据页的内容，还包含了一块描述信息来记录缓存页的元数据。这个描述信息对于管理缓存页、定位数据页、优化性能等方面非常重要。由于每个缓存页都需要存储描述信息，因此 Buffer Pool 的实际内存占用会比配置值稍大一些。16KB 的缓存页大小在性能、内存使用、兼容性和硬件优化之间达到了较好的平衡，适合大多数应用场景。

2025-03-09 00:19:06 953

原创 05 真实生产环境下的数据库机器配置如何规划？

另外对于数据库而言，如果可以的话，最好是采用SSD固态硬盘而不是普通的机械硬盘，因为数据库最大的复杂就在于大量的磁盘IO，他需要大量的读写磁盘文件，所以如果能使用SSD固态硬盘，那么你的数据库每秒能抗的并发请求量就会更高一些。有一定并发量的互联网类的系统，对数据库可能会产生每秒几百，每秒几千，甚至每秒上万的并发请求量，对于这类场景下，我们应该选择什么样的机器去部署数据库，才能比较好的抗下我们的系统压力呢?对于16C32G的机器部署的MySQL数据库而言，每秒扛个两三千，甚至三四千的并发请求也都是可以的。

2025-03-08 00:21:21 1800

原创 04 InnoDB存储引擎中的update执行流程

其实是用来保持redo log日志与binlog日志一致的。我们来举个例子，假设我们在提交事务的时候，一共有上图中的5、6、7三个步骤，必须是三个步骤都执行完毕，才算是提交了事务。那么在我们刚完成步骤5的时候，也就是redo log刚刷入磁盘文件的时候，mysql宕机了，此时怎么办？这个时候因为没有最终的事务commit标记在redo日志里，所以此次事务可以判定为不成功。不会说redo日志文件里有这次更新的日志，但是binlog日志文件里没有这次更新的日志，不会出现数据不一致的问题。

2025-03-06 13:44:04 1971 1

原创 03-初步了解InnoDB存储引擎的架构设计

1️⃣ 当这个参数的值为0的时候，那么你提交事务的时候，不会把redo log buffer里的数据刷入磁盘文件的，此时可能你都提交事务了，结果mysql宕机了，然后此时内存里的数据全部丢失。接着我们来思考一个问题，按照上图的说明，现在已经把内存里的数据进行了修改，但是磁盘上的数据还没修改，那么此时万一MySQL所在的机器宕机了，必然会导致内存里修改过的数据丢失，这可怎么办呢？所谓的redo日志，就是记录下来你对数据做了什么修改，比如对“id=10这行记录修改了name字段的值为xxx”，这就是一个日志。

2025-03-02 15:41:21 661

原创 02-为了执行SQL语句,MySQL做了哪些设计

还是更新磁盘的数据？举个例子，比如执行器可能会先调用存储引擎的一个接口，去获取“users”表中的第一行数据，然后判断一下这个数据的“id”字段的值是否等于我们期望的一个值，如果不是的话，那就继续调用存储引擎的接口，去获取“users”表的下一行数据。执行器就会去根据我们的优化器生成的一套执行计划，然后不停的调用存储引擎的各种接口去完成SQL语句的执行计划，大致就是不停的更新或者提取一些数据出来。，他会按照一定的步骤去查询内存缓存数据，更新磁盘数据，查询磁盘数据，等等，执行诸如此类的一系列的操作。

2025-03-01 23:36:20 770

原创 01-运行中的代码是如何与MySQL打交道的吗?

如果我们要访问数据库，必须得跟数据库建立一个网络连接，那么这个连接由谁来建立呢？其实答案就是这个MySQL驱动，他会在底层跟数据库建立网络连接，有网络连接，接着才能去发送请求给数据库服务器！实际上MySQL中的连接池就是维护了与系统之间的多个数据库连接。除此之外，你的系统每次跟MySQL建立连接的时候，还会根据你传递过来的账号和密码，进行账号密码的验证，库表权限的验证。常见的数据库连接池有DBCP，C3P0，Druid，等等。MySQL会提供各个语言版本的MySQL驱动。

2025-03-01 23:30:45 224