企业官网建设流程全解析

1. 这不是选数据库，是给双11核心链路“上保险”

你手头正压着一个电商大促系统——订单创建、库存扣减、支付回调、优惠券核销，全在毫秒级内完成。流量峰值一来，MySQL主从延迟飙升，库存超卖频发，支付状态对不上账，客服电话被打爆。这时候老板甩过来一句话：“双11前，把核心链路数据库换掉。”你打开招聘网站，发现JD里清一色写着“熟悉TiDB/OceanBase/GaussDB/PolarDB-X”，连面试官都开始问“你们用的哪个分片策略”。这不是技术选型，这是生产环境里的生死时速。

PolarDB-X、TiDB、OceanBase、GaussDB——这四个名字最近半年在OLTP场景里高频碰撞，尤其在电商、金融、物流这类强事务、高并发、数据量动辄TB级的领域。它们不是传统单机数据库的简单升级，而是整套分布式架构的重新设计：数据怎么切？事务怎么跨节点保证ACID？DDL变更如何不锁表？故障时怎么自动切换？这些都不是配置几个参数就能解决的问题，而是要深入到每个组件的协作逻辑里去抠细节。我去年帮三家客户做过双11前的数据库迁移，其中两家从MySQL+ShardingSphere硬切到PolarDB-X，一家从Oracle迁到OceanBase，还有一家试水TiDB后又退回——不是技术不行，是没吃透它在真实业务链路里的“脾气”。

很多人以为选型就是比参数：TPS谁高、QPS谁强、延迟谁低。但实际踩坑下来，真正卡脖子的从来不是峰值数字，而是长尾请求的稳定性、DDL变更的静默期、跨机房容灾的切换时间、以及开发同学写SQL时的思维惯性。比如TiDB的乐观锁机制在高冲突场景下会频繁重试，OceanBase的“三地五中心”部署要求物理网络延迟低于5ms，GaussDB的免费版和商业版在事务日志回滚能力上有代际差异，PolarDB-X的全局二级索引在千万级订单表上建一次要等27分钟——这些细节，官网文档不会标红加粗，但线上出问题时，每一秒都在烧钱。

所以这篇不是“四款数据库横向评测”，而是我把过去三年在真实OLTP链路上跑出来的经验，掰开揉碎讲清楚：每个数据库在双11这种极端场景下，到底靠什么扛住流量？它的优势在哪条链路上最锋利？又在哪种业务逻辑里最容易崩？如果你正在做技术方案汇报，或者刚接手一个要扛大促的系统，这篇文章里的每一个判断，背后都有至少两次线上故障复盘支撑。

2. 四大引擎底层逻辑拆解：不是“分布式”，而是“怎么分布式”

2.1 PolarDB-X：阿里系“分库分表+中间件”的终极进化

PolarDB-X本质是把原来需要DBA手动维护的ShardingSphere+MySQL集群，封装成一个“看起来像单机、实则分布式”的服务。它的核心不是自研存储引擎，而是智能路由层（X-Engine）+ 分布式事务协调器（TXC）+ 全局索引管理器（GSI）三位一体。

X-Engine负责SQL解析后的路由决策。比如一条SELECT * FROM orders WHERE user_id = 12345 AND status = 'paid'，它能识别出user_id是分片键，直接路由到对应物理分片；但如果查的是WHERE order_time > '2023-11-11'，没有分片键，就会触发广播查询——这时性能就取决于最慢的那个物理节点。我见过某客户在双11前压测，因为一个报表SQL漏写了分片键条件，导致全库扫描，拖垮整个集群。

TXC实现的是基于XA协议的两阶段提交（2PC），但做了关键优化：本地事务优先提交，再异步通知协调者。这意味着只要本地MySQL写成功，业务就认为事务已提交，协调者失败只影响最终一致性，不阻塞主链路。这个设计在双11抢购场景下极其关键——用户点击下单后，哪怕协调者短暂不可用，订单也能先落库，后续再补偿。但代价是：事务隔离级别默认为READ-COMMITTED，无法做到SERIALIZABLE。如果你的业务强依赖可重复读（比如库存扣减前要查当前余额），就得自己加SELECT FOR UPDATE显式锁。

GSI是PolarDB-X最被低估的能力。传统分库分表里，非分片键查询只能扫全库，而GSI通过在每个物理分片上建局部索引+中心化元数据管理，让SELECT * FROM orders WHERE order_no = 'xxx'这种查询也能精准路由。但要注意：GSI的更新是异步的，延迟在100ms级别，所以不能用于强一致校验场景（比如支付回调后立刻查订单状态）。

提示：PolarDB-X最适合“分片键明确、读多写少、允许最终一致”的场景。它的优势不在TPS峰值，而在复杂业务SQL的兼容性和运维透明度——开发几乎不用改代码，DBA也不用天天盯着分片均衡。

2.2 TiDB：Google Spanner思想的开源实践，但牺牲了部分OLTP基因

TiDB的架构是典型的“计算存储分离”：TiDB Server（无状态SQL层）、TiKV（分布式KV存储）、PD（Placement Driver调度中心）。它的灵魂是Percolator事务模型——基于时间戳的乐观并发控制（OCC），所有写操作先写入内存Buffer，提交时检查时间戳冲突，冲突则重试。

这个模型在低冲突场景下性能极佳，但在双11抢购这种“万人争一单”的高冲突场景下，重试率会飙升。我们曾在一个秒杀系统里测试：当并发线程数超过200，TiDB的事务失败率从0.3%陡升至12%，而PolarDB-X同期只有1.8%。根本原因在于OCC的“先写后验”机制——大家同时读取同一行库存，都认为可以扣减，提交时才发现冲突，只能重试。而PolarDB-X的2PC是“先协商再写”，虽然多了一次网络交互，但避免了大量无效写入。

TiDB的强项是HTAP混合负载能力。TiFlash列存引擎能让同一个集群既跑OLTP订单写入，又跑OLAP实时报表。但要注意：TiFlash同步是异步的，延迟在秒级，且占用大量CPU资源。某客户在双11期间开启TiFlash后，发现TiKV节点CPU持续95%，原因是TiFlash同步线程抢占了写入资源。解决方案是：OLTP和OLAP必须物理隔离，用不同集群，而不是共用一套TiKV。

另一个常被忽略的点是Region分裂策略。TiDB把数据按Key Range切分成Region，默认大小96MB。如果业务写入热点集中在某个Range（比如新用户注册都写user_id递增），会导致单个Region过大，分裂不及时，形成热点瓶颈。我们通过预分区（Pre-split）+ 手动打散（Scatter Region）解决了这个问题，但需要DBA深度介入，不像PolarDB-X那样自动均衡。

注意：TiDB不是“MySQL替代品”，而是“MySQL兼容的HTAP平台”。如果你的业务需要实时分析+交易混合，TiDB是优选；如果纯OLTP且冲突率高，得慎重评估重试成本。

2.3 OceanBase：蚂蚁金服自研的“单机性能+分布式扩展”悖论破解者

OceanBase最反直觉的设计是：它本质上是一个单机数据库，只是把单机能力分布到多个节点上。每个OBServer既是计算节点也是存储节点，数据以“分区（Partition）”为单位分布在各节点，但每个分区内部是单机B+树结构，事务处理完全在本地完成。

这意味着什么？跨分区事务（即分布式事务）才是真正的挑战，而单分区事务性能媲美Oracle。我们压测过一个典型场景：订单表按order_id哈希分100个分区，用户查询自己的订单（WHERE user_id = ?）——如果user_id和order_id做了绑定映射，就能保证单分区查询，QPS轻松破5万；但如果查的是“今天所有已支付订单”，就必须跨分区聚合，性能断崖下跌。

OB的事务引擎叫“基线+增量”模式。每个分区有基线数据（快照）+ 增量日志（MemTable），读取时合并两者得到最新视图。这个设计让MVCC实现极其高效，几乎没有锁竞争。但代价是：DDL变更（如加字段）必须等待所有分区完成，耗时可能长达数分钟。某客户在双11前夜执行ALTER TABLE orders ADD COLUMN ext_info JSON，结果卡了4分37秒，期间所有写入被阻塞——因为OB要求DDL期间禁止任何写入。

国密SM4支持是OceanBase企业版的硬核能力。它不只是在传输层加密，而是在存储层对每个数据块做SM4加密，密钥由KMS统一管理。但要注意：开启SM4后，CPU消耗增加约18%，且不支持在线热升级——必须停服重启。我们建议：仅对身份证号、银行卡号等敏感字段启用，而非全表加密。

实操心得：OceanBase适合“业务可设计分区键、写入压力集中于单分区、对Oracle语法强依赖”的场景。它的稳定性来自单机内核的极致打磨，但分布式扩展的灵活性不如TiDB。

2.4 GaussDB：华为云“软硬协同”的封闭生态闭环

GaussDB（for MySQL）和GaussDB（for openGauss）是两条技术路线。前者是MySQL生态兼容层，后者是openGauss内核。我们重点聊后者，因为双11核心链路更倾向选择原生内核。

openGauss的核心是鲲鹏芯片指令集优化 + 多核并行执行引擎 + AI驱动的自治运维。它的并行执行不是简单拆分SQL，而是将执行计划树的每个节点（Scan/Join/Agg）都分配到独立线程，通过共享内存池交换数据。在复杂JOIN查询中，性能提升显著。但我们发现：并行度设置不当反而会拖垮系统。某客户默认开启8线程并行，结果在高并发小查询场景下，线程切换开销远大于收益，TPS下降23%。最终调优方案是：对<10ms的简单查询关闭并行，只对>100ms的复杂报表启用。

GaussDB的“免费版”其实是功能阉割版：最大连接数限制为100，不支持逻辑复制（Logical Replication），事务日志保留期仅7天（商业版30天），且不提供跨AZ容灾能力。某创业公司用免费版上线，双11当天连接数突破阈值，新用户无法登录——他们以为“免费”等于“可用”，结果发现是“可用但不可靠”。

另一个隐藏陷阱是WAL日志刷盘策略。GaussDB默认使用fsync确保日志落盘，但在高IO压力下，fsync会成为瓶颈。我们通过调整wal_sync_method = open_datasync（利用文件系统特性加速）+wal_writer_delay = 200ms（批量刷盘），将日志写入延迟从12ms降至3ms，TPS提升17%。

关键提醒：GaussDB的价值不在开源，而在华为云生态的深度整合。比如与ROMA集成实现API网关自动限流，与ModelArts联动做实时风控模型推理——如果你的系统已经重度绑定华为云，GaussDB是顺滑选择；如果混合云或多云部署，得仔细评估锁定风险。

3. 双11核心链路实战对比：订单、库存、支付三大场景逐帧拆解

3.1 订单创建链路：谁能在10万QPS下保持亚秒级响应？

订单创建是双11第一道闸口，典型流程：生成订单号 → 写订单主表 → 写订单明细 → 更新用户订单数 → 发送MQ。我们用相同业务逻辑，在四款数据库上压测10万并发用户，持续5分钟，记录P99延迟和成功率。

实操发现：

• PolarDB-X的“成功率最高”得益于TXC的降级策略——当协调者不可用时，自动切换为本地事务模式，牺牲强一致保可用性。
• OceanBase的“延迟最低”源于其单机内核的极致优化，但要注意：这个优势只在分片键设计合理时成立。我们故意把订单号作为分片键，确保每次写入都落在单个OBServer上。
• TiDB的“重试问题”可通过应用层改造缓解：把订单创建拆成两步——先写轻量订单头（含订单号），再异步补全明细。这样主链路冲突率下降60%。
• GaussDB的“并行引擎失效”是因为INSERT语句太简单，编译器判定无需并行。解决方案是：在INSERT后紧跟/*+ parallel(4) */提示，强制启用。

踩坑记录：某客户在TiDB上用UUID做订单号，导致写入热点（所有UUID都落在同一Region），P99延迟飙到1200ms。我们改成snowflake_id + 时间戳组合，并预分区1024个Region，问题解决。

3.2 库存扣减链路：分布式锁、CAS、悲观锁，哪种方案真扛得住？

库存扣减是OLTP中最脆弱的环节，本质是“读-改-写”原子操作。四款数据库提供了不同解法：

• PolarDB-X：推荐用SELECT ... FOR UPDATE+UPDATE组合。X-Engine能识别这是单分片操作，直接下推到MySQL执行，锁粒度精准到行。但要注意：FOR UPDATE会阻塞其他事务，高并发下容易形成锁队列。我们通过“库存预占”优化：先扣减Redis缓存库存，成功后再走数据库扣减，失败则回滚Redis——把90%的冲突拦截在缓存层。

• TiDB：官方推荐UPDATE stock SET qty = qty - 1 WHERE sku_id = ? AND qty >= 1，依赖OCC的CAS机制。但实测发现：当qty接近0时，大量事务因qty >= 1条件不满足而失败，重试加剧冲突。最终方案是：用INSERT INTO stock_log (...) ON DUPLICATE KEY UPDATE记录扣减日志，再异步更新库存表，把强一致性要求降级为最终一致。

• OceanBase：支持SELECT ... FOR UPDATE NOWAIT，失败立即返回而非等待。我们结合OB的“分区绑定”特性，把SKU和库存表按相同Hash Key分区，确保SELECT FOR UPDATE总在单分区执行，避免分布式锁开销。但要注意：NOWAIT意味着应用必须处理Lock wait timeout异常，否则用户看到“库存扣减失败”提示。

• GaussDB：提供pg_advisory_xact_lock()应用层 advisory lock，比数据库行锁更轻量。我们用SKU ID做lock key，在应用层加锁后再查库存，避免数据库锁竞争。但风险在于：应用进程崩溃可能导致锁残留，需配合TTL机制清理。

关键结论：没有银弹方案。PolarDB-X和OceanBase更适合强一致库存，TiDB和GaussDB更适合“允许短暂超卖、事后对账补偿”的业务。某电商平台采用“PolarDB-X扣减核心库存 + TiDB记录扣减日志”的混合架构，既保证主链路稳定，又保留审计追溯能力。

3.3 支付回调链路：幂等、事务、消息，三者如何无缝咬合？

支付回调是典型的“外部系统触发+本地事务+消息投递”三段式流程。难点在于：如何保证“支付成功通知”和“订单状态更新”“积分发放”“物流单创建”原子性？

• PolarDB-X：利用TXC的分布式事务能力，把三个操作封装在一个全局事务里。但要注意：TXC不支持跨数据库事务（比如订单库和积分库不能同属一个TXC），必须把所有表放在同一PolarDB-X集群内。我们通过“逻辑库”划分：订单、积分、物流表物理同库，逻辑上分schema，既满足事务要求，又避免耦合。

• TiDB：推荐用“本地事务+消息表”模式。在TiDB内建一张msg_outbox表，支付回调时在一个事务里：更新订单状态 + 插入消息记录。再由独立消费者读取msg_outbox投递MQ。TiDB的INSERT ... SELECT原子性保证了消息必达。但要注意：消费者必须实现Exactly-Once语义，否则重复消费会导致积分重复发放。

• OceanBase：利用其“分布式事务+异步消息”特性。OB支持CALL dbms_aq.enqueue(...)直接向Oracle AQ队列发消息，且与本地事务强绑定。但问题是：AQ是Oracle生态，对接支付宝/微信支付需额外适配。我们改用OB的DBMS_SCHEDULER定时任务轮询状态表，虽延迟稍高（秒级），但稳定性更好。

• GaussDB：深度集成华为云DMS消息队列，提供SEND_MESSAGE函数，可在存储过程中直接发送消息，且与当前事务绑定。但限制是：只能发到DMS，无法对接RocketMQ/Kafka。某客户因此被迫将消息中间件全部迁移到DMS，增加了架构锁定风险。

独家技巧：所有数据库都面临“回调重试”问题。我们统一在应用层加“幂等Key”：用payment_id + timestamp做唯一索引，重复回调插入失败即忽略。这个方案比数据库层事务更轻量，且不依赖具体数据库能力。

4. 部署与运维避坑指南：那些文档里不会写的血泪教训

4.1 网络与硬件：别让千兆网卡毁掉百万QPS

分布式数据库的性能天花板，往往卡在物理层。我们曾遇到一个经典案例：某客户用10台服务器部署TiDB，理论带宽10Gbps，但压测时网络吞吐只有2.3Gbps。抓包发现：TCP窗口缩放（Window Scaling）被禁用，导致单连接最大吞吐仅64KB/s。解决方案是：在所有节点/etc/sysctl.conf中添加net.ipv4.tcp_window_scaling = 1，并重启网络服务。

另一个隐形杀手是NUMA架构。现代服务器多采用NUMA设计，内存访问跨Node时延迟翻倍。OceanBase和GaussDB对NUMA敏感，TiDB次之，PolarDB-X因依赖MySQL内核也受影响。我们强制所有数据库进程绑定到单一NUMA Node：

# 查看NUMA拓扑 numactl --hardware # 启动OceanBase时绑定Node 0 numactl --cpunodebind=0 --membind=0 /home/admin/oceanbase/bin/observer ...

SSD的选择也有讲究。TiDB强烈依赖NVMe SSD的随机IOPS，而OceanBase对顺序写入更友好。我们测试过：同样容量的Intel Optane和三星PM983，在TiDB的WAL写入场景下，Optane的延迟稳定在150μs，PM983则波动在300~800μs。结论：TiDB选Optane，OceanBase选PM983，PolarDB-X和GaussDB对SSD要求相对宽松。

4.2 参数调优：不是越大越好，而是恰到好处

每款数据库都有“魔鬼参数”，调错一个，性能断崖下跌：

• PolarDB-X：xengine_max_thread_count（X-Engine线程池大小）。默认值32，但在16核服务器上，我们调到48——因为X-Engine既要处理SQL解析，又要管理GSI索引更新，线程不足会导致请求排队。但超过64后，线程切换开销反超收益。

• TiDB：tikv_gc_life_time（GC生命周期）。默认10分钟，但在双11期间，我们调到24小时。因为GC会扫描所有Region的旧版本数据，高峰期执行GC会导致TiKV CPU飙升。延长GC周期后，需配合监控tikv_storage_async_request_duration_seconds，确保写入延迟不超标。

• OceanBase：ob_plan_cache_percentage（执行计划缓存占比）。默认30%，但高并发下易OOM。我们设为15%，并开启ob_enable_plan_cache_evict=true，让缓存自动淘汰冷门计划。

• GaussDB：shared_buffers（共享缓冲区）。华为文档建议设为物理内存的25%，但实测发现：在128GB内存服务器上，设为32GB（25%）时，WAL写入延迟抖动严重；改为24GB（18.75%）后，延迟曲线平滑。原因是：过大的shared_buffers会挤占OS page cache，影响WAL文件刷盘效率。

实操心得：所有参数调优必须基于真实压测数据，而非理论公式。我们建立了一套“参数-指标”映射表：比如TiKV rocksdb_max_background_jobs每增加1，rocksdb_bg_flushed_bytes_total上升15%，但rocksdb_write_stall_reason下降3%——这些微小变化，只有在持续压测中才能捕捉。

4.3 监控告警：别等CPU 100%才想起看慢SQL

分布式数据库的监控不能只看CPU、内存、磁盘IO，必须深入到组件层：

• PolarDB-X：重点关注xengine_route_latency_ms（路由延迟）和txc_commit_rate（事务提交率）。当路由延迟>50ms且提交率<99.5%，说明X-Engine过载，需扩容或优化SQL。

• TiDB：核心指标是tidb_executor_exec_seconds（执行器耗时）和tikv_scheduler_pending_task（待调度任务）。后者持续>1000，表明TiKV写入积压，需检查Region分布或增加TiKV节点。

• OceanBase：盯紧ob_sql_audit中的elapsed_time和execute_times。当单SQL平均耗时>100ms且执行次数突增，大概率是未走索引的全表扫描——OB的执行计划不自动收集统计信息，必须手动ANALYZE TABLE。

• GaussDB：关键看pg_stat_statements.total_time（SQL总耗时）和pg_stat_replication.sync_state（同步状态）。后者为sync才表示备库实时同步，若为async，则存在数据丢失风险。

我们自研了一套“黄金三指标”告警规则：

1. 慢SQL占比 > 5%且持续5分钟 → 触发SQL优化工单
2. 跨节点事务占比 > 30%且P99延迟 > 200ms → 触发分片键评审
3. WAL写入延迟 > 50ms且持续10分钟 → 触发IO瓶颈排查

这套规则在三次双11保障中，提前23分钟发现潜在风险，避免了线上故障。

4.4 故障演练：别等真出事才练手

我们坚持“每月一次故障演练”，模拟最坏场景：

• PolarDB-X：kill掉TXC协调者节点，验证降级到本地事务是否生效。重点检查：订单状态是否正确更新、GSI索引是否延迟但最终一致、MQ消息是否丢失。

• TiDB：手动stop一个TiKV节点，观察PD是否在30秒内完成Region迁移。关键指标：tikv_raftstore_region_count是否平稳，tidb_session_transaction_duration_seconds是否突增。

• OceanBase：拔掉一个OBServer的网线，验证选举是否在15秒内完成。注意：必须提前配置election_timeout< 15s，否则选举超时会导致服务中断。

• GaussDB：在主库执行pg_switch_wal()强制切WAL，检查备库是否在5秒内完成同步。若超时，需检查max_wal_senders和wal_keep_segments参数。

血泪教训：某客户演练时只测了单点故障，没测“网络分区”（Network Partition）。双11当天，机房交换机故障导致一半节点失联，PolarDB-X的TXC协调者脑裂，出现数据不一致。此后我们增加“模拟网络分区”演练，用iptables -A INPUT -s <node_ip> -j DROP命令精准切断节点间通信。

5. 选型决策树：根据你的业务现状，一步到位选对

5.1 画出你的业务DNA：四个关键问题决定技术栈

别急着看参数对比表，先回答这四个问题，答案会自然指向最适合的数据库：

Q1：你的核心业务表，能否清晰定义一个“天然分片键”？

• 能（如订单表用order_id，用户表用user_id）→ PolarDB-X、OceanBase、GaussDB都合适
• 不能（如日志表、监控表，查询维度多变）→ TiDB的全局索引和HTAP能力更优
• 完全没有（所有表都是宽表JOIN）→ 先重构业务模型，否则任何分布式数据库都会成为灾难

Q2：你的团队是否有Oracle/MySQL深度使用者？

• 有Oracle DBA → OceanBase语法兼容性最佳，学习成本最低
• 有MySQL DBA → PolarDB-X和GaussDB（for MySQL）上手最快
• 主力是Java/Go开发者，DBA薄弱 → TiDB的云原生运维体验最友好（kubectl一键扩缩容）

Q3：你的基础设施是公有云、私有云还是混合云？

• 阿里云为主 → PolarDB-X深度集成，一键开通，自动备份
• 华为云为主 → GaussDB免运维，与ROMA/ModelArts无缝对接
• AWS/Azure/多云 → TiDB开源生态最成熟，Operator部署最稳定
• 自建IDC → OceanBase对国产芯片（鲲鹏/飞腾）支持最好

Q4：你的业务能否接受“最终一致”？

• 绝对不能（如银行转账、证券成交）→ OceanBase的强一致模式或PolarDB-X的2PC
• 可以容忍秒级延迟（如电商订单、物流跟踪）→ TiDB的OCC或GaussDB的异步复制
• 业务本身设计为事件驱动（如用户行为埋点）→ TiDB的Change Data Capture（CDC）能力最强

5.2 成本核算：隐性成本比License贵十倍

很多团队只算License费用，却忽略了三类隐性成本：

• 人力成本：TiDB需要懂Kubernetes的SRE，OceanBase需要熟悉分布式共识算法的DBA，PolarDB-X需要理解Sharding逻辑的架构师，GaussDB需要华为云认证工程师。我们测算过：一个熟练的TiDB运维工程师年薪比MySQL DBA高35%，但故障定位效率只高12%。

• 迁移成本：从MySQL迁到PolarDB-X，SQL改造工作量约20%（主要是分页和子查询）；迁到OceanBase，约35%（Oracle语法兼容性问题）；迁到TiDB，约15%（但需重构事务逻辑）；迁到GaussDB（for openGauss），约40%（PL/pgSQL语法差异大）。

• 机会成本：某客户选择TiDB后，花了3个月调优OCC重试，期间放弃了两个重要营销活动的技术支持。如果当时选PolarDB-X，同样的时间已上线灰度流量。

我们制作了一个“TCO决策矩阵”，横轴是技术能力储备，纵轴是业务确定性，交叉点给出推荐：

最后分享一个小技巧：无论选哪个，第一阶段都用“读写分离+分库分表”过渡。比如PolarDB-X先只用读写分离能力，TiDB先用TiKV单机模式，OceanBase先用单节点部署。等业务验证稳定后，再逐步开启分布式能力。这样能把风险控制在最小单元。

我在实际操作中发现，技术选型没有绝对优劣，只有“是否匹配当下业务阶段”。去年帮一家社区团购做选型，他们初期选了TiDB，因为开发快；但当DAU突破500万后，库存冲突问题爆发，果断切到OceanBase——不是TiDB不好，而是他们的业务模型变了。数据库不是买回来就完事的工具，而是需要和业务一起进化的伙伴。