问题

“我们有 MySQL 了，为什么还要 Doris？”

“Doris 号称 HTAP，是不是可以把 MySQL 省了？”

这两个问题本质上是同一个困惑：OLTP 和 OLAP 的边界在哪里，Doris 有没有在抹平这条线？

先理清概念

OLTP（在线事务处理）= MySQL 的主场。 特点是：大量小事务、高并发读写、毫秒级响应、强一致性。

OLAP（在线分析处理）= Doris 的主场。 特点是：少量大查询、批量扫描、秒级响应可接受、最终一致性通常够用。

MySQL 做 OLAP 查询（比如”统计过去一年每个品类的日均销量”）慢的原因不是 MySQL 写得不好，而是它用的索引结构（B+ Tree）和存储格式（行存）根本不是为扫描设计的。行存意味着即使你只查两个字段，它也要把整行读出来。

Doris 用的是列存。列存意味着只读查询需要的列，跳过其他所有数据。同时 Doris 的 MPP（大规模并行处理）架构可以把一个查询拆成多份，在多台机器上并行跑，然后汇总。

HTAP 在抹平这条线吗？

HTAP（Hybrid Transactional/Analytical Processing） 是近年热词，意思是一个数据库同时做 OLTP 和 OLAP。

Doris 确实在往这个方向走。从 2.1 的 Unique Key 模型（支持 Merge-on-Write 实现更新）到 3.x 的存算分离，再到 4.x 的 AI 能力，Doris 在努力让”分析”这件事更实时。

但 HTAP 不等于一个数据库包办一切。实践中：

  • Doris 的写入走的是批量导入（Stream Load、Routine Load、Insert Into），不是 MySQL 那种逐行事务写入。
  • Doris 不支持 MySQL 级别的事务隔离。它的更新模型是”标记删除 + 追加新版本”，跟 MySQL 的 MVCC 不是一回事。
  • Doris 的优势在”大宽表扫描 + 聚合”，不是”按主键点查一百次”。

所以，”Doris 替代 MySQL”是个伪命题。它们解决的是不同问题。

真实的分工

在一个典型的数据密集型后端里，MySQL 和 Doris 的分工是这样的：

环节 MySQL Doris
用户下单 写事务，保证一致性 —
实时库存查询 点查，毫秒返回 —
每日销售报表 — 凌晨从 MySQL 同步，批量计算
用户行为分析 — Kafka 实时灌入，多维聚合
后台管理列表 分页查询 + JOIN —
运营大盘 — 实时看板，多维度下钻

中间那层”数据怎么从 MySQL 到 Doris”，就是数据同步管道（Canal → Kafka → Doris Routine Load 是一套经典方案）。

什么时候不需要 Doris？

如果你的分析查询规模不大——比如几十万行、几个维度、响应时间要求不严——MySQL 的分析能力其实够用。加个合适的索引，写个 GROUP BY，跑几秒钟也能出结果。

Doris 的引入成本不只是部署。还包括：

  • 数据同步管道的运维
  • 两套查询语法的学习（虽然都兼容 MySQL 协议，但优化思路完全不同）
  • 数据一致性监控

架构的复杂度是负债，不是资产。 只有在 MySQL 确实扛不住分析负载时，才值得引入 Doris。

什么时候 MySQL 真的扛不住了？

几个信号：

  • GROUP BY 查询从秒级变成分钟级
  • 分析查询开始影响在线业务（CPU/IO 争抢）
  • 需要实时多维度下钻，MySQL 建索引的速度跟不上查询需求的变化
  • 数据量大到单表无法放内存，全表扫描成为常态

出现这些信号时，就该认真考虑 Doris 了。

意味着什么

  1. MySQL 和 Doris 不是互斥关系，是上下游关系。 MySQL 负责”产生数据”，Doris 负责”理解数据”。
  2. HTAP 的目标不是用一个数据库替代两个，而是让”分析”离”产生”更近。 但这个”近”是分钟级到秒级的缩短，不是让分析师直接往 MySQL 里跑全表扫描。
  3. 理解两者的存储引擎设计（行存 vs 列存、B+ Tree vs MPP）比记住 SQL 语法差距更重要。 这是在遇到性能问题时做出正确架构决策的基础。

一句话：MySQL 管”记”，Doris 管”看”。别让 MySQL 去做 Doris 的事，也别指望 Doris 接 MySQL 所有的活。