压缩表从名字上来看，简单理解为压缩后的表，也就是把原始表根据一定的压缩算法按照一定的压缩比率压缩后生成的表。
Buffer Pool 是什么？从字面上看是缓存池的意思，没错，它其实也就是缓存池的意思。它是 MySQL 当中至关重要的一个组件，可以这么说，MySQL的所有的增删改的操作都是在 Buffer Pool 中执行的。 但是数据不是在磁盘中的吗？怎么会和缓存池又有什么关系呢？那是因为如果 MySQL的操作都在磁盘中进行，那很显然效率是很低的，效率为什么低？因为数据库要从磁盘中拿数据啊，那肯定就需要IO啊，并且数据库并不知道它将要查找的数据是磁盘的哪个位置，所以这就需要进行随机IO，那这个性能简直就别玩了。所以 MySQL对数据的操作都是在内存中进行的，也就是在 Buffer Pool 这个内存组件中。
Buffer Pool 是什么？从字面上看是缓存池的意思，没错，它其实也就是缓存池的意思。它是 MySQL 当中至关重要的一个组件，可以这么说，MySQL的所有的增删改的操作都是在 Buffer Pool 中执行的。
Doublewrite Buffer是MySQL数据库中InnoDB存储引擎的一种机制，用于解决部分写失效的问题，提高数据完整性和可靠性。Doublewrite Buffer是内存+磁盘的结构，包括内存结构和磁盘结构两个部分。
MySQL是一种流行的关系型数据库管理系统，广泛应用于各种场景。数据库中的数据储存在磁盘上，而MySQL使用数据页来组织和存储数据。数据页是MySQL中的关键概念，直接影响着数据库的性能和存储效率。本文将深入探讨MySQL数据页的构造和数据的组织方式，揭示数据页中数据的奥秘。
前面我写了几篇关于 mysql 索引的文章，索引是 mysql 非常重要的一部分。你也可能经常会看到一些关于 mysql 军规、mysql 查询优化的文章，其实这些操作的背后都是基于一定的原理的，你要想明白这些原理，首先就得知道 mysql 底层的一些东西。
这应该是 MySQL 原理中最底层的部分了，我们存在 MySQL 中的数据，到底在磁盘上长啥样。你可能会说，数据不都存储在聚簇索引中吗？但很遗憾，你并没有回答我的问题。我会再问你，那聚簇索引在磁盘上又长啥样？
临近春节，相信每个公司都会进行全面巡检，无论是业务层还是数据库层，达到事前预防的目的；今天就来分享一下针对MySQL数据存储层面，在数据库存储来不及扩容的情况下，MySQL中的压缩方案；
程序员平时和mysql打交道一定不少，可以说每天都有接触到，但是mysql一张表到底能存多少数据呢？计算根据是什么呢？接下来咱们逐一探讨
这几天在读《MySQL技术内幕 InnoDB存储引擎》，对 Innodb逻辑存储结构有了些了解，顺便也记录一下；
常见的服务器一般都是Linux操作系统，Linux文件系统页（OS Page）的大小默认是4KB。而MySQL的页（Page）大小默认是16KB。可以使用如下命令查看MySQL的Page大小：
程序员平时和mysql打交道一定不少，可以说每天都有接触到，但是mysql一张表到底能存多少数据呢？计算根据是什么呢？接下来咱们逐一探讨，除了小编总结的面试题以外，小编还整理了一份MySQL的实战学习笔记，分享给正在阅读的小伙伴们。
这一节我们来介绍缓冲池的内部结构。如果不清楚缓冲池是什么东西可以查看之前系列的第一篇文章。缓冲池最简单的理解为数据库磁盘文件在内存对应的映射，是一个十分重要的核心组件，缓冲池的内容和细节还是挺多的，这部分内容个人会限制篇幅让读者更好的消化。
1千万，2千万，或者上亿条数据？具体的答案不重要，当然肯定也不会是一个固定的数目，今天我们就一起来探讨探讨这个问题。
回答干脆利索，16K呗，我想这是大多数人的第一个反应和回答，这个回答没有毛病。但这16k里面到底有多少是你表中存储的那些实实在在的数据 ？？
对于innoDB存储引擎来说，数据是存储在磁盘上，而执行引擎想要操作数据，必须先将磁盘的数据加载到内存中才能操作。当数据从磁盘中取出后，缓存内存中，下次查询同样的数据的时候，直接从内存中读取，这样大大提高了查询性能。
我们聊到了Buffer Pool，很多朋友估计还是不是很了解，本文咱们就来聊聊。
在数据库系统的世界中，保障数据的完整性和稳定性是至关重要的任务。为了实现这一目标，MySQL内部使用了许多精巧而高效的机制。
在操作系统中,我们执行一个指令去磁盘取数据,那么他会从磁盘取出4KB数据,这个4KB就是一个局部单位,而这4KB数据就是你的指令中取出的数据周围的数据,因为操作系统认为你下一次的数据会从这条数据的周围中取。每次从磁盘读取数据在这里称为一次磁盘IO。那么在Mysql的操作当中,也有这么一个原理。
如果您遇到全球少数的MySQL顾问之一，请他审核您的SQL语句和表结构设计，我相信他会告诉您一些有关好的主键设计的重要性。特别是对InnoDB，我相信他已经想您解释了索引合并和页分裂。这两个概念与性能密切相关，在设计任意索引（不仅仅是主键）时都应该考虑这方面因素。
上篇文章《InnoDB在SQL查询中的关键功能和优化策略》对InnoDB的查询操作和优化事项进行了说明。但是，MySQL作为一个存储数据的产品，怎么确保数据的持久性和不丢失才是最重要的，感兴趣的可以跟随本文一探究竟。
MySQL作为一款面向企业的数据库产品，必须具有能够处理高峰活动和数据容量增长的能力。在进行容量规划时，架构师需要考虑因为用户的活动和数据增长所导致的资源使用变化，并需要考虑未来的促销活动或者其他预计的繁忙时期。
回答：MySQL InnoDB 引擎底层数据结构是 B+ 树，所谓的索引其实就是一棵 B+ 树，一个表有多少个索引就会有多少颗 B+ 树，MySQL 中的数据都是按顺序保存在 B+ 树叶子节点上的。
《MySQL8.0的redo log优化》一文中，我们介绍了MySQL8.0对redo log 的优化方式，其中有一条是脏页有序加入到flush_list的优化。今天我们来看看flush_list的概念，并解释下这个优化规则。
MySQL的服务实现通过后台多个线程、内存池、文件交互来实现对外服务的，不同线程实现不同的资源操作，各个线程相互协助，共同来完成数据库的服务。MySQL常用的后台线程概括如下，分为Master Thread，IO Thread，Purge Thread，Page Cleaner Thread
今天想和大家聊一聊 MySQL 中的 redo log，其实最早我是想聊两阶段提交的，后来想想可能有小伙伴还不了解 binlog，所以就先整了一篇 binlog： 手把手教你玩 MySQL 删库不跑路，直接把 MySQL 的 binlog 玩溜！ MySQL删库不跑路（视频版） binlog 大家懂了之后，接下来还差个 redo log，redo log 大家也懂了，那么再讲两阶段提交相信小伙伴们就很容易懂了，咱们一步一步来。 1. 谁的 redo log 学习 redo log，我觉得首先要搞明白一个问
前几篇对MySQL的知识介绍，让我们知道MySQL基本单位是数据页，默认情况下每个数据页的大小是16kb。数据页被读取到内存（Buffer Pool）中后被称为缓存页,，当对Buffer Pool中的数据页做了更新后，此时的数据页叫做：脏页，脏页最终是要刷入磁盘的，那么问题来了。
本节为分区高级篇，主要针对分区底层原理进行介绍，建议不了解分区概念的先看下面的分区入门篇:
种数据库都有它自己的内存机制，如果说汽车的三大件，发动机，变速箱，底盘。数据库的内存机制算是数据库核心的核心，一个没有好的内存管理和分配的数据库，一定是不会有好的性能。
墨墨导读：Page是MySQL Innodb存储的最基本结构，也是Innodb磁盘管理的最小单位，了解page的一些特性，可以更容易理解MySQL。
InnoDB一棵B+树可以存放多少行数据？这个问题的简单回答是：约2千万。为什么是这么多呢？因为这是可以算出来的，要搞清楚这个问题，我们先从InnoDB索引数据结构、数据组织方式说起。
Hello我又来了，快年底了，作为一个有抱负的码农，我想给自己攒一个年终总结。自上上篇写了手动搭建Redis集群和MySQL主从同步(非Docker)和上篇写了动手实现MySQL读写分离and故障转移之后，索性这次把数据库中最核心的也是最难搞懂的内容，也就是索引，分享给大家。
MySQL的数据存储结构主要分两个方面：物理存储结构与内存存储结构，作为数据库，所有的数据最后一定要落到磁盘上，才能完成持久化的存储。内存结构为了实现提升数据库整体性能，主要用于存储临时数据和日志的缓冲。本文主要讲MySQL的物理结构，以及MySQL的内存结构，对于存储引擎也主要以InnoDB为主。
虽然说 MySQL 的数据是存储在磁盘里的，但是也不能每次都从磁盘里面读取数据，这样性能是极差的。
InnoDB数据存储的研究中，我提到了MySQL的Bug #67963，题目是“InnoDB每16384页中浪费62页”。我说: InnoDB偶尔需要分配一些内部记账页面;每256mib数据对应2个页。为此，它分配一个区段(64个页面)，分配所需的两个页面，然后将剩余的区段(62个空闲页面)添加到一个名为FREE_FRAG的区段列表中，该区段用于单页分配。几乎没有从该列表中分配页面，所以这些页面被浪费了。 这是相当微妙的，在任何大型InnoDB表中只浪费0.37%的磁盘空间，但尽管如此，这还是很有趣的，而且很容易修复。 浪费0.37%的磁盘空间是不幸的，但不是一个大问题……
mysql主从复制原理是大厂后端的高频面试题，了解mysql主从复制原理非常有必要。
这一节我们来继续讲述关于缓冲池的内容，以及关于数据页和表空间的内容，当然内容页比较基础和简单，理解相关概念即可。
这个问题可能比较抽象，如果对MySQL索引结构不理解的人来说，可能蒙，所以建议先去看看索引结构再来看这个问题。MySQL 选择将节点大小设置为 16KB 而不是更大的原因，主要是为了在内存管理、性能、磁盘 I/O 效率、适应性和兼容性之间取得平衡。本文将从讲解页的结构开始，然后分析为什么MySQL为什么把节点大小设置为16K，而不是更大?
很多开发者在最开始时其实都对数据库有一个比较模糊的认识，觉得数据库就是一堆数据的集合，但是实际却比这复杂的多，数据库领域中有两个词非常容易混淆。数据库和实例：
在 InnoDB 中，你的 delete 操作，并不会真的把数据删除，mysql 实际上只是给删除的数据打了个标记，标记为删除，因此你使用 delete 删除表中的数据，表文件在磁盘上所占空间不会变小，我们这里暂且称之为假删除。
update语句是如何执行 , 如何将执行后的新数据持久化在磁盘中 可以假设两种情境：
同学B：因为索引其实就是一种优化查询的数据结构，比如Mysql中的索引是用B+树实现的，而B+树就是一种数据结构，可以优化查询速度，可以利用索引快速查找数据，所以能优化查询。
这一节本来计划开始索引的学习，但是在InnoDB存储引擎的索引里，存在一些数据存储结构的概念，这一节先了解一下InnodDB的逻辑存储结构，为索引的学习打好基础。
由上图可以看出，tablespace由segment组成，segment由extend组成，extend由page组成，page由row组成 在MySQL中默认会有一个共享表空间ibdata1，如果设置了innodb_file_per_table=on时，每张表内的数据放在各自的tablespace中，私有tablespace仅包括数据，索引，插入缓冲Bitmap页，而其他的例如回滚信息，插入缓冲索引页，系统事务信息，二次写缓冲等都还是放在共享表空间
上篇文章说mysql5.6之后新增了系统变量optimizer_tance可以看到他的优化过程。
大家是不是感觉弱爆了，随着工作经验的增加，我对索引有了更深入的了解，下面就来分享下我眼中的索引，分享以问题的形式，从敲门到进门。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
