本文将介绍传统数据库在处理大表时所采用的解决方案并分析PolarDB MySQL版体系下针对这些大表的优化处理方法。
背景信息
在业务架构设计中，数据库模型设计是至关重要的一环。由于单机计算和存储能力的限制，许多业务架构师不得不考虑对大表进行拆分，通过中间件或其他手段实现分库分表，以便提升资源的扩展能力。因此，在MySQL生态中流传着一个经验法则：单表行数建议不要超过500万行。一般来说，分库分表方案解决了以下几个主要问题：本地存储不足、计算能力不足以及大表的运维复杂性。
随着数据量的日益增长，运维团队为了确保业务的稳定性，不得不开始考虑数据拆分的问题。由于分库分表带来的兼容性挑战，业务代码也需进行相应的修改，这意味着开发团队需要参与架构改造，并重写SQL语句以适应新的分库分表结构。业务团队往往将重点放在业务发展上，在此期间难以抽出精力进行系统的拆分。这导致拆分工作只能不断推迟，直到最终不得不执行。在此期间，整体系统的稳定性始终面临风险。
在MySQL生态中，通常建议单表的行数不超过500万行，这一准则背后有其深厚的历史背景。这一限制主要源于性能优化和管理维护的考虑。从资源的角度来看，早期服务器的IO能力较低，较大的单表会增加B-tree索引的高度，进而导致IO性能问题。同时，磁盘容量也相对有限。因此，需要考虑存储上限和备份空间的问题。从运维角度来看，旧版本的MySQL（5.5之前）基本不支持在线DDL。在对大表进行维护时，这可能会导致业务出现异常。
本地存储能力优化
海量弹性存储空间
在许多业务快速发展的阶段，面对海量数据的存储需求，企业往往会考虑进行数据拆分。然而，这种考虑并不是因为计算能力遇到瓶颈，更多时候是因为单一集群的存储容量达到了上限。最初设计时，如果未能充分考虑数据的海量存储方式，或者是在业务逻辑中无法进行有效的清理或归档，那么就可能面临存储瓶颈。
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倍。
TPC-C是业界常用的一套Benchmark，由TPC委员会制定发布，用于评测数据库的联机交易处理（偏向OLTP）能力。
表文件扩展优化
随着数据的不断写入，数据表文件的扩展是不可避免的。高频的数据插入会增加表空间扩展的频率。在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是一个跨平台且支持多线程的模块化基准测试工具，用于评估系统在运行高负载的数据库时相关核心参数的性能表现。
本文中TPC-C的实现基于TPC-C的基准测试，并不能与已发布的TPC-C基准测试结果相比较，本文中的测试并不符合TPC-C基准测试的所有要求。
作为对照，我们分别使用Sysbench工具向PolarDB MySQL版插入400亿行数据（10 TB）和40亿行数据（1 TB）、500万行数据（125 GB）的测试实验。整体来看，在高并发场景下，单个大表的性能与单个小表的性能基本相当。此外，真实生产环境中不会像压测场景出现如此密集的写入导致脏页一直维持在非常高的水位。完全可以承载一般业务流量。
