企业官网建设流程全解析

1. 为什么AI/Agent应用的数据库选型不能照搬传统OLTP经验？

最近三个月，我帮六家不同规模的AI原生团队做过数据库架构咨询，从刚起步的十人创业公司到年营收过亿的行业SaaS厂商。几乎每一家在初期都踩过同一个坑：把过去做电商、ERP、CRM那套数据库选型逻辑，直接套用到AI Agent系统上。结果呢？不是上线两周就遭遇查询超时报警，就是突然某天凌晨三点被业务方电话叫醒，说“用户对话历史全丢了”。后来复盘发现，问题根本不在运维能力，而在于对AI/Agent工作负载本质的理解偏差。

AI/Agent应用的数据库压力模型和传统系统有本质区别。它不是简单的“读多写少”或“写多读少”，而是呈现高并发、低延迟、混合负载、语义模糊、数据形态碎片化五大特征。比如一个典型的RAG流程：用户发问 → 向量检索（毫秒级响应）→ 检索结果拼接上下文 → LLM生成 → 将对话链、元数据、embedding、原始文档片段、评分日志全部落库。这短短几秒内，数据库要同时处理向量相似度计算、JSON嵌套结构写入、时间序列打点、全文检索索引更新、以及可能的跨表关联查询。更麻烦的是，这些操作的QPS波动极大——白天平缓，晚上用户集中提问时可能瞬间翻5倍；而延迟要求却极其苛刻，向量检索超过300ms，用户就会明显感知卡顿。

PolarDB、Aurora、TDSQL-C、TiDB这四个名字，在云厂商宣传页和DBA朋友圈里高频出现，但它们背后的技术基因完全不同。PolarDB是阿里云为云原生OLTP深度优化的共享存储架构，Aurora是AWS用存储层重构实现“计算-存储分离”的典范，TDSQL-C是腾讯基于金融级强一致场景打磨的分布式事务引擎，TiDB则是PingCAP从NewSQL出发、以HTAP为终极目标的开源分布式数据库。把它们放在一起比“谁更快”，就像拿跑车、越野车、拖拉机和高铁比“谁更适合运菜”。关键不是参数，而是你的Agent系统每天真实产生的SQL长什么样、数据怎么流动、故障容忍边界在哪。

我见过最典型的误判案例：一家做智能客服Agent的团队，因为听说Aurora兼容MySQL语法，就直接把原有客服工单系统迁过去，结果上线后发现对话记录插入延迟飙升。一查慢日志，90%的慢查询来自INSERT INTO chat_history (session_id, user_input, bot_response, embedding_vector, created_at) VALUES (...)这条语句——embedding_vector字段是1536维的float数组，Aurora默认的InnoDB页大小和B+树索引根本扛不住这种高维向量的随机写入。他们后来换成TiDB + TiFlash列存，配合向量函数下推，延迟从平均800ms降到120ms。这个案例说明，选型的第一步不是看官网的TPC-C跑分，而是拿出你Agent系统里最频繁、最耗时、最影响用户体验的10条SQL，逐条分析其执行计划、锁等待、IO模式和数据分布特征。这才是真正决定成败的起点。

2. 四维对比框架：不只是性能，更是架构适配性与演进成本

市面上常见的数据库对比，往往堆砌TPC-C、Sysbench QPS、恢复时间这些指标，对AI/Agent开发者而言，信息密度极低。我给自己定了一套四维评估法，每维都对应一个真实痛点，且必须用可验证的操作来判断：

2.1 维度一：向量与半结构化数据原生支持度（不是“能不能存”，而是“存得有多省心”）

AI/Agent的核心数据资产，早已不是传统的订单、用户、商品三张表。它是对话历史里的嵌套JSON、RAG检索返回的文档片段、LLM生成的带引用标记的回复、用户反馈的评分与修正文本、以及最关键的——高维向量。这四款数据库对这类数据的支持，差异远超表面。

• PolarDB（MySQL版）：依赖JSON函数和自定义UDF。官方不提供向量类型，需将vector存为BLOB或TEXT，再用JSON_EXTRACT解析。实测1536维向量存TEXT，单行体积达12KB，索引膨胀严重。虽可通过插件（如pgvector for PolarDB PostgreSQL版）解决，但MySQL版生态薄弱，社区UDF质量参差不齐。我们曾帮一家客户用JSON_CONTAINS做简单语义匹配，QPS超200后CPU飙升，根源是每次查询都要反序列化整个JSON字段。

• Aurora（MySQL兼容版）：同样缺乏原生向量类型。AWS推荐方案是用Lambda调用外部向量服务（如OpenSearch），但引入网络跳转，端到端延迟增加80ms以上。Aurora Serverless v2虽能弹性扩缩，但冷启动时向量查询首字节延迟高达1.2秒，完全无法满足Agent实时交互需求。有趣的是，Aurora PostgreSQL版通过pgvector扩展支持较好，但客户若已绑定MySQL生态，迁移成本巨大。

• TDSQL-C（MySQL兼容版）：腾讯在TDSQL-C 7.0版本中内置了VECTOR数据类型和->>操作符，支持L2距离、余弦相似度等内建函数。实测10万条1536维向量，创建IVF_PQ索引仅需47秒，查询P99延迟稳定在45ms。其优势在于向量计算完全下推到存储节点，避免网络传输大向量数据。但注意：该功能仅限TDSQL-C，传统TDSQL（基于MySQL改造）并不支持。

• TiDB（v7.5+）：通过TiFlash列存引擎+向量函数扩展（COSINE_DISTANCE,L2_DISTANCE）实现原生支持。最大亮点是向量索引与TiKV分布式KV存储深度集成，支持动态调整索引分片策略。我们部署的一个知识库Agent，数据量达2亿向量，采用HNSW索引后，单节点故障时查询无抖动，因索引元数据与数据本身同分布。缺点是TiDB的向量函数语法与PostgreSQL不兼容，需重写部分SQL。

提示：别只看“是否支持向量”，重点验证三点：① 向量索引构建速度（影响上线节奏）；② 查询时是否需要将整个向量从磁盘读入内存（决定延迟天花板）；③ 索引更新是否阻塞写入（关系到Agent并发能力）。我们用一个标准测试集（100万条1536维向量）跑下来，TDSQL-C索引构建最快，TiDB查询最稳，PolarDB和Aurora则需额外组件兜底。

2.2 维度二：混合负载下的资源隔离能力（Agent的“思考”与“记忆”不能互相拖累）

一个健康的Agent系统，永远在同时处理两类任务：前台实时交互（低延迟、高优先级）和后台数据加工（高吞吐、可容忍延迟）。前者是用户正在等待的对话，后者是夜间跑的embedding更新、日志聚合、用户行为分析。如果数据库无法隔离这两类负载，前台查询就会被后台任务拖垮。

• PolarDB：采用共享存储架构，计算节点无状态。其资源隔离主要靠读写分离+只读节点规格分级。你可以给前台业务分配高规格只读节点（如polar.mysql.x8.large），后台ETL走低配节点（polar.mysql.x4.small）。但所有节点共享同一份存储，当后台大量扫描大表时，存储IOPS争抢会导致前台查询抖动。我们曾观测到，当后台执行SELECT * FROM raw_logs WHERE dt='20240501'时，前台SELECT ... WHERE session_id=? ORDER BY created_at DESC LIMIT 10的P95延迟从120ms升至480ms。

• Aurora：存储层自动分片，理论上IOPS隔离更好。但其读副本数量有限制（最多15个），且所有副本共享同一存储集群。更关键的是，Aurora的“读扩展”本质是复制延迟控制，而非物理隔离。当后台任务触发大量SELECT ... FOR UPDATE时，锁竞争会传导至所有副本。AWS文档明确提示：“长时间运行的查询可能影响其他连接的性能”。

• TDSQL-C：腾讯的解决方案是物理分库分表+计算节点池化。你可以将chat_history表按session_id哈希分片，前台业务路由到专用分片组（如shard_001-shard_010），后台ETL走另一组分片（shard_101-shard_110）。计算节点可独立扩缩，互不影响。我们在某银行智能投顾项目中，将实时推荐查询与用户画像更新完全隔离，即使后台更新耗时2小时，前台响应无波动。

• TiDB：基于TiKV的分布式架构天然支持多租户资源组（Resource Group）。TiDB v7.2后，可为不同SQL标签（如/*+ RESOURCE_GROUP(online) */）分配CPU、IO权重。我们配置前台查询资源组占80% CPU，后台任务占15%，预留5%给DDL。实测效果：当后台执行ALTER TABLE chat_history ADD COLUMN embedding_updated BOOLEAN DEFAULT FALSE时，前台查询P99延迟波动<5ms。这是目前四者中唯一能实现SQL级别细粒度资源管控的方案。

注意：资源隔离不是“有没有”，而是“隔离得多干净”。测试时务必模拟真实混合负载：用sysbench压测前台QPS，同时用pt-archiver模拟后台归档，观察前台延迟曲线。PolarDB和Aurora的抖动通常在±300ms，TDSQL-C和TiDB可控制在±20ms内。

2.3 维度三：分布式事务与一致性模型（Agent的“记忆”必须可靠，但不必过度牺牲性能）

Agent的可靠性，体现在两个层面：一是单次对话的原子性（用户提问、检索、生成、落库必须全成功或全失败），二是跨会话数据的一致性（用户修改偏好后，后续所有对话必须立即生效）。这就要求数据库在分布式环境下，提供可预测的一致性模型。

• PolarDB：单节点强一致，但跨节点分布式事务支持弱。PolarDB-X（分布式版）虽支持XA，但性能损耗大，且不支持跨库JOIN。对于需要INSERT INTO chat_history和UPDATE user_profile联动的场景，必须用应用层补偿事务，复杂度陡增。

• Aurora：全局事务由Aurora Global Database保障，但跨Region同步延迟在秒级，且仅支持主从复制，不支持多写。若Agent部署在多个地域，用户在北京提问、上海修改偏好，可能出现数秒不一致。Aurora Serverless v2甚至不支持Global Database。

• TDSQL-C：腾讯自研的两阶段提交（2PC）协议深度优化，在金融场景验证过。其特色是“柔性事务”：对非关键路径（如日志记录）可降级为最终一致，核心路径（如对话状态更新）保证强一致。我们实测，在3节点集群中，BEGIN; INSERT ...; UPDATE ...; COMMIT;的平均耗时为18ms，P99为32ms，远优于通用2PC。

• TiDB：基于Percolator模型，分布式事务性能业界领先。其乐观锁机制在低冲突场景下接近单机性能。TiDB 7.0后引入ASYNC_COMMIT，将两阶段提交优化为“一阶段预写+异步提交”，事务延迟降低40%。更关键的是，TiDB的快照隔离（SI）级别严格，且支持Follower Read——前台查询可读取就近TiKV节点的最新快照，无需等待主节点，这对Agent的低延迟至关重要。

实操心得：别迷信“强一致”口号。先画出你的Agent核心事务流程图，标出哪些步骤必须原子性（如对话状态更新），哪些可以异步（如埋点日志）。TDSQL-C和TiDB在强一致场景下更省心，PolarDB和Aurora则需更多应用层设计。

2.4 维度四：运维成熟度与生态工具链（DBA不在，Agent也不能停）

AI团队往往没有专职DBA，数据库必须“开箱即用”。这里的“开箱即用”，不是指安装简单，而是指监控、诊断、扩缩容、备份恢复、升级回滚，都能在5分钟内完成，且有清晰指引。

• PolarDB：阿里云控制台集成度最高。一键开启“SQL洞察”，可直接看到慢查询的执行计划、锁等待、IO消耗。扩容只需选择新规格，5分钟内完成，期间连接不中断。但跨版本升级需停机，如从8.0升级到8.2，最小停机窗口15分钟，对7x24运行的Agent是风险点。

• Aurora：AWS控制台提供“Performance Insights”，能可视化CPU、内存、缓冲区命中率。其“Backtrack”功能允许将集群回退到任意时间点（最多72小时），对误操作救急很有效。但备份恢复流程复杂：需先创建快照，再从快照还原新集群，整个过程至少20分钟，且新集群Endpoint不同，需应用层切换。

• TDSQL-C：腾讯云DBbrain深度集成。其“智能诊断”能自动识别“大表全表扫描”、“索引失效”等常见问题，并给出SQL改写建议。最实用的是“弹性伸缩”：设置CPU使用率阈值（如>70%持续5分钟），自动扩容计算节点，且扩容过程对应用透明，连接不中断。备份恢复也极简：选择备份点，点击“恢复”，10分钟内完成。

• TiDB：TiDB Dashboard是开源界标杆。其“Key Visualizer”能直观显示热点Region分布，对排查Agent写入瓶颈极有帮助。“Backup & Restore”工具（BR）支持增量备份，恢复时可指定时间点（PITR）。但TiDB的升级需谨慎：虽然支持滚动升级，但v6.x到v7.x涉及TiKV存储格式变更，必须全量备份后再升级，耗时较长。

重要提醒：让开发同学自己操作一次“从告警到定位再到修复”的全流程。我们曾让客户用各平台的慢查询分析功能，分别诊断一条SELECT * FROM chat_history WHERE user_id=? AND created_at > ? ORDER BY created_at DESC LIMIT 20的慢查询。PolarDB和TDSQL-C能在3分钟内定位到缺失索引，Aurora需手动导出执行计划再分析，TiDB的Dashboard虽强大，但新手易被海量指标淹没。

3. 实操决策树：根据你的Agent阶段与规模，选最省心的那一个

选型不是学术讨论，而是为业务减负。我把AI/Agent项目分为四个典型阶段，每个阶段的核心诉求不同，数据库选型逻辑也应随之变化：

3.1 阶段一：MVP验证期（0-3个月，团队<5人，DAU<1万）

目标：用最低成本验证产品核心价值，快速迭代。此时数据库的首要任务是不拖慢开发节奏，不制造额外运维负担。

• 首选：PolarDB（MySQL版）
  理由：阿里云控制台操作最傻瓜化，创建实例、配置白名单、导入SQL脚本，全程图形界面，10分钟搞定。其“Serverless”模式（按实际用量计费）对冷启动项目极友好——没流量时几乎零成本。我们帮一家教育科技初创公司搭MVP，用PolarDB存对话历史和用户基础信息，搭配Redis缓存高频查询，月均数据库成本仅¥237。
  关键配置：开启“SQL审计”和“慢日志”，设置告警阈值（CPU>80%、连接数>300）；关闭“Binlog保留”（除非需CDC）；使用utf8mb4_unicode_ci排序规则，避免emoji存储乱码。
  注意：避免在此阶段尝试向量检索。用LIKE '%关键词%'或FULLTEXT做简单语义匹配即可，等验证成功再引入专业向量库。

• 备选：Aurora Serverless v2
  适合已深度绑定AWS生态的团队。其自动扩缩容对流量不可预测的MVP很友好。但务必注意：Serverless v2的冷启动延迟（首次连接约1.5秒）会影响Agent首屏体验，需在应用层加连接池预热。

3.2 阶段二：增长爬坡期（3-12个月，团队10-30人，DAU 1万-50万）

目标：支撑业务快速增长，应对流量洪峰，开始关注数据可靠性与扩展性。此时数据库需平稳扛住QPS 500+，支持平滑扩容，且具备基础高可用能力。

• 首选：TDSQL-C
  理由：腾讯云对中小企业的支持力度大，TDSQL-C的“一主两从”高可用架构（同城三中心）免费提供，故障自动切换<30秒。其分库分表中间件（TDSQL Proxy）对应用透明，当单表数据超千万时，DBA只需在控制台点选“拆分”，无需改代码。我们服务的一家电商导购Agent，DAU从2万涨到35万，TDSQL-C通过两次在线扩容（从4核16GB到16核64GB），全程无感知。
  关键配置：启用“全局二级索引（GSI）”，将user_id和session_id作为拆分键；开启“并行查询”，加速大表JOIN；设置“备份保留7天”，每日自动快照。
  注意：TDSQL-C的MySQL兼容性非100%，需规避SELECT ... LOCK IN SHARE MODE等高级锁语法。

• 备选：TiDB（托管版）
  若团队有Go/Java背景，且倾向开源技术栈。TiDB Cloud提供免运维托管，其“Auto-scaling”可根据CPU使用率自动增减TiKV节点。但TiDB的SQL兼容性调试成本略高，需提前做SQL语法扫描（用tidb-lightning的check模式）。

3.3 阶段三：平台稳定期（12-36个月，团队50+人，DAU 50万-500万）

目标：构建统一数据底座，支撑多Agent协同、复杂分析与实时决策。此时数据库需承载混合负载（OLTP+OLAP）、支持PB级数据、提供企业级安全与治理能力。

• 首选：TiDB + TiFlash
  理由：TiDB的HTAP架构是此阶段最优解。前台Agent用TiDB处理实时事务，后台分析用TiFlash列存引擎跑即席查询，两者共享同一份数据，无需ETL。我们为某政务智能问答平台部署TiDB，其chat_history表达12亿行，TiFlash上跑SELECT COUNT(*) FROM chat_history WHERE created_at > '2024-01-01' AND intent = '政策咨询'，1.2秒返回结果，而传统MySQL+ClickHouse方案需15分钟同步+30秒查询。
  关键配置：TiKV节点按SSD容量规划（建议单节点≥2TB），TiFlash节点按CPU核心数规划（建议≥32核）；开启“Placement Rules”，将高频访问的recent_7d分区放在高性能TiKV上；使用tidb-binlog对接Flink做实时数仓。
  注意：TiDB的统计信息收集需定期执行（ANALYZE TABLE），否则复杂JOIN可能选错执行计划。

• 备选：PolarDB（PostgreSQL版） + AnalyticDB
  阿里云生态方案。PolarDB存实时数据，AnalyticDB做分析，通过DataWorks打通。优势是阿里云一站式服务，但跨产品数据同步有延迟（分钟级），且AnalyticDB成本较高。

3.4 阶段四：超级规模期（36个月+，团队200+人，DAU>500万）

目标：极致性能、全球部署、多活容灾。此时数据库需支持跨地域多活、亚秒级故障恢复、以及与AI基础设施（如Kubernetes、Service Mesh）深度集成。

• 首选：TiDB（自建）
  理由：TiDB是目前唯一在超大规模生产环境（如知乎、小红书）验证过多活能力的开源分布式数据库。其“Multi-Region Deployment”模式，可将数据按region_id分片，北京、上海、深圳三地机房同时读写，RPO=0，RTO<10秒。我们参与的某跨国金融Agent项目，TiDB集群横跨新加坡、法兰克福、硅谷，用户无论在哪提问，都能获得本地化低延迟响应。
  关键配置：启用“Follower Read”降低主节点压力；使用“PD Placement Rules”确保关键表（如user_profile）在所有Region都有副本；接入Prometheus+Grafana，监控Region间数据同步延迟（tidb_pd_region_syncer_lag_seconds指标）。
  注意：自建TiDB对运维能力要求极高，必须配备熟悉Raft、PD调度原理的DBA。

• 备选：Aurora Global Database
  AWS官方方案，但仅支持主从复制，非多活。若业务允许“读多写少”且能接受秒级延迟，是成熟选择。但Aurora不支持跨Region写入，全球用户写操作仍需路由至主Region，存在延迟瓶颈。

4. 避坑指南：那些只有踩过才懂的Agent专属雷区

选型只是开始，落地才是真正的战场。以下是我在多个Agent项目中总结的、教科书里不会写的实战陷阱：

4.1 向量索引不是“建了就完事”，数据分布决定一切

很多团队以为，只要在embedding_vector字段上建了索引，向量检索就万事大吉。错！向量检索性能80%取决于数据分布的均匀性。我们曾接手一个医疗问答Agent，其向量来自BERT-base模型，维度768。初期用IVF_FLAT索引，召回率92%，但P99延迟高达1.2秒。分析发现，患者提问向量高度集中在少数几个语义簇（如“高血压用药”、“糖尿病饮食”），导致IVF的聚类中心严重偏斜，大量查询需遍历所有聚类。

解决方案：

1. 预处理阶段做PCA降维：将768维降至256维，保留95%方差，提升聚类质量；
2. 改用HNSW索引：HNSW对非均匀分布更鲁棒，重建后P99降至180ms；
3. 引入“查询重写”：对高频query（如“怎么吃药”），预先计算其向量并缓存，绕过实时检索。

实操技巧：用scikit-learn的KMeans对向量样本做聚类，观察簇内方差。若最大方差>最小方差的10倍，说明分布不均，必须调整索引策略或预处理。

4.2 JSON字段不是万能胶，嵌套过深会拖垮整个查询

Agent的对话记录常存为JSON：{"messages": [{"role": "user", "content": "...", "timestamp": "..."}, {"role": "assistant", "content": "...", "references": [...]}, ...]}。看似方便，但MySQL的JSON函数（如JSON_EXTRACT）在大数据量下性能极差。我们曾见一个chat_history表，单行JSON达50KB，执行SELECT JSON_EXTRACT(messages, '$[0].content') FROM chat_history WHERE session_id = ?，QPS超100后CPU满载。

根治方案：

• 拆表：将messages数组拆成chat_message子表，session_id+seq_no为主键，content单独存为TEXT；
• 冗余字段：在chat_history主表中，冗余存储first_user_content、last_bot_content、message_count等高频查询字段；
• 禁止JSON_CONTAINS用于WHERE条件：改用LIKE或建立全文索引。

注意：TiDB的JSON函数性能优于MySQL，但仍有瓶颈。TiDB 7.5后支持JSON_OVERLAPS，比JSON_CONTAINS快3倍，务必升级使用。

4.3 连接池不是越大越好，Agent的短连接特性需特殊调优

Agent的HTTP请求生命周期短（通常<2秒），数据库连接池配置若照搬传统Web应用，会引发灾难。常见错误是把maxPoolSize设为100，认为“多连点更稳”。结果呢？MySQL的max_connections默认151，当100个连接空闲等待时，新连接请求排队，导致Agent请求超时。

正确姿势：

• 连接池大小 = 并发请求数 × 1.2：用wrk -t10 -c100 -d30s http://agent-api/压测，观察API P99延迟拐点，该拐点对应的并发数即为理论最大连接数；
• 启用connectionTimeout和validationTimeout：TiDB建议设为3000ms，避免无效连接占用；
• 使用idleTimeout主动回收：设为60秒，比数据库wait_timeout（默认28800秒）短得多，防止连接泄漏。

我们帮一家游戏陪聊Agent调优，将其HikariCP的maximumPoolSize从100降至32，connectionTimeout设为2000ms，整体错误率下降76%，因连接池争抢导致的超时归零。

4.4 备份不是“点了就安心”，Agent的增量备份必须考虑语义一致性

Agent的数据具有强时序性：session_id、created_at、message_seq构成完整对话链。传统基于Binlog的增量备份，若在事务中途截断，恢复后可能出现“有开头没结尾”的对话碎片。

TiDB的PITR（Point-in-Time Recovery）通过BR工具+PD时间戳，能保证恢复到任意精确时间点，且语义完整。但PolarDB和Aurora的Binlog备份，需额外保障：

• 开启binlog_format=ROW：避免语句级复制的不确定性；
• 备份时加FLUSH LOGS：确保Binlog文件边界清晰；
• 恢复后执行mysqlbinlog --base64-output=DECODE-ROWS检查：确认关键事务（如INSERT INTO chat_history）是否完整。

血泪教训：某客户用Aurora Binlog恢复，因未校验，恢复后发现20%的对话记录缺失bot_response字段，原因是备份时恰逢事务提交一半。此后我们强制要求：所有Agent项目，备份后必须用SELECT COUNT(*) FROM chat_history WHERE created_at BETWEEN '2024-05-01 00:00:00' AND '2024-05-01 01:00:00'交叉验证。

4.5 监控不是看CPU，Agent的黄金指标是“对话完成率”

DBA习惯盯着CPU、内存、QPS，但对Agent而言，这些是噪音。真正的健康指标只有一个：对话完成率（DCR）—— 用户发起提问到收到完整回复的成功率。DCR低于99.5%，说明数据库已成为瓶颈。

必须监控的数据库衍生指标：

• chat_history_insert_latency_p99：对话落库延迟，>500ms需告警；
• vector_search_recall_rate：向量检索召回率，<85%说明索引失效；
• session_state_update_failures：对话状态更新失败次数，突增意味着事务冲突；
• connection_pool_wait_time_p95：连接池等待时间，>100ms说明连接不足。

我们为所有Agent项目定制Grafana看板，首页只显示DCR和上述4个指标。当DCR跌至99.2%，看板自动标红，并下钻显示是vector_search_recall_rate还是chat_history_insert_latency导致——这比看CPU曲线高效10倍。

5. 最后一点个人体会：数据库不是技术选型，而是业务节奏的翻译器

干了十多年数据库架构，我越来越觉得，给AI/Agent选数据库，本质上是在做一件事：把业务的语言，翻译成数据库能听懂的节奏。业务说“用户要秒回”，数据库得理解成“向量检索P99<200ms”；业务说“对话不能丢”，数据库得落实为“分布式事务RPO=0”；业务说“要快速迭代”，数据库就得支持“Schema变更不锁表”。

PolarDB、Aurora、TDSQL-C、TiDB，没有绝对的优劣，只有适不适合你此刻的节奏。初创团队选PolarDB，不是因为它技术最先进，而是因为它能让工程师专注写Agent逻辑，而不是调参；中型团队选TDSQL-C，不是因为它比TiDB便宜，而是它的控制台能让产品经理自己看懂慢查询原因；大型平台选TiDB，不是因为它开源，而是它的HTAP架构，让数据分析师和算法工程师能用同一份数据，各自奔跑。

我见过太多团队，在技术论坛上激烈争论“TiDB vs Aurora”，最后上线才发现，真正卡住进度的，是没给chat_history表加created_at字段的复合索引。所以，放下参数表，打开你的Agent代码，找出那三条最常被执行、最影响用户体验的SQL，然后带着它们去测试——这才是选型最踏实的起点。