PolarDB MySQL计算能力优化

在传统MySQL数据库架构设计中，由于早期服务器的I/O能力和存储空间受到限制，加之MySQL 5.5之前缺乏在线DDL特性，对大表进行维护时可能会导致业务异常。因此，在MySQL生态中形成了“单表建议不超过500万行”的实践准则。该准则主要用于规避大表所带来的性能下降和运维复杂性等问题。

为了解决单表过大的问题，许多业务架构师采用了分库分表方案，通过拆分数据以扩展存储和计算能力，但这显著增加了业务复杂度：需要改造SQL逻辑、维护路由规则，且拆分过程容易影响系统稳定性。

PolarDB MySQL版集群采用了共享分布式存储架构，已支持单表存储10 TB级数据或超10亿行记录，使得在多数场景下无需进行数据拆分。与单表相比，分库分表会带来显著的复杂性提升，因此，在非必要情况下，不应过早进行过度优化。

本地存储能力优化

海量弹性存储空间

在许多业务快速发展的阶段，面对海量数据的存储需求，企业往往会考虑进行数据拆分。然而，这种考虑并不是因为计算能力遇到瓶颈，更多时候是因为单一集群的存储容量达到了上限。最初设计时，如果未能充分考虑数据的海量存储方式，或者是在业务逻辑中无法进行有效的清理或归档，那么就可能面临存储瓶颈。

PolarDB MySQL版采用了计算存储分离和共享分布式存储架构。与传统数据库MySQL相比，PolarDB MySQL版的分布式存储设计使其集群最大支持500 TB的存储空间。PolarDB MySQL版的存储架构由一组通过RDMA硬件连接的Chunk Server（采用PFS技术）构成，为上层提供块设备接口。计算节点通过RDMA网络将存储挂载到计算节点中，底层的Chunk对计算过程完全透明。

这一近乎海量的存储空间，使您不用再为磁盘容量限制和扩缩容问题苦恼，只需专注于业务的需求设计。无需进行复杂的数据拆分（如分库分表），这大大降低了业务系统的复杂程度。

计算能力优化

索引并发控制的优化

限制单集群性能的一个主要因素是大表性能问题。为了有效解决这一问题，PolarDB MySQL版进行了深入的探索和验证。针对大表的插入场景的痛点，仔细研究了各个模块机制中的瓶颈，并进行了相应的优化。经过基准测试和实践业务场景的验证，实现了最高可达10倍的性能提升。

PolarDB MySQL版对单集群的索引大锁进行了优化，创新性地引入了支持并发分裂的Polar Index，从而显著降低了大量并发访问时的冲突开销。在公有云线上业务的实际场景中，性能提升达到了3倍，而在高并发TPC-C场景下，性能更是提升了11倍。

表文件扩展优化

随着数据的不断写入，数据表文件的扩展是不可避免的。高频的数据插入会增加表空间扩展的频率。在MySQL中，表空间的扩展是一个比较消耗系统资源的操作，因此，高频的扩展操作会直接影响事务的执行性能。为优化大表插入场景中的文件扩展开销，PolarDB MySQL版基于自研的分布式文件系统，在表文件扩展过程中，减少对文件系统元信息的修改。这一设计使得文件扩展时锁的开销不再成为瓶颈，从而显著提升了PolarDB MySQL版在大批量数据写入场景下的性能。

Redo日志写入优化

高负载的插入操作必然会产生大量的Redo日志。为了确保事务的持久性，事务必须在所有Redo日志成功写入磁盘后才能返回。因此，Redo日志的写入延迟和吞吐量直接影响着数据库的性能。PolarDB MySQL版创新性地推出了Redo并行写入机制，有效地解决了大表日志落盘的痛点。目前，Redo日志的最高吞吐量已达到4 GB/s，而单集群的IO吞吐极限更是高达5.2 GB/s。

逻辑预读、IO调度、并行二级索引插入优化

整体而言，针对云上数据库的痛点（结合线上经验与系统实验），PolarDB MySQL版在单集群处理大表时的性能能够满足绝大多数业务需求。

性能测试

作为对照，我们分别使用Sysbench工具向PolarDB MySQL版插入400亿行数据（10 TB）和40亿行数据（1 TB）、500万行数据（125 GB）的测试实验。整体来看，在高并发场景下，单个大表的性能与单个小表的性能基本相当。此外，真实生产环境中不会像压测场景出现如此密集的写入导致脏页一直维持在非常高的水位。完全可以承载一般业务流量。