先聊个真事。上个月帮一个做在线教育的朋友看数据库他们的业务库已经涨到接近 9TB主从复制延迟动不动就飙到十几秒每天凌晨的大查询和备份任务挤在一起直接把主库 IO 打满。他问我该不该上一个分布式中间件做分库分表我劝他先别急——很多团队在这个阶段其实不是缺分库分表的能力而是缺一个真正能横向扩展存储、又不需要业务大改的底座。这也是我今天想聊的 PolarDB 存算分离架构的典型适用场景当数据量走到 100TB 这个量级单机 MySQL 和常规主从已经被压到极限分库分表又会带来巨大的改造代价和数据搬迁风险时用存算分离把存储层独立出去、按需扩展往往是最平滑、性价比也最高的破局方式。这篇内容我结合三个真实客户的落地案例来拆他们分别属于游戏、金融科技和电商零售数据规模全部到了 100TB 上下业务形态各不相同但最终都选择了 PolarDB 的存算分离路线。我会把每个客户在切换前的痛点、为什么没有走别的路、最终集群长什么样以及切换过程中踩过的坑和调整细节都展开讲清楚。对正在做容量规划、数据库选型或者被大表拖垮的运维和 DBA 来说这篇应该能给你一条比较清晰的参考路径。1. 存算分离为什么是超大规模数据的必然选择1.1 传统架构在百TB规模下的困境先把话说透在数据量达到 100TB 之前很多团队其实感受不到架构的瓶颈。单机 MySQL 配上主从复制撑到 5TB、10TB 都还算体面顶多是把慢查询优化一下、把归档任务错峰跑一跑。但一旦数据量跨过 50TB 往 100TB 走问题就不是优化能解决的了。首先是存储成本的失控。一台物理机配 NVMe SSD单盘容量和 IOPS 总是有限制的。为了扛住 100TB 的数据量你可能需要在一片大容量 HDD 上存放冷数据再把热数据放在 SSD 上于是就得自己实现一套冷热分层逻辑——这听起来很美做起来全是泪。其次主从同步开始变得不可靠。100TB 的实例binlog 的生成速度非常惊人从库追主库的延迟会从毫秒级涨到秒级甚至分钟级。我见过最夸张的情况是某个从库因为大事务回放卡了整整四十分钟业务方已经打了三次投诉电话。再次备份和恢复的时间窗口完全失控。用传统物理备份或者逻辑备份跑一次全量动辄十几个小时期间对主库的影响又没法完全消除一旦需要恢复数据整个团队的心态基本是崩溃的。这些困境的本质只有一个计算和存储耦合在一起导致扩容时计算资源和存储资源必须一起加数据搬迁成本极高存储瓶颈直接锁死了整体的扩展能力。1.2 存算分离的核心思想与收益PolarDB 存算分离的思路其实不复杂把 MySQL 兼容的计算节点和底层存储节点拆开计算节点只负责 SQL 解析、执行计划生成和事务处理而数据实际存放在一个分布式存储池中。这个存储池内部会自动把数据切成一个个数据分片分布在多台存储节点上并且通过多副本机制保证数据可靠性。这样做带来的第一个直观收益是扩容方式的改变。以前加存储必须加机器现在存储空间不够了直接在存储池上做横向扩容就行计算节点数量可以保持不变。反过来如果只是 CPU 或内存不够那就单纯增加只读计算节点存储不需要动。这种存储与计算完全解耦的模型让容量规划变得像在云上点外卖一样简单。第二个收益是存储成本的显著下降。PolarDB 的存储池底层可以分层放置热数据和冷数据不需要业务方自己维护一套归档逻辑。对 100TB 级别的数据来说单是存储成本一项不少客户算下来就比传统方案节省了一半以上。第三个收益则是高可用能力的增强。存储节点自身通过多副本机制保障数据不丢失计算节点宕机后可以在秒级内完成切换并且因为数据在存储池里是共享的新的计算节点起来后不需要做任何数据回放或重建这个恢复速度和传统主从架构完全不是一个量级。对很多团队来说存算分离最大的隐性收益其实是它让 DBA 从每天陪着大实例熬备份的状态里解放出来把精力放在真正的业务优化上而不是天天加班救火。2. 三个客户的真实落地案例2.1 游戏行业支撑千万级日活的用户中心与日志库第一位客户是国内一家做休闲竞技类手游的厂商他们的日活峰值在千万级别玩家数据、对局记录、道具流水和充值流水都集中在这套数据库里。最核心的库是用户中心和结算中心数据量大概在 60TB 左右再加上对局日志库和历史归档总数接近 120TB。他们切换前用的是自建 MySQL 主从集群每台物理机挂 12 块 4TB SATA SSD做了 RAID 10。核心痛点有两个一个是每个月末的结算批处理任务跑起来后主库的 CPU 和 IO 直接被打满玩家在晚高峰时段会出现登录超时另一个是充值流水表已经增长到接近 8 亿行单表太大了每次对账查询慢得让人崩溃他们甚至考虑过分库分表但评估下来改造量太大——支付和账号体系的强事务查询根本不支持按用户 ID 简单拆分。切换 PolarDB 存算分离架构后他们把用户中心、结算中心和充值流水全部迁到了 PolarDB 的一个大实例上计算节点用了 8 核 64GB 的主节点加 4 个只读节点存储池自动扩展到 120TB。结算批处理任务还是照常在凌晨跑但因为它现在跑在独立计算节点上主库完全不感知晚高峰的登录超时问题直接消失。充值流水的大查询由于可以路由到只读节点对账效率提升了接近十倍。这个客户最满意的一点是他们保留了大表的原始结构没有做任何拆分业务代码改动量几乎为零。迁移过程中踩过一个比较典型的坑因为历史归档库里有一部分表用的是 MyISAM 引擎迁移工具不支持直接转换后来用了 PolarDB 提供的数据迁移服务做了全量加增量同步先在目标端把表结构改成了 InnoDB再开放业务流量整个过程前前后后演练了三次才正式切流。2.2 金融科技交易流水库从扩容噩梦到按需扩展第二位客户是某头部金融科技公司的核心账务团队他们的账务流水库是最典型的超高并发写入场景。每天产生的交易流水超过 5 亿条单日新增数据量在 500GB 到 800GB 之间整体数据规模接近 100TB。对金融系统来说数据一条都不能丢强一致性是刚需同时还要支持多维度查询比如按用户查、按商户查、按交易时间范围查还有大量对账批处理任务。他们原来的架构已经是 MySQL 分库分表的经典方案256 个分片分布在 8 台物理机上。这个方案支撑到了 80TB 左右问题开始显现。分片的数据分布不均衡有的分片因为某个大商户的流水集中写入已经膨胀到快 1TB而其他分片只有 300GB。每次扩容一个分片都要经历数据搬迁、路由规则变更、灰度验证的完整流程光是一个分片的迁移就要做三到五天而且大商户的强事务查询跨了多个分片后性能下降非常明显。他们转向 PolarDB 存算分离后最核心的调整是放弃了分库分表把核心流水表重新合并回一张大表直接跑在 PolarDB 的单个大实例上。你没听错原来在传统架构下必须分库分表的场景在存算分离的架构下反而不需要了。因为存储池可以横向扩展单表容量不再是瓶颈而计算节点通过增加只读节点来分散查询压力。这个改动直接把他们的应用层代码从分库分表中间件的各种限制里解放了出来跨分片查询变成了普通 SQL开发效率提升非常明显。因为这个客户对数据一致性要求极高他们选择全部写入走主节点只读节点主要承接对账和报表类的查询。实测下来在账务流水表 100TB 规模下单条按条件索引查询的 P99 延迟可以稳定在 20 毫秒以内这在他们原来的分库分表架构上很难达到——因为跨分片的查询需要聚合网络开销太大。2.3 电商零售订单中台与商品中心的统一数据底座第三位客户是电商赛道的一家头部平台他们的数据规模最为庞大。订单中台超过 70TB商品中心接近 30TB再加上会员、营销、库存等系统总量大概到了 160TB。这家公司和前两家不同的地方在于他们没有历史包袱从一开始就搭建在云原生架构上之前的订单库用的是另一个云厂商的托管 MySQL当时已经遇到了明显的容量上限——单实例存储上限是 16TB他们不得不把订单表按年拆成多张物理表业务代码里到处是年和月参数拼接的表名开发同学叫苦不迭。他们换 PolarDB 的时候做了一个很彻底的决策不搞按年拆表了直接合并成一张全量订单大表。因为 PolarDB 存算分离的存储池可以扩展到 100TB 以上单表容量上限被彻底打破。现在订单中台和商品中心统一跑在 PolarDB 集群上主计算节点规格是 16 核 128GB外加 6 个只读计算节点分别承接订单查询、商品详情读取、运营报表等不同的业务流量实现了读写完全隔离。商品中心有个很典型的场景大促期间商品价格和库存需要频繁更新同时商品详情页的并发查询量会突然暴增。以前他们在托管 MySQL 上只能靠增加只读副本扛查询压力但只读副本有延迟经常出现用户看到的价格和库存不是最新值的情况。换到 PolarDB 后因为存储是共享的只读节点天然强一致用户可以读到主节点最新提交的数据大促稳定性提升非常明显。这个客户在双十一大促峰值期间订单中台的写入 TPS 稳定保持在每秒 12 万以上查询 QPS 超过 80 万存储池的 IO 延迟全程没有超过 3 毫秒。3. 存算分离架构下的核心细节与实操要点3.1 存储引擎与计算节点解耦后的写入链路很多刚接触 PolarDB 的同学会习惯性地把它的存储池想象成一块普通的网络硬盘其实这是个重要的理解偏差。PolarDB 的计算节点和存储节点之间采用了一套专门设计的传输协议计算节点上的 InnoDB 引擎在写入数据时并不是像传统架构那样先把数据页写到本地磁盘再通过 binlog 同步给其他节点而是把 Redo Log 实时下推到存储池由存储节点负责把数据页最终落地。这个设计带来的直接效果是主节点和只读节点共享同一份存储数据binlog 的同步压力被彻底消除。你在 PolarDB 集群上创建只读节点它不需要像传统 MySQL 从库那样去回放主库的 binlog而是直接读取共享存储上已经提交的数据。只读节点的扩展速度因此变得非常快而且只读节点永远不会有复制延迟超标的问题因为它的数据已经是最新的。这也是前面提到的电商客户能在只读节点上做到强一致读的根本原因。实操层面有个重要的调优点写入密集型的业务要特别关注 Redo Log 的刷盘策略和存储池的 IOPS 容量。PolarDB 的每个计算节点可以独立设置 innodb_flush_log_at_trx_commit如果业务对数据安全性要求极高就保持默认的 1如果是一些可以容忍小概率丢失的日志型业务可以改成 0 或 2这样写入吞吐会明显提升。我自己在压测环境下对比过在 100TB 数据量下把刷盘策略从 1 调整到 2写入吞吐量能提升大约 30%但这个改动务必要业务方确认好一致性容忍度再动。3.2 100TB 级别下的备份恢复与归档策略一旦数据规模上了 100TB备份这个话题就不再只是DBA 日常任务了它会直接决定整个运维体系的可靠程度。传统 MySQL 在 100TB 规模下的物理备份基本没法看了——xtrabackup 全量备份至少要跑十几个小时备份文件占用的磁盘空间又是另一笔巨大开销。PolarDB 存算分离架构在备份上的优势可以说是它最容易被低估的亮点。因为数据实际存储在分布式存储池里PolarDB 的备份是基于存储层的快照能力做的可以在秒级生成一个一致性快照完全不占用计算节点的 IO 资源。你可以一天做多次快照成本极低恢复时也可以选择任意一个快照时间点做快速恢复把一个 100TB 的实例恢复到新集群通常只需要几分钟到十几分钟这个恢复速度在传统架构下是想都不敢想的。这个特性落到实际操作上最大的价值在于你可以放心大胆地做频繁的沙箱验证和容灾演练而不用像以前那样给每次演练预留一整天的窗口。我建议所有用了 PolarDB 的团队把月级容灾演练改成周级每次演练直接从一个小时前的快照恢复出一个完整实例然后让测试团队在上面跑核心链路回归。这套流程跑顺以后整个团队的数据库运维安全感会提升一个档次。归档策略方面存算分离架构不一定需要你自己做冷热分离。PolarDB 的存储池支持按数据块的访问频度自动调整存储层级冷数据会自动沉降到更低成本的存储介质上。你在业务层面唯一需要规划的其实是生命周期明确的历史数据是否要迁出到独立实例。我见过不少客户把三年以上的订单数据留在原实例的归档库用 PolarDB 的 DTS 工具做按时间范围的定期同步这样既能保持主实例的轻量又不影响历史数据查询这个方案实操下来很成熟。3.3 兼容性与迁移路径从自建 MySQL 平滑迁移PolarDB 的 MySQL 兼容性是我愿意向客户推荐它的一个重要原因。它不是兼容大部分语法这种程度而是从协议层到 SQL 语义都做了深度兼容这意味着大多数基于 MySQL 5.7 或 8.0 开发的应用甚至不需要改一行代码就能跑在 PolarDB 上。当然实际迁移时还是有几个细节值得提前确认。第一个是数据库账号和权限体系的迁移。PolarDB 的账号体系跟 RDS MySQL 类似但和自建 MySQL 的授权命令有一些差异建议在迁移前做好账号清单整理统一在目标端重建不要尝试直接导入 mysql.user 表的数据那是典型的自找麻烦。第二个是存储过程和定时任务的检查。如果业务里用了大量的存储过程和 Event Scheduler迁移前需要逐个在 PolarDB 上做兼容性验证因为个别内置函数的行为边界可能略有区别。第三个是参数配置的核对。自建 MySQL 的 my.cnf 里很多参数在 PolarDB 上是通过参数模板管理的比如 innodb_buffer_pool_size 这类参数不再需要手动设置而像 sql_mode、max_allowed_packet、timeout 这类参数要对照业务需求提前配置好。迁移路径上最稳的组合方案是先创建 PolarDB 实例再用数据传输服务做全量迁移加增量同步。全量迁移的阶段可以放在业务低峰期执行增量同步阶段观察主从延迟稳定在 0 到 1 秒之间以后再选择一个维护窗口做最终的业务切换。我特别建议在正式切换前做至少两次全流程演练第一次演练只验证数据完整性和主要功能链路第二次演练就要带着故障预案做把切换过程中可能出现的回滚场景也一并演练到位。很多团队第一次切流时手忙脚乱基本都是因为演练次数不够导致切换脚本里的隐藏问题没有提前暴露。4. 常见问题与排查技巧实录4.1 超大事务与锁等待问题存算分离架构下的大事务表现和传统 MySQL 有些相似但排查的思路不太一样。我遇到过好几个客户反馈业务高峰期 PolarDB 主节点的 CPU 使用率并不高但 SQL 执行延迟很高应用侧出现大量锁等待超时。这类问题十有八九来自超大事务。因为 PolarDB 的存储是共享的大事务持有行锁的时间一旦变长所有访问同一行数据的其他事务都会被阻塞。更麻烦的是在存算分离架构下超大事务的提交过程需要等待 Redo Log 在存储池中完成多副本确认所以事务越大提交阶段的开销就越高。排查看两样东西一是 information_schema.innodb_trx 表里有没有长时间未提交的事务二是 Performance Schema 里的 events_statements_current 表定位到具体是哪条 SQL 开了事务后长时间不提交。实操层面我一般会建议业务代码里统一加上事务超时控制在应用层使用类似 Spring 的 Transactional 注解时设置一个合理的 timeout 值默认不要超过 30 秒。同时把事务内的查询尽量拆出去只把写操作留在事务里这种小的编码习惯可以在根源上减少大事务的产生。4.2 存储IOPS与延迟抖动排查存算分离架构下计算节点和存储节点之间走的是网络所以存储延迟不再是本地磁盘的微秒级而是网络往返的毫秒级。这个架构差异需要团队提前建立好心理预期和监控基线。正常情况下PolarDB 的存储池在百 TB 规模下单次 IO 的 P99 延迟应该稳定在 1 到 3 毫秒之间。如果发现 IO 延迟出现持续抖动首先要看是不是存储池的 IOPS 配额被打满。排查方法很简单在 PolarDB 控制台查看存储节点监控关注存储 IOPS 使用率这个指标。如果持续超过 80%就得考虑提升存储池的性能等级或者把部分读流量从主节点迁移到只读节点。这里有个经验值我在好几个客户现场验证过当读流量占比超过 70% 时把查询流量分流到只读节点存储 IOPS 的总体压力能下降 50% 以上延迟抖动问题通常会随之消失。还有一种比较隐蔽的延迟抖动来自存储节点自身的块拆分和再平衡。当存储池容量使用率达到某个阈值后系统会自动触发数据块的迁移和再平衡这个过程会造成短时间的 IO 延迟升高。规避的办法是提前做好容量规划不要等到 90% 再来扩容。我一般建议把存储使用率的安全水位控制在 70% 以内这样既能留出足够的再平衡缓冲也能避免在业务高峰期触发自动迁移。4.3 连接数与连接池参数调优存算分离架构带来的一个隐性变化是因为只读节点扩展太方便了很多团队会倾向于创建大量只读节点来分摊流量结果每个节点都配置了很大的连接池整体连接数一下子涨上去直接把网络层和应用网关打懵了。这个问题我在两个客户现场都遇到过排查起来其实不难但需要提前预防。PolarDB 集群的每个计算节点都有 max_connections 限制不同规格对应的默认值不同。在 100TB 数据量下主要写入节点建议保持默认配置即可不要为了追求高并发而盲目调大 max_connections。因为连接数越大上下文切换开销越大反而会降低单节点的吞吐能力。更推荐的做法是控制应用连接池的最大连接数配合只读节点的水平扩展来分摊压力。这里分享一个我实际调过的参数组合。对一个 8 核 64GB 的主节点应用连接池的最大连接数设置在 100 到 200 之间比较合适只读节点如果是 4 核 16GB最大连接数建议控制在 80 以内。然后根据业务读流量的增长动态增加只读节点数量而不是堆单节点的连接数。同时把 MySQL 侧的 wait_timeout 和 interactive_timeout 适当调短比如从默认的 8 小时缩短到 1 小时能有效避免应用侧异常退出时残留大量死连接。这套组合拳打下来连接数相关的故障基本可以绝迹。5. 写在最后一次架构升级的真实体会回头再看这三个客户虽然行业不同、业务形态不同、数据特征也不同但他们最后走到的位置是高度一致的——通过存算分离彻底告别了分库分表或者按年拆表这类反模式把精力重新放回到业务本身。我个人在帮他们做方案选型和迁移评估的过程中最大的体会是PolarDB 存算分离的真正价值并不只是容量大而是它把数据库最麻烦的存储扩展问题从基础设施改造降维成了控制台操作。如果你现在正对着一个 50TB 以上的 MySQL 实例发愁或者刚被分库分表的改造量劝退我的建议是不妨先拿一个非核心业务库到 PolarDB 上做一次完整的迁移演练。花半天时间验证一下兼容性和性能表现远比你花几个月时间讨论架构方案要实在得多。数据量再大也没有想象中那么可怕关键是选对船。