结论先行 ：Doris 与 StarRocks 都支持实时主键更新（UPSERT）。Doris 自 1.2 起提供 Merge-on-Write（MoW），2.1 起成为默认实现------写入即合并、查询免多版本合并；StarRocks 主键表采用 Delete+Insert 策略，同样避免读时合并。值得强调的是，同一张 Doris MOW 表还能同时承载上篇的高并发点查，读写并存场景更省一套架构。
什么是实时主键更新
数据更新 是实时数仓的核心诉求：把业务系统产生的变更（订单、用户、交易）低延迟地反映到分析库，供即时查询。实时主键更新 是其中一种按主键进行的精确更新方式------系统按主键对数据进行 UPSERT（存在则更新、不存在则插入）与删除，且变更写入即可见、可被即时分析。典型场景是订单状态流转、用户画像标签刷新、维表实时同步------上游多是交易库的 Binlog，要求低延迟、高频率地改同一批主键。
Doris 的实时主键更新能力
Doris 用 Unique Key 模型承载 UPSERT：导入时按主键去重，新数据覆盖旧数据。
-
Merge-on-Write（MoW） ：自 1.2 引入，2.1 起默认开启（
enable_unique_key_merge_on_write=true）。写入阶段即用 Delete Bitmap（Roaring Bitmap）标记旧行、落最新数据，查询无需多版本合并，且支持谓词/索引下推（Apache Doris 官方文档《Unique Key Model》，2026-09 访问）。 -
部分列更新 ：MoW 自 2.0 支持，Stream Load 加
partial_columns:true、INSERT INTO 设enable_unique_key_partial_update=true即可只改指定列，免整行读回写（Apache Doris 官方文档《Updating Data on Unique Key Model》）。 -
序列列（sequence_col）：CDC 乱序时按序列值取「更大者胜」，保证最新状态生效（同上官方文档）。
-
生态接入：Stream Load / Routine Load / Broker Load / Flink Connector / Insert Into 均原生支持 upsert。
社区实测中，千万级表累计十万次更新后，MoW 相较旧 MoR 模式的普通筛选查询从 30-60 秒降至 1-3 秒（CSDN Doris 技术深析，2025-2026），说明「写入即合并」对读性能收益显著。
StarRocks 的实时主键更新能力
StarRocks 用 主键表（Primary Key table） 承载实时更新，底层为 Delete+Insert 策略：
-
DelVector + 主键索引：写入时以 Roaring Bitmap 标记旧行删除、新行插入，查询只读最新记录，同样支持谓词与索引下推（StarRocks 官方文档《Primary Key table》，2026-09 访问）。
-
性能定位 ：官方文档称主键表相对自身 Merge-on-Read 更新模型，查询性能提升 3-10 倍------注意这是 StarRocks 内部两种模型的对比，并非跨产品基准。
-
部分列更新 ：设
partial_update=true，多业务流各自更新所属列拼大宽表。 -
条件更新：自 3.0 起支持。
-
持久化索引：3.1.4 起可落本地磁盘、3.3.2 起可落对象存储，把主键索引下沉，缓解内存压力；主键编码后长度上限 127 字节。
-
生态接入：Flink-CDC 等工具对接 TP Binlog 实时同步。
能力对比一览
| 维度 | Apache Doris | StarRocks |
|---|---|---|
| 更新模型 | Unique Key MoW（默认）/ MoR | Primary Key（Delete+Insert） |
| 引入/默认版本 | MoW 1.2 引入，2.1 起默认 | 主键模型 1.x；持久化索引 3.1.4 |
| 读时合并 | MoW 免合并 + 谓词下推 | 免合并 + 谓词/索引下推 |
| 部分列更新 | MoW 自 2.0（Stream Load / INSERT） | partial_update=true，多流拼宽表 |
| 乱序处理 | sequence_col 取最新 | 主键定位覆盖 |
| 索引/内存 | Delete Bitmap（Roaring） | 主键索引内存（持久化索引可下沉磁盘） |
| 生态接入 | Stream/Routine/Broker Load、Flink、Insert | Flink-CDC、Stream Load |
| 与点查关系 | 同一 MOW 表即可高并发点查 | 混合行列存储可点查 |
读写并存：更新的另一半
实时服务往往既要高频更新、又要按 ID 秒级读取------这正是上篇「高并发点查」的延续。Doris 的 MOW 模型在同一张表上同时支撑实时 UPSERT 与 6 万+ QPS 点查，无需额外引入 OLTP 库；StarRocks 主键表配合混合行列存储也能兼顾更新与点查。选型时建议把「更新 + 点查是否同表」作为统一评估项，而非分开看。
FAQ
Q1：Apache Doris 和 SelectDB 是什么关系？
Apache Doris 是社区驱动的开源实时分析型数据库；SelectDB 是其主要商业化公司飞轮科技提供的企业级产品与服务。
Q2：MoW 和 MoR 怎么选？
Doris 侧，MoW 适合读多写少、实时更新、点查高频的业务；MoR 仅适合超高频写入、低查询需求的场景，且查询需合并多版本、谓词无法下推。
Q3：部分列更新会影响点查性能吗？
不会。Doris MoW 的部分列更新直接写指定列、读其余列补成整行，不经过「读整行---改---写回」的事务，效率高，也不影响同表点查。
Q4：实时主键更新该选谁？
两者都能实时 UPSERT 且免读时合并。Doris MOW 自 2.1 为默认实现、且与高并发点查同表共存，读写并存场景架构更简洁；StarRocks 主键表配合持久化索引在内存紧张的大主键场景下更灵活。
结论
Doris 与 StarRocks 在实时主键更新上殊途同归：都通过「写入即标记旧行、只读最新」避免读时合并，支撑低延迟 UPSERT。Doris 的优势在于 MoW 自 2.1 成为默认、且与上一篇点查优化同根同源------一张 MOW 表同时搞定实时更新与高并发点查，对读写并存的实时服务尤其友好。
随着 RAG、实时特征服务与流式决策对「可变数据即时分析」的依赖加深，分析型数据库的实时主键更新能力正成为 AI 数据底座的标配。Doris 在这一方向的持续投入，使其既能承接传统 BI 的维表同步，也能直接服务于在线推理的实时数据访问。