为无为，事无事，味无味。

‌undo日志和版本链并不直接构成Read View，但它们共同在InnoDB的MVCC机制中实现了数据的版本管理和可见性判断‌。undo日志和版本链共同记录了数据的历史版本，并通过roll_pointer指针将这些版本连接起来。而Read View则用于在执行查询操作时判断数据版本的可见性。这三者协同工作，实现了InnoDB的MVCC机制，从而提高了数据库的并发性能和一致性。

MySQL中单独SELECT语句的事务行为与MVCC机制解析 在MySQL中，SELECT语句的事务行为取决于是否开启显式事务和隔离级别设置。默认自动提交模式下，单独SELECT不会开启显式事务，也不分配事务ID，通常直接读取最新数据；而在显式事务中，SELECT会共享当前事务ID，MVCC通过事务ID、undo日志链和ReadView机制实现数据隔离。不同版本MySQL的事务ID分配规则存在差异：5.1-5.5版本仅写操作分配事务ID，5.7+版本所有显式事务（包括SELECT）都会分配ID。MVCC通过

本文分析了MySQL InnoDB引擎中MVCC机制的核心函数changes_visible的实现原理，涵盖5.7、8.0和8.4三个版本。该函数通过比较数据行的事务ID与当前事务的ReadView（包含活跃事务ID集合、上下限事务ID）来判断数据可见性。关键判断逻辑包括：当事务ID小于ReadView上限或为创建者ID时可见；大于等于下限时不可见；处于中间范围时需检查活跃事务列表。各版本实现位置不同但逻辑一致，8.4版本通过布隆过滤器等优化提升了高并发下的性能。该函数是MVCC实现读写并发的核心技术，直接

MySQL的MVCC机制通过隐藏字段(DB_TRX_ID、DB_ROLL_PTR)、Undo日志、ReadView、事务系统和Purge线程五大核心组件协同工作，实现高效的多版本并发控制。其中隐藏字段记录事务信息和版本链指针，Undo日志存储历史版本，ReadView定义事务可见范围，事务系统管理事务生命周期，Purge线程负责垃圾回收。这种机制使MySQL能够支持高并发事务，实现不同隔离级别下的一致性读，同时避免数据冲突和存储膨胀问题，是数据库事务处理的核心基础。

MVCC（多版本并发控制）是InnoDB实现高并发的核心技术，通过维护数据行的多个版本来实现读-写操作的非阻塞执行。其核心机制包括： 版本链：通过隐藏字段trx_id和roll_pointer构建数据修改历史链 ReadView：事务快照，包含creator_trx_id、活跃事务列表等，用于判断版本可见性 两种读操作：快照读（不加锁，读取历史版本）和当前读（加锁，读取最新版本） 在不同隔离级别下： READ COMMITTED：每次查询生成新ReadView，可能读到其他事务已提交的修改 REPEATAB

Uber技术团队从PostgreSQL迁移到MySQL的技术分析显示：PostgreSQL在写入效率（不可变行设计导致写入放大）、复制带宽需求（WAL日志冗长）和版本升级（需长时间停机）方面存在明显不足。相比之下，MySQL的二级索引指向主键设计、逻辑复制机制和线程每连接模型在写入性能、复制效率和并发处理上更具优势。最终Uber将大部分数据库迁移至基于MySQL的Schemaless层，仅保留少量PostgreSQL实例。这一决策显著提升了系统的写入效率、复制可靠性和运维便利性。

PostgreSQL的MVCC实现存在严重设计缺陷：采用追加式存储导致存储膨胀，每次更新都复制整行数据而非增量变更；版本链采用旧到新顺序需要遍历长链；自动清理机制效率低下，常因长事务阻塞形成恶性循环。这些问题导致I/O开销增加、性能下降和云成本上升，尤其在高写入负载下表现更差。相比Oracle、MySQL等使用增量存储的数据库，PostgreSQL的MVCC设计在二级索引维护和存储空间回收方面存在明显劣势。尽管存在这些缺陷，PostgreSQL仍是功能丰富的可靠数据库，但需精细调优来缓解问题。

摘要： 卡耐基梅隆大学的研究团队在OtterTune博客中指出，PostgreSQL的多版本并发控制(MVCC)实现存在严重缺陷，是其最糟糕的设计部分。PostgreSQL采用追加式存储方式，每次更新都复制整行数据而非仅存储变更部分，导致存储膨胀和性能下降。此外，其版本链采用旧到新(O2N)顺序，需要遍历长链或维护冗余索引条目，而自动清理机制(autovacuum)难以有效回收空间，常因长事务阻塞形成恶性循环。相比Oracle、MySQL等使用增量存储的数据库，PostgreSQL的MVCC设计增加了I/O

Uber工程团队2016年从PostgreSQL迁移到MySQL的核心原因包括：PostgreSQL在写入操作、数据复制和版本升级方面存在显著瓶颈。其基于CTID指针的存储架构导致写入放大效应，次要索引更新产生冗余磁盘操作；物理复制机制造成跨数据中心带宽压力；MVCC实现限制副本读取性能；版本升级需停机数小时。相比之下，MySQL的InnoDB引擎通过主键引用次要索引，显著减少写入放大；逻辑复制更节省带宽；连接线程模型优于PostgreSQL的进程模型；支持在线版本升级。这些特性使MySQL更适合Uber快

以下是 PostgreSQL（Postgres）与 MySQL 的全方位对比，涵盖 定位、功能特性、性能、适用场景、生态工具 等关键维度，帮助根据业务需求选择合适的数据库。一、基础定位许可证 LicenseMySQL 社区版采用 GPL 许可证。Postgres 发布在 PostgreSQL 许可下，是一种类似于 BSD 或 MIT 的自由开源许可。即便 MySQL 采用了 GPL，仍有人担心 MySQL 归 Oracle 所有，这也是为什么 MariaDB 从 MySQL 分叉出来。

2025年MySQL新版发布与技术解析 2025年7月22日，MySQL正式发布9.4.0创新版本，同期推出8.4.6 LTS长期支持版和8.0.43版本。9.4.0版本主要带来四大更新：1）新增HeatWave GenAI协作优化；2）支持RHEL10等新操作系统；3）深层性能与架构优化；4）字符集与排序规则改进。值得注意的是，该版本将NONE排序规则优先级降至最低，并修复了非ASCII标识符处理问题。 版本策略上，创新版支持周期仅3个月，建议生产环境选择8.4 LTS版本。性能测试显示，9.4.0在写入

本文探讨了MySQL主从复制环境下的"脏读"问题本质。在RC隔离级别下，真正的脏读（读取未提交数据）不会发生，但主从异步复制延迟会导致从库读取到旧数据，这种现象被部分人错误地称为"脏读"。文章详细分析了MySQL 5.6至9.0各版本中该问题的表现差异及解决方案：包括半同步复制、并行复制、组复制等技术优化，最终建议关键业务查询走主库、使用MySQL 8.0+版本并配合监控机制。核心结论指出：主从环境下的"脏读"实际上是复制延迟导致的数据不一致问题，

本文系统梳理了MySQL数据库的性能优化与分库分表方案。核心建议包括：单表记录不超过500万行，单库表数量控制在1万以内；通过索引优化、字段精简等手段提升性能；对于亿级数据场景，推荐采用分库分表策略。文章详细对比了垂直/水平拆分方案，分析了中间件选型要点（ShardingSphere vs MyCAT），并提供了MySQL关键参数（如innodb_buffer_pool_size）和Linux系统（如IO调度器）的优化配置建议。特别强调分库分表需结合业务特征，在单表超500万行或2GB时实施，同时需解决分布

这个问题目前在项目上很少碰到，这次也是出于好奇拿来学习探讨，下面总结下这个问题出现的场景：1.代码中存在较大事务，超过 binlog_cache_size，高并发下生成大量临时文件，占满 tmpdir。2.代码在事务执行过程中碰到 tmpdir 磁盘已满错误，未处理异常执行回滚，后续执行 Commit 导致。3.代码在事务执行过程中碰到 tmpdir 磁盘已满错误，未处理异常执行回滚，继续执行碰到嵌套事务，引发 Commit 导致。也许很多童鞋想到可以加大binlog_cache_size。

2024年4月30日刚刚发布长期稳定版本MySQL 8.4 版本(LTS)，就在短短3个月内，就被发现重大bug，虽然一般不会超过8000张表，也不会触发这个bug。但是这也从另一面证明了新出来的软件版本不一定稳定，还是得有人去趟坑，社区活跃性很重要，线上生产环境不要轻易“吃螃蟹”尝鲜。

不过很不幸的是MySQL5.7频频被爆出Table cache 导致 MySQL 崩溃。不过可惜啊，就在今年2024年07月MySQL8.0、8.4、MySQL9.0都还爆出数据库下表的数量超过1万张表时，触发重大bug Crash。MySQL 8.0.38,MySQL 8.4.1,MySQL 9.0.0三个版本中被确认，这个问题在 >= 8.0.38 版本中存在，包括 8.4.1 和 9.0.0。

MySQL经常会遇到Too many open files，MySQL上的open_files_limit和OS层面上设置的open file limit有什么关系？源码中也会看到不同的数据结构，TABLE, TABLE_SHARE，跟表是什么关系？MySQL flush tables又做了些什么，接下来梳理一下。

除了字典元素本生，字典表本生也有自己的属性，比如字段/表名等等，这些属性都放到了字典表定义这个类里面，注意这也是单例，下面是和它有关的继承关系，只截取一部分。比如这里Tables类，里面就要字段的定义如下除了上面提到的字典元素的类，字典表属性的类，建立视图还有一个类，这里简单看看。

数据库优化有四个维度，分别是：硬件升级、系统配置、表结构设计、SQL语句及索引。那优化的成本和效果分别如下：优化成本：硬件升级>系统配置>表结构设计>SQL语句及索引。优化效果：硬件升级由上图可以看出性价比排名也是硬件升级。影响/复杂度：硬件升级>系统配置>表结构设计>SQL语句及索引。其中，硬件升级>系统配置>表结构设计 又统称为“架构设计”。

Optimizing SELECT Statements先看官网MySQL5.7和MySQL8.4。MySQL8.4增加了三条select优化，如上图红色方框选择的3条。

在故障排查过程中，我们需要了解mysql的状态信息，如：mysqld启动时长，连接数、QPS、TPS、读写比、DQL/DML执行次数、慢查询次数、锁等待、ibf命中率等等状态统计信息，以便于根据当前mysql运行状态进行分析判断和调整优化。需要查询这些运行状态信息可以通过下面三种方式：1. 使用命令行工具：可以通过在命令行中执行`mysqladmin status`命令来查看MySQL的状态。该命令会显示MySQL的版本信息、运行时间、并发连接数等。2. 使用MySQL客户端：可以通过登录MySQ

前面有提到SHOW [FULL] PROCESSLIST命令，在排查一些MySQL的问题，会经常用到 show processlist这个命令。show processlist 是显示用户正在运行的线程，需要注意的是，除了 root 用户能看到所有正在运行的线程外，其他用户都只能看到自己正在运行的线程，看不到其它用户正在运行的线程。除非单独个这个用户赋予了PROCESS 权限。

为了排查和定位MySQL故障，除了要上面的监控之外，还需要了解一些常用的故障排查命令，他们可以帮助我们了解数据库的运行情况，定位问题。在这里主要整理：SHOW FULL PROCESSLIST，SHOW STATUS、SHOW VARIABLES等。

科普文：软件架构数据库系列之【MySQL的Prometheus监控：MySQL Exporter】-优快云博客科普文：软件架构数据库系列之【MySQL5.7的系统表梳理】-优快云博客前面提到过MySQL的监控，监控数据都是来MySQL自带的系统表。对于系统和状态变量，变量的作用域（变量作用域）为全局、会话或两者兼而有之。有关设置和使用选项和变量的详细信息，请参阅官方文档：https://dev.mysql.com/doc/refman/8.4/en/server-option-variable-refe

关于numa和其他cpu架构，可以看看上面的文章。在数据库系统中，OLTP（在线事务处理）数据库通常面临着高并发和高吞吐量的要求。在某些情况下，可以通过启用 NUMA（非统一内存访问）来改善 OLTP 数据库的性能。NUMA 系统的内存分配策略与传统的对称多处理 (SMP) 系统不同。在 SMP 系统中，所有 CPU 核心都可以访问同一个共享的内存。而在 NUMA 系统中，内存访问被限制在特定的节点（或节点集合），这取决于 CPU 核心的物理位置。

CheckPoint是MySQL的WAL和Redolog的一个优化技术。‌‌是一种优化技术，主要用于将缓存池中的脏页刷新到磁盘，确保数据的持久性和一致性。CHECKPOINT机制通过记录一个特定的时间点（称为检查点），在该时间点上，所有在此之前的修改都会被刷新到磁盘上，从而在系统崩溃时能够快速恢复数据。

前面我们把innodb的存储结构进行了拆分，分别进行了描述，在上一篇“科普文：软件架构数据库系列之【MySQL/innodb刷脏页】” 的文档中对刷脏页的后台线程做了概叙，这里就对后台线程做一个补充。InnoDB 通过独立的线程将Buffer Pool中的脏页刷入存储中。这些线程称作Page Cleaner. Page Cleaner的线程数量通过系统参数--innodb-page-cleaners控制。刷脏是以Buffer Pool实例为单位进行的。一个Buffer Pool实例同时只能有一个Pa

从脏页数据的产生、到刷脏页数据到磁盘这个过程基本涵盖了MySQL/innodb的内存、磁盘、后台线程三大构件。了解这个过程，可以让我们更好的理解innodb引擎下数据库的运行原理，为提升数据库性能提供理论依据。因为整个过程涉及到的技术点很多，我们前面已经拆分了进行详细描述，所以在这里不再赘述，会在后面SQL执行过程、磁盘数据加载过程、加锁过程、内存数据刷新过程中再统一描述。总之，InnoDB通过刷脏页的机制来保证数据的一致性/持久性和提高数据库性能。了解脏页的概念和刷脏策略对于数据库管理员和开发人员

FLUSH TABLES是 MySQL 的一个命令，用于关闭所有打开的表、清除表缓存并创建新的表缓存。这个命令在执行期间不允许对表进行修改，因为它会关闭所有打开的表，从而使得当前所有的数据库操作无法进行。如果你需要进行表的修改，应该在执行FLUSH TABLES命令之前完成你的修改工作。如果你在执行FLUSH TABLES时需要进行修改，你可以将修改操作在执行FLUSH TABLES命令前执行。

‌InnoDB的Buffer Pool具有以下四大特性‌：‌Change Buffer‌：​ Change Buffer是InnoDB存储引擎中的一个特殊数据结构，用于缓存对不在buffer pool中的二级索引页所做的修改。这些修改可能来自INSERT、UPDATE或DELETE操作（DML）。当这些页被其他读操作加载到buffer pool时，Change Buffer中的修改会被合并到这些页中，从而减少对磁盘的随机I/O操作‌。‌Double Write‌：Double Write机制用于确保I

innodb内存管理四剑客：LRU算法+Free_list、LRU_list、Flush List。在前面梳理innodb的内存结构和磁盘结构时，关于innodb的内存管理都是做了描述。今天单独把这一部分拿出来，也是为了更好的理解innodb的内存结构及其运行机制，为后面的SQL语句执行过程，磁盘数据如何加载到内存、内存的脏数据如何刷新到磁盘做准备。

MySQL使用采样统计的方法，会选出N个数据页，每个数据页大小16kb，接着统计选出来的数据页上的不同值就会得到一个平均值，用平均值在乘以索引的页面数得到的结果就是这个索引的基数。但别误解force index的使用方法，之前在代码中看到这样一个案例，给查询列使用了函数操作导致使用不上索引，然后这哥们就直接使用force index，肯定不行的哈！优化器选择了错误的索引，只用force index来快速矫正，再通过优化SQL语句来引导优化器选择正确的索引，最暴力的手法是直接删除误选的索引。

页是InnoDB存取数据的基本单位，默认页大小是16KB，InnoDB为了不同的目的设计了很多不同类型的页，本文重点分析了存放用户记录的索引页。页的头尾部分File Header和File Trailer是所有页都有的一个通用结构，它们记录了页的一些通用状态信息，和Checksum用来验证页的完整性。Page Header是索引页特有的结构，它记录了页内用户记录相关的状态信息。User Records部分用来存放用户记录。

了解 MySQL 的 ROW_FORMAT 默认值及其影响对于优化数据库性能和存储至关重要。选择合适的 ROW_FORMAT 可以提高查询效率，减少存储需求，并根据具体需求灵活调整。通过本文的代码示例和图表，希望读者能够更深入地理解 ROW_FORMAT 的作用和选择依据。在实际应用中，建议根据数据的特点和查询需求，合理选择 ROW_FORMAT。同时，定期监控和评估数据库性能，以确保数据存储和查询的最优化。

c. 假设某个字符集中最多需要W个字节表示一个字符，该列允许存储最多M个字符，实际占用字节数为L，如果该变长字段允许存储的最大字节数（M * W）超过255个字节，并且真实占用的字节数L 超过127个字节，则使用2 字节来表示真实数据占用的字节数，否则用一个字节。的方式记录长度的（涉及大端、小端存储问题），如03 02 01代表的是第一个变长字段长度为1，第二个变长字段长度为2，第三个变长字段长度为3.至于变长字段怎么确定的序列，是根据创建的先后来规定的，即第一个创建的变长字段为第一个变长字段。

我们先看一下官网，从目录可以看到”MySQL 8.4 Reference Manual / Optimization / Optimization and Indexes“索引放在优化目录下面，也就是索引是用来提升性能的。MySQL 选择B+树作为索引结构的主要原因是B+树的以下特性；检查索引列是否合理

Index Merge是通过同时扫描多个索引，再将数据合并到一起的访问方式。只适用于单表有多个索引可选的情况，不支持用多表场景。合并数据的种类有：unions，intersections。Inerge-Merge的使用限制： ● 如果where条件中有复杂的AND/OR嵌套，可能选不中较优的计划。

PolarDB 在线上支持了非常多的大表实例, 10+TB 的大表其实非常多, 我也看到之前很多大厂 DBA 朋友的实际分享, 比如微博6B(billion) 哥, 讲述微博的某一张单表 60 亿行数据等等, NineData 创始人斗佛公众号大圣聊数据库讲述海外类似微信业务单表几十亿都是运行的挺好的. 所以其实如果业务表结构设计合理, 其实大表是完全没问题的, 不用被现在的数据库厂商强行引导.其实 Btree 是一个非常扁平的 Tree, 绝大部分 Btree 不超过 4 层的, 我们看一下实际情况。

InnoDB的read-ahead，在触发的时候，针对下一个extent，对每一个page提交了异步IO请求，也就是增加了IO request次数，虽然Native AIO和disk会有针对性合并IO，但仍然非常有限，而Oracle每次提交合并多个连续数据块的IO请求，能够更好利用disk的吞吐能力。在高并发的场景下，sql响应时间主要取决于同步IO请求的时间，而InnoDB的预读通常不会触发，就算触发，更多的是预热(warmup)的效果，并不会对系统带来非常大的收益，对rt的影响也非常小。

在前面几期月报我们介绍了undo log、redo log以及InnoDB如何崩溃恢复来实现数据ACID的相关知识。本期我们介绍另外一种重要的数据变更日志，也就是InnoDB change buffer。Change buffer的主要目的是将对二级索引的数据操作缓存下来，以此减少二级索引的随机IO，并达到操作合并的效果。