1. 为什么AI/Agent应用的数据库选型不能照搬传统OLTP经验我去年带团队落地一个智能客服Agent系统时第一版架构直接沿用了老项目用的MySQL主从集群——毕竟读写分离、分库分表都玩得挺熟。结果上线两周后对话历史查询延迟从200ms飙到3秒以上知识库向量检索偶尔超时更诡异的是当并发用户突破800时事务日志突然开始频繁刷盘失败。运维同事甩给我一张监控图InnoDB Buffer Pool Hit Rate掉到62%而Redo Log写入IOPS峰值冲到4500。那一刻我才意识到AI/Agent应用对数据库的压测维度和传统电商订单系统根本不在一个坐标系里。传统OLTP选型看的是TPC-C指标、单点写入吞吐、ACID强一致性保障但AI/Agent场景下你得同时扛住四类压力源高频小事务用户消息存档、大字段写入LLM生成的长文本embedding向量、混合负载实时对话流离线知识同步、弹性扩缩容流量波峰波谷剧烈。比如一个典型Agent会同时触发1用户输入存入message表每秒200条每条含timestampsession_idcontentmetadata2调用RAG模块时批量读取向量相似度Top50单次扫描10万行向量3后台定时任务更新知识图谱节点单次更新涉及500关联表4突发流量导致连接数瞬时翻倍比如营销活动期间并发涨3倍。这四类压力在PolarDB、Aurora、TDSQL-C、TiDB上表现差异极大。举个具体例子我们曾用Aurora做向量检索测试当similarity阈值设为0.78时单次查询耗时稳定在120ms但把阈值放宽到0.65后响应时间直接跳变到1.8秒——不是因为SQL慢而是Aurora的存储层在处理宽列扫描时会把大量冷数据页从SSD缓存加载到内存触发Page Cache抖动。而同样场景下TiDB的Region分裂机制让热点自动分散耗时波动控制在±15ms内。这种底层架构差异绝不是调几个参数就能抹平的。所以这次对比不谈“谁更好”只聚焦四个硬核维度写入吞吐稳定性应对Agent消息洪流、向量检索延迟抖动影响RAG实时性、跨AZ故障恢复速度保障7x24服务、水平扩展成本拐点决定长期TCO。后面所有数据都来自我们在真实Agent场景下的压测模拟10万用户并发每秒生成3000条消息其中20%含128维向量持续运行72小时。下面拆解每个维度的具体表现。2. 写入吞吐稳定性Agent消息洪流下的抗压能力实测AI/Agent应用最典型的写入特征是“短平快高频率小数据包”。用户每发一条消息系统就要记录timestamp、session_id、roleuser/assistant、content、token_count、model_used等字段平均单条记录约1.2KB。但高峰期可能每秒涌入5000条且要求99.9%的写入延迟低于200ms。传统数据库的写入瓶颈往往卡在三个环节日志刷盘争抢、锁竞争、主从复制延迟。我们用sysbench定制脚本模拟该场景重点观测四个数据库在不同并发下的P99写入延迟曲线。2.1 PolarDB的写入链路优化与隐性代价PolarDB采用计算存储分离架构写入请求先由计算节点写入Redo Log再异步同步到共享存储。在1000并发下其P99延迟稳定在85ms比同配置MySQL低40%。关键在于它的Log Buffer预分配机制当检测到连续小事务时会将多个事务的Redo Log合并成一个更大的块写入减少I/O次数。但这个优化有隐藏代价——当事务大小超过阈值默认16KB系统会强制切分日志块此时P99延迟会突增到210ms。我们在压测中故意混入10%的长文本消息含base64图片编码果然观察到延迟毛刺。提示PolarDB的innodb_log_file_size参数需根据Agent消息平均长度调整。我们最终设为256MB默认128MB配合innodb_log_buffer_size64MB使长文本写入毛刺消失。但要注意增大日志文件会延长崩溃恢复时间需权衡RTO。2.2 Aurora的存储层加速原理与瓶颈Aurora的“存储层自适应”是其核心优势它把Redo Log下推到存储层计算节点只需发送Log Record存储层负责持久化和复制。这使其在纯写入场景下P99延迟极低1000并发时仅62ms。但问题出在“写放大”上——Aurora为保证跨AZ一致性会将每条Log Record复制到6个存储节点3 AZ×2副本当网络抖动时某个节点响应慢会导致整个写入阻塞。我们在模拟AZ间网络延迟20ms时P99延迟飙升至340ms且出现1.2%的写入超时。注意Aurora的aurora_replica_status视图能实时查看各副本延迟但默认不开启。需执行CALL mysql.rds_set_configuration(aurora_replica_status, 1)启用否则故障时无法快速定位慢副本。2.3 TDSQL-C的分布式事务调度策略TDSQL-C作为金融级分布式数据库其写入稳定性来自两阶段提交2PC的精细化调度。它把事务分为“轻量级”和“重量级”单表操作走快速路径P9950ms跨分片操作走标准2PC。在Agent消息场景中由于session_id天然具备分片键属性95%的写入落在单分片因此1000并发下P99仅48ms。但当出现跨session关联操作如合并多轮对话延迟会跳升至180ms。我们通过改造业务逻辑将关联操作拆分为异步消息队列处理规避了该瓶颈。2.4 TiDB的Raft日志同步机制与调优TiDB的写入延迟受Raft多数派确认影响显著。在3副本部署下P99延迟在1000并发时为110ms但当网络延迟从1ms增至5ms时延迟升至290ms。关键优化点在于raft-store.pd-heartbeat-tick-interval参数默认100ms的心跳间隔在高延迟网络下会导致Raft Leader选举频繁。我们将该值调至500ms并启用raft-store.sync-logtrue强制日志落盘使P99延迟稳定在130ms±10ms。数据库1000并发P99延迟网络延迟5ms时P99长文本写入毛刺率关键调优参数PolarDB85ms120ms3.2%innodb_log_file_size256MAurora62ms340ms0.8%aurora_replica_status1TDSQL-C48ms95ms0.3%分片键强制路由TiDB110ms290ms1.5%raft-store.pd-heartbeat-tick-interval500ms实测结论TDSQL-C在纯写入场景下稳定性最优但依赖业务分片设计Aurora在理想网络下延迟最低但对网络质量敏感PolarDB和TiDB需针对性调参才能发挥最佳性能。对于Agent应用如果消息表能按session_id分片推荐TDSQL-C是首选若必须支持复杂关联查询则TiDB的HTAP能力更合适。3. 向量检索延迟抖动RAG场景下的真实性能博弈AI/Agent的RAG检索增强生成模块对数据库的向量检索能力提出严苛要求单次查询需在100ms内返回Top-K相似结果且P95延迟波动不能超过±30ms。否则用户会感知到“思考卡顿”。我们用FAISS生成100万条128维向量导入各数据库的向量扩展模块PolarDB-PGVector、Aurora-PostgreSQL插件、TDSQL-C的向量索引、TiDB的ANN插件执行相同查询SELECT * FROM knowledge_base WHERE embedding - [0.1,0.2,...] 0.65 ORDER BY embedding - [0.1,0.2,...] LIMIT 50。3.1 PolarDB-PGVector的索引构建与内存管理PolarDB基于PostgreSQL的PGVector扩展使用IVF-Flat索引。其优势在于索引构建速度快100万向量建索引仅需8分钟但内存消耗巨大。当查询阈值设为0.65时需扫描约15万个候选向量PolarDB会将这些向量全量加载到shared_buffers中。我们观察到当shared_buffers不足时系统频繁触发pg_stat_bgwriter的buffers_checkpoint事件导致延迟抖动达±85ms。解决方案是预留专用内存将shared_buffers设为总内存的40%原为25%并设置work_mem64MB使向量计算在内存中完成。经验PolarDB的pg_stat_progress_create_index视图可实时监控向量索引构建进度但默认不暴露详细状态。需在postgresql.conf中添加track_activitieson和track_countson才能获取完整指标。3.2 Aurora向量插件的存储层协同缺陷Aurora的向量插件基于PostgreSQL在存储层做了深度优化向量数据与元数据分离存储查询时仅加载元数据页。这使其在阈值0.78时P95延迟仅92ms。但问题在于“阈值敏感性”——当阈值放宽到0.65需扫描的向量数量激增存储层无法高效过滤导致大量无效数据页被加载。我们抓取IO栈发现iostat -x显示await值从8ms飙升至42ms证实存储层成为瓶颈。Aurora官方文档建议阈值不低于0.75但这与RAG实际需求冲突。3.3 TDSQL-C向量索引的分布式查询瓶颈TDSQL-C的向量索引基于HNSW算法单分片查询性能优秀P9578ms。但Agent知识库通常跨多个分片按topic分片查询需广播到所有分片。当分片数超过8个时协调节点需聚合各分片结果并重排序P95延迟跳升至210ms。我们通过“分片预筛选”优化先用BM25算法在协调节点快速过滤无关分片再将向量查询下发使P95降至125ms。3.4 TiDB ANN插件的Region感知优化TiDB的ANN插件最大优势是Region-aware它能识别向量数据所在的Region位置避免跨Region网络传输。在100万向量均匀分布于10个Region时P95延迟稳定在88ms±12ms。但需注意TiDB的tidb_enable_vectorized_expressionON必须开启否则向量计算退化为逐行CPU运算延迟暴涨至1.2秒。我们还发现TiDB的tidb_ann_max_result_size参数默认为1000当RAG需要Top-200结果时需手动调大否则返回结果被截断。数据库阈值0.78 P95延迟阈值0.65 P95延迟延迟抖动范围关键限制PolarDB92ms185ms±85msshared_buffers内存占用高Aurora92ms320ms±140ms存储层扫描效率骤降TDSQL-C78ms210ms±65ms跨分片查询需广播TiDB88ms115ms±12ms必须开启向量化表达式实测结论TiDB在向量检索稳定性上碾压其他三者尤其适合阈值动态调整的RAG场景PolarDB适合阈值固定且内存充足的环境Aurora和TDSQL-C需接受阈值范围限制。我们最终选择TiDB因为Agent的相似度阈值需根据用户query长度动态计算短query用0.75长query用0.6只有TiDB能无缝支撑这种变化。4. 跨AZ故障恢复速度7x24服务的生命线验证AI/Agent应用没有维护窗口任何单AZ故障都必须在30秒内完成服务切换。我们模拟了四种故障场景计算节点宕机、存储节点不可用、网络分区、主库脑裂并测量各数据库从故障发生到新主库提供读写服务的时间RTO及数据丢失量RPO。4.1 PolarDB的存储层高可用机制PolarDB的RTO为12-18秒RPO≈0。其原理是当主计算节点故障Proxy层检测到心跳超时默认3秒后立即发起Failover流程。新主节点从共享存储加载最新Redo Log因存储层实时同步Log无丢失然后应用Log恢复内存状态。但存在一个隐藏风险如果故障发生在Redo Log写入存储层的瞬间可能丢失最后一批未刷盘的日志。我们通过SHOW ENGINE INNODB STATUS观察到在极端情况下RPO可达200ms。实操技巧PolarDB的pg_stat_replication视图中sync_state字段标识同步状态但默认不刷新。需在监控脚本中加入SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn() FROM pg_stat_replication每5秒轮询一次比Proxy心跳更早发现异常。4.2 Aurora的Quorum-Based故障转移Aurora采用Quorum机制6个存储节点中只要4个在线即可提供服务。当AZ故障导致2个节点离线剩余4个节点自动组成新QuorumRTO仅8-12秒RPO0。但问题在于“脑裂防护”——Aurora依赖AWS CloudWatch的健康检查若CloudWatch自身延迟可能导致误判。我们在压测中人为制造CloudWatch延迟15秒观察到故障转移被推迟至23秒且出现短暂双主。4.3 TDSQL-C的强一致仲裁机制TDSQL-C的RTO为15-25秒RPO0。它使用Paxos协议要求多数派3节点中2个确认才能提交事务。当AZ故障导致1个节点离线剩余2节点仍可正常服务。但Failover过程需重新选举Leader涉及元数据同步耗时较长。我们发现TDSQL-C的show tdsqld status命令输出中paxos_role字段能实时显示节点角色但需配合tdsqlctl check工具才能获取完整状态。4.4 TiDB的Multi-Raft故障域隔离TiDB的RTO为20-30秒RPO0。其优势在于故障域隔离PDPlacement Driver将Region副本分散在不同AZ当AZ故障时PD自动将缺失副本调度到健康AZ。但PD调度需时间我们观察到从AZ故障到Region副本补全平均耗时22秒。关键优化是调整pd.config中的max-replicas3和location-labels[zone,rack]确保副本严格跨AZ分布。数据库RTO范围RPO故障检测方式关键监控命令PolarDB12-18s~200msProxy心跳Redo Log校验SELECT pg_is_in_recovery()Aurora8-12s0CloudWatch健康检查SHOW REPLICA STATUSTDSQL-C15-25s0Paxos多数派投票show tdsqld statusTiDB20-30s0PD心跳Region健康检查tiup ctl:v7.5.0 pd -u http://pd:2379 store实测结论Aurora在RTO上最优但依赖AWS生态PolarDB平衡性最好TDSQL-C和TiDB的RTO稍长但自主可控。对于混合云部署的Agent应用我们放弃Aurora选择PolarDB——因为其RTO足够满足SLA且无需绑定单一云厂商。5. 水平扩展成本拐点从千级到百万级用户的经济账AI/Agent应用的用户量可能从千级爆发至百万级数据库的扩展成本直接影响长期ROI。我们测算四种方案从1000QPS扩展到10000QPS的TCO含实例费用、存储费用、运维人力时间跨度3年。5.1 PolarDB的存储计算分离成本结构PolarDB采用“计算节点共享存储”模式扩展计算节点只需增加只读实例每实例¥1200/月存储按实际用量计费¥0.35/GB/月。从1000QPS到10000QPS我们需从2计算节点扩至8节点存储从2TB增至20TB。三年总成本约¥1.2M。但隐藏成本在于当计算节点超过6个时Proxy层成为瓶颈需升级Proxy规格¥800/月且跨节点Join性能下降30%。5.2 Aurora的Serverless模式陷阱Aurora Serverless v2看似按需付费¥0.09/ACU/hour但ACUAurora Capacity Unit的弹性粒度粗糙。在流量波峰时ACU从4升至32需12秒期间请求排队波谷时降回4需60秒造成资源浪费。我们模拟72小时流量曲线发现Serverless实际支出比固定规格高37%且无法预测峰值成本。5.3 TDSQL-C的分片扩容模型TDSQL-C按分片付费每个分片¥2000/月。从1000QPS到10000QPS需从4分片扩至20分片三年总成本¥1.44M。但扩容需停机迁移数据约2小时且分片数越多跨分片事务性能越差。我们通过“冷热分离”优化将历史消息归档到低成本对象存储仅热数据保留在TDSQL-C使分片数控制在12个以内。5.4 TiDB的弹性扩缩容实践TiDB的TiKV节点可在线增删每节点¥1500/月。从1000QPS到10000QPSTiKV从6节点扩至24节点PD和TiDB节点保持3节点不变。三年总成本¥1.08M。关键优势是扩容后无需应用改造SQL兼容性100%。我们还利用TiDB的ALTER TABLE ... SHARD_ROW_ID_BITS功能将大表按行ID分片避免热点集中。数据库1000QPS年成本10000QPS年成本扩容停机时间运维复杂度PolarDB¥320K¥480K0中需调优ProxyAurora¥280K¥520K0低全托管TDSQL-C¥380K¥600K2小时/次高需分片规划TiDB¥260K¥420K0中需PD调优实测结论TiDB在长期扩展成本上最具优势尤其适合用户量不可预测的AI/Agent产品PolarDB性价比均衡Aurora的Serverless模式在实际负载下反而更贵TDSQL-C的分片扩容成本最高。我们最终选择TiDB因为其零停机扩容能力与Agent业务的敏捷迭代节奏完美匹配。6. 综合决策树你的Agent应用该选哪个回到最初的问题PolarDB、Aurora、TDSQL-C、TiDB到底选谁答案不是“哪个最好”而是“哪个最适合你的当前阶段和约束条件”。我们用一张决策树收束所有维度是否已深度绑定AWS生态 ├─ 是 → 检查RTO要求是否≤12秒 │ ├─ 是 → AuroraRTO最优但向量检索阈值受限 │ └─ 否 → PolarDB平衡性好自主可控 └─ 否 → 检查是否已有成熟分片设计能力 ├─ 是 → TDSQL-C写入稳定性最强金融级可靠 └─ 否 → 检查是否需支持动态向量阈值 ├─ 是 → TiDB向量检索抖动最小扩展成本最低 └─ 否 → PolarDB成本适中运维门槛低我们团队最终选择了TiDB原因很实在技术债最小Agent业务刚起步没有现成分片逻辑TiDB的透明分片省去架构改造RAG体验最关键用户对响应延迟极其敏感TiDB的±12ms抖动远优于其他选项成本可预期三年TCO比PolarDB低15%且无需担心Serverless的隐性成本团队技能匹配DBA熟悉MySQL语法TiDB的兼容性让他们一周内就能独立运维。但必须坦诚TiDB的运维复杂度高于Aurora。比如PD节点故障时需手动执行tiup ctl pd -u http://pd:2379 unsafe remove-fail-store而Aurora只需在控制台点“重启”。所以如果你的团队只有1名兼职DBAAurora可能是更务实的选择——技术选型的本质是让工具适配人而不是让人适配工具。最后分享一个血泪教训我们上线TiDB后某天凌晨收到告警TiKV节点CPU飙升至95%。排查发现是RAG模块的向量查询未加LIMIT导致全表扫描。TiDB的information_schema.cluster_slow_queries视图帮我们快速定位到问题SQL但根源在于开发规范缺失。现在所有向量查询必须通过DAO层强制注入LIMIT 100并在CI阶段用SQL解析器校验。技术再先进也救不了不守规矩的代码。