数据库内核月报

背景

MYSQL是全球最流行的数据库之一，开源易用的特点成为数据库初学者和开发者的选择。许多用户能够自行部署和管理本地 MySQL 服务，但随着业务发展不可避免会遇到了本地部署数据库的性能瓶颈，从而希望MySQL具有更高的性能、可用性和可扩展性，但是受到自有环境的物理限制难以达成。

数据库的性能是直接影响用户体验的关键因素之一。数据库的持久化存储设备（如磁盘）的性能直接影响数据库性能。为了确保数据的持久性和完整性，数据库系统必须通过I/O操作将数据写入存储设备。只有当事务提交后的数据被成功写入磁盘后，才能保证在系统崩溃或断电等故障情况下数据不会丢失。在访问数据时，由于内存容量有限，数据库需要频繁地通过I/O操作从磁盘读取所需的数据。在遇到磁盘性能性能不足导致数据库性能下降时，通过升级性能更好的磁盘，将磁盘组成磁盘阵列等方法是调优的常见手段，不过磁盘的数量和性能受单机物理环境的限制。

数据库的可用性同样是衡量用户体验的重要指标。通过将数据持久化到磁盘上，数据库能够在系统崩溃或服务器断电后重启，并从磁盘中恢复数据，从而重新提供服务。然而，在恢复期间，数据库将暂时不可用。如果磁盘发生故障导致无法访问，或者服务器故障无法重启，则可能导致数据永久丢失，使数据库彻底不可用。对于企业级数据库而言，高可用性和数据不丢失至关重要。为提升数据库的可用性，通常采用主备同步的机制，但通过网络传输数据会增加事务处理的延迟，降低数据库整体性能。

数据库的扩展性也是用户体验的重要衡量标准，单机部署的数据库其扩展能力受限于单个物理节点的存储容量和I/O吞吐量。企业数据库的数据量会随着用户量的增长膨胀至数百TB乃至PB级别，显然单机架构难以满足这种规模的需求。为提升扩展性，可将数据库部署到云盘，解决存储空间扩展的问题，但与云盘的数据传输经过网络，会增加I/O延迟，数据库性能也会降低。

数据库的性能、可用性与可扩展性三者之间相互影响，不同的数据库系统在设计时会根据具体的应用场景和需求，在这三个方面做出不同的权衡。随着各种需求的增长越来越多的企业和个人倾向于选择使用云数据库服务，以利用其在性能、可用性、可扩展性和维护便捷性方面的优势。

本文通过介绍PolarDB使用的存储技术PolarStore，来展示PolarDB如何有效地平衡了性能、可用性和可扩展性之间的矛盾。对比传统数据库部署模式，深入探讨PolarStore的工作机制及其对I/O路径优化，并基于性能、可靠性和弹性扩展能力三个维度进行全面分析分析PolarDB具有的独特优势。这将有助于读者依据自身业务特性及需求选择最为合适的数据库解决方案。

PolarDB I/O链路架构

为了便于理解PolarDB分布式存储PolarStore在数据库架构中的作用，下图在架构图中增加I/O路径的示意图。

PolarDB采用计存分离架构，将数据处理和持久化存储分别部署在独立的服务器上。在这种架构中，SQL引擎和InnoDB存储引擎位于计算节点，而数据通过自主研发的用户态文件系统PolarFS写入PolarStore。每个计算节点部署PolarSwitch服务组件，负责将文件系统的请求发往不同的存储节点。

本文从性能、可用性和扩展性三个维度分析PolarStore的I/O特性，具体如下：

性能优化。PolarStore针对InnoDB存储引擎的关键I/O路径（如Redo持久化、数据页读写）进行了深度优化。通过智能缓存、异步I/O和预读技术，显著降低了I/O延迟并提升了吞吐量。在高并发与海量数据负载场景下，相较于传统MySQL本地磁盘部署，PolarStore的吞吐量和I/O延迟都表现出色。
高可用保障。云数据库的高可用性是确保数据在服务器故障时仍可访问的关键特性。相较于传统MySQL主从复制架构，本文将进一步探讨不同故障场景下，PolarStore能够增强了数据库的容错能力，还大幅缩短了恢复RTO，确保业务连续性。
扩展性优势。PolarDB采用分布式存储架构，支持存储容量的弹性扩展和计算节点的水平扩展。通过分片、动态扩容及自动负载均衡，实现了存储扩展性；同时依托高效数据分发能力，支持动态资源调度，从而满足复杂工作负载需求。这种存储与计算解耦的设计提升了系统灵活性和成本效益。

I/O链路性能

传统方式基于本地盘部署的MySQL，MySQL常见的存储引擎是InnoDB存储引擎，PolarDB-MySQL中也是使用的InnoDB引擎。PolarDB的I/O性能优化包括InnoDB中I/O链路的优化和PolarStore I/O性能的优化，本文主要介绍PolarStore对数据库I/O的优化。细化分析InnoDB中I/O的作用对比传统本地盘部署和PolarStore的性能。

InnoDB中的I/O

InnoDB的架构图如下（图源自MySQL 官网）。InnoDB位于文件系统上层，通过文件的方式管理数据库的表，也是通过文件接口来做数据持久化。

在InnoDB引擎中对性能影响最大的I/O为 Redo 写I/O 和 Page 读写 I/O。

Redo 写I/O直接影响事务提交性能。在InnoDB存储引擎中，事务提交的持久性保障依赖于Redo日志的强制写（fsync）操作完成，该过程作为Write-Ahead Logging (WAL)机制的核心环节，Redo的写I/O直接影响事务提交性能。Buffer Pool的脏页管理机制对事务性能同样构成关键影响。数据库通过LRU算法维护缓冲池中的数据页，事务对数据页的修改会生成脏页。后台刷脏线程通过异步方式将脏页刷新到磁盘数据文件，若出现I/O延迟高导致脏页积聚，将引发以下连锁反应：首先，Checkpoint机制无法正常推进，导致Redo日志文件空间无法及时重用；其次，Redo日志缓冲区因缺乏可用空间而触发频繁的强制同步写入，最终形成”脏页堆积→Checkpoint停滞→Redo日志阻塞→事务提交延迟”的恶性循环。因此Redo 和Page的写I/O都对事务提交性能至关重要。
Page Double Write保证原子性。在持久化存储介质中，不同存储设备对写入操作的原子性支持存在显著差异。例如，SSD支持4KB粒度的原子写入，而HDD仅保证512B原子性。InnoDB采用16KB页作为存储单元，当事务对页内数据进行局部修改时，若直接写入原始数据位置，可能因存储介质的原子性不足导致页结构损坏。具体而言，16KB页的写入若中途中断，将产生部分写入问题，破坏原有数据的完整性。InnoDB引入Doublewrite Buffer机制，通过将修改页的完整副本先持久化至预分配的双写区域，待该副本稳定落盘后，再异步将修改页写入原始位置。这种双写策略确保崩溃恢复时，可通过双写区域的完整页副本重建逻辑一致的数据内容。但双写的机制会增加写I/O的压力，进一步加大了I/O性能对性能的影响。
Page 读I/O影响数据库查询修改。数据库系统中，数据Page的访问与解析是核心I/O操作的关键路径，事务提交更新Page也需要保证Page在Buffer Pool中。当执行页级操作时，系统从Buffer Pool中查找Page，若不在Buffer Pool未命中，则需触发读I/O，从存储设备中读取该页，当数据量越大时，Buffer Pool有限的空间命中的概率越低，产生读I/O越多，读I/O的性能也直接反馈在数据库查询性能中，也影响了事务的提交性能，因此Page读I/O在数据库OLTP场景下至关重要。

PolarStore的I/O优化

PolarFS是用户态文件系统，PolarStore提供逻辑卷。PolarFS深度和DB数据特点结合，为不同数据特点提供了高度定制化的优化，通过IO打标的方式将数据特点传递给底层的分布式存储。

写路径上，PolarFS能够将一个文件条带化的分散在多个存储节点上，由PolarSwitch 服务经过高速RDMA网络发送到对应的leader上，leader通过parallal raft协议和follower同步数据。整体的延迟包括PolarFS到Polarswitch软件栈开销，Polarswitch经过RDMA发送到存储节点的网络延迟，存储节点leader将数据通过RDMA同步到follower中，同时将数据写入高速介质Optane/AliSCM中，将数据成功消息返回给Polarswitch再到PolarFS，以上即可完成一次IO。ChunkServer会后台异步的将数据从高速介质Optane刷新到NVMe中，Optane作为写Cache做写加速，未来还有更加快速的设备AliSCM，持久化内存设备做写Cache加速。原理如图所示，每个写IO持久化到Journal file中即可返回，异步的将数据刷新到NVMe中释放高速介质的空间。PolarStore软件和RDMA技术相结合，系统运行过程实现内存零拷贝。
PolarStore提供请求均为原子写，InnoDB中无需DoubleWrite Buffer，消除数据崩溃一致性保证带来的double write开销。
读路径上，PolarStore利用存储节点上内存，构建了一个数TB的弹性内存池，根据PolarFS的IO打标，将数据库中的Page，cache在内存中，读请求能够直接从内存中获取直接返回给DB，仅仅需要经过高速RDMA网络和内存访问的延迟，同时根据数据I/O打标、三副本中仅需保留一份数据，以及合理的Cache淘汰策略，能够将最重要的数据Cache在弹性内存池中，大幅度提升关键数据的Cache命中率。

MySQL直连本地盘，在低压力下写I/O延迟有优势，延迟随着压力增大线性增加，本地盘的IOPS有限。

PolarStore的写路径全链路无内存Copy，软件栈很薄，经由RDMA高速网络写入高速存储介质中，低压力下写延迟接近本地盘，读路径经过高速网络直接从弹性内存中访问，延迟优于本地盘。PolarStore有自动负载均能的能力，随着压力的增加，I/O延迟相对稳定，PolarStore的IOPS可弹性空间非常大。

可用性

数据库的可用性包括业务连续性和数据可靠性两方面。单机本地盘部署MySQL当发生数据库故障时，在恢复期间业务中断，若本地盘发生不可恢复的故障，则数据丢失，这对企业级数据库来说是不可容忍的，提升数据库可用性的传统方式为采用主备同步的机制。

主备同步的机制可分为异步复制(Asynchronous Replication)和半同步复制(Semi-Synchronous Replication)，异步复制的过程为主库将事务写入 Binlog，备库异步读Binlog重放，特点是主库提交后，备库同步有延迟，若主库在此期间故障，则数据可能不一致；半同步机制的过程为主库写入时需要等一个备库确认后才能完成事务提交，影响性能。相同的数据可靠性情况下，本文主要对比半同步机制。

PolarDB是计存分离的架构，存储采用分布式的架构，支持一写多读。计存分离架构中，故障可能发生在计算节点，也可能发生在存储节点。

当存储节点发生故障时，PolarStore上维护三副本，任一副本故障都不影响可用性。PolarStore的三副本分别位于不同的磁盘不同的主机，磁盘和主机故障业务可用性不受影响。当故障后会自动恢复三副本，业务没有任何感知，数据恢复过程中可有多个服务并发进行恢复，故障恢复期间，新增数据仍然有三副本，数据风险极低。一个数据库的逻辑卷按照10GB的Chunk粒度分散在不同的主机上，单节点发生故障时，需要恢复的数据量不是一个数据库集群的全部数据，而是小部分数据，恢复三副本的速度更快。PolarStore合理的数据分布和并发恢复机制能够大大降低数据丢失的风险，可用性非常高，产品上线以来未发生过由于机器故障导致的数据丢失问题。

PolarStore支持PolarDB实现自动选主。故障发生在计算节点时，基于polarstore提供的voting disk能力实现自动切主，内核自动切换角色。老RW故障后，数据库内核自治，无需管控参与，PolarStore提供抢锁的机制选主，故障秒级切换，自动恢复服务。传统主备MySQL服务需要管控参与，主备切换时需等待Slave上Binlog追平，修改Master和Slave角色，恢复时间长。

PolarDB还支持跨机房容灾和跨地区容灾的能力，为用户提供更高级别的数据保护。

I/O 延迟和IOPS对性能影响测试

根据前文的分析，我们分以下几种性能测试场景进行对比。

测试规格：均为8 core 64GB。

测试场景：sysbench oltp_read_only、oltp_write_only。

数据量：360GB和20GB两种场景，360GB模拟数据库I/O bound场景，20GB为模拟Page在Buffer Pool中全部命中，I/O性能直接影响Redo持久化的性能。

对比实例：MySQL on Disk、MySQL on Disk 打开半同步、PolarDB。

oltp_read_only，数据量为360GB，测试数据库纯读的性能，PolarStore的读延迟大大优于本地盘，并且IOPS也显著有优势的情况下，不同压力下，PolarDB的性能都优于本地盘部署。read only场景不对比数据量为20G的场景，20G的数据量在测试规格下数据全部在Buffer Pool中命中后，测试和I/O没有关系，在本文对比测试场景中，DB自身性能可认为相差不多。下图为随着压力增加，MySQL on Disk和PolarDB场景下的性能对比，由于大压力和低压力下数值差异较大，同一个图表中不易观察，分为两个图表展示，图a为低压力下，随着压力增加（thread数量增加）数据库性能的变化，图b为高压力下测过规格达到瓶颈，数据库的性能不受压力增加而变化。

oltp_write_only，数据量为360GB，测试数据库写入的性能，数据写入的过程中，对Page修改时，由于Buffer Pool空间有限，多数是读改写，因此Page的读性能也较为重要，PolarDB不同压力下性能表现都优于本地盘，压力越大，优势越明显。

oltp_write_only，数据量为20GB，该数据量能保证所有的Page都能Cache在Buffer Pool中，系统中仅有Redo 写I/O影响性能。实际业务场景中数据量极少出现小于Buffer Pool的场景，本文实验为更直观的展示数据库主备半同步的影响测试。在低压力下，本地盘凭借直连存储设备的优势，性能略好与PolarDB，随着压力的增加，本地盘达到IOPS瓶颈时，PolarDB性能优于本地盘。使用主备半同步机制部署MySQL，数据同步需要跨网络同步，事务需要等待备库同步确认后事务才能完成提交，数据库性能整体有大幅下降，可以看出在相同数据可靠性的情况下，PolarDB的性能高于本地盘主备同步的MySQL。文中测试PolarStore使用Optane设备做写加速，若替换为AliSCM设备，写入延迟与本地盘持平，整体性能会有进一步提升。

数据库的数据量越大，即数据规模和buffer pool 的容量比率越大，I/O性能对数据库影响越大，上面测试中优化比例会更明显。

弹性扩展性

数据库的扩展性包括计算能力的扩展和存储能力的扩展，当用户数据量基本不变，但需要大量的链接访问或修改时，需要提升数据库的计算资源，当数据量不断变化，连接访问和IOPS高时，则需要提升存储能力。

本地盘部署MySQL的扩展性受限于物理磁盘容量和吞吐量，计算资源的扩展性也受限于本机的资源情况，当部署主机无法满足时，较难扩展。为提升扩展性，可将MySQL部署到云盘，能够缓解存储空间扩展的问题，数据库和云盘依赖网络进行数据传输，无法做到计算存储一体化部署，跨级网络延迟高，MySQL的整体性能大幅下降。

PolarDB存储空间弹性扩展

PolarDB采用计算与存储分离的分布式架构，其存储层为PolarStore系统，提供弹性逻辑卷服务。逻辑卷以固定粒度（10GB）的Chunk为分配单元，拥有高扩展性与动态伸缩能力。PolarStore逻辑卷系统支持水平扩展至PB级存储规模，可满足超大规模数据集的存储需求。

系统通过监控与自动化资源调度机制实现非中断式扩展。当逻辑卷使用率超过阈值时，系统自动触发扩容流程：向逻辑卷追加新的Chunk，并通过PolarFS分布式文件系统完成空间注册与映射，使新增存储立即对数据库引擎开放。此过程确保数据库实例在数据文件扩展、表空间增长或新表创建时无缝利用新增容量，全程无服务中断。为数据库混合负载场景提供线性扩展能力，在数据量持续增长时维持数据库服务的高可用性与性能稳定性。

PolarDB数据库集群的存储架构拓扑图清晰呈现了其分布式存储系统的物理部署形态。PolarStore实现了存储节点的无服务规模限制特性。该分布式存储系统依托横向扩展架构设计，可支持存储容量的弹性线性扩展，最大存储空间可扩展至PB量级，满足海量数据存储的弹性需求，确保数据库系统在应对数据爆炸式增长时仍能保持高效的I/O吞吐性能和数据持久性保障。

基于PolarStore的逻辑卷原理能够支持秒级快照、可写快照等功能，对于超大数据量的存储支持秒级快照也是值得详细分析的技术，请关注本系列后续文章。

PolarDB计算资源弹性扩展

PolarDB支持一写多读，基于物理复制和PolarStore分布式存储系统实现全局数据强一致性，扩展只读节点动态挂载到共享存储上。RO节点分钟级水平扩展，无需数据Copy开销。每个RO节点都能享受到PolarStore的优化能力，EMP能够同时加速所有的RW和RO节点。

总结

在复杂的业务场景中，数据库的性能、可用性与扩展性需求各异。深入探究技术原理，不仅有助于精准选择最适合的数据库产品，更能为业务发展提供坚实支撑。然而，数据库的评价维度远不止这三大衡量标准，易用性、快照与备份能力、成本效益等同样至关重要。数据库技术以服务业务为核心，其特性的重要性排序权衡，赋予了数据库工作的独特价值和乐趣。

数据库内核月报－ 2025 / 04

兼顾高性能 & 高可用：持续演进的 PolarDB-MySQL 存储优化技术

背景