周传炽1. 面试官问这个问题，真正想听的是“定位差异”
前几天一个准备跳槽的朋友面试回来，跟我吐槽：“面试官问我 MySQL 和 Doris 的架构区别，我讲了十分钟存储引擎、执行引擎、副本机制，结果他最后说我没答到点上。”我问他面试官是怎么追问的，他说面试官只问了一句：“如果业务里同时有事务需求和报表需求，你怎么选？”
这句话才是题眼。
面试官问“MySQL 和 Doris 的架构区别”，表面上是考察你对两个数据库的了解程度，实际上是想看你有没有能力做技术选型。一个只会背文档的人能说出“MySQL 是行存储、Doris 是列存储”，但只有真正在项目里踩过坑的人，才能说清楚“为什么线上库不能拿 MySQL 跑聚合报表”“为什么 Doris 不适合做高频点查”——这两件事背后的原因，才是架构区别的本质。
先给一个总纲式的结论，后面展开讲：
- MySQL 是 OLTP 引擎，为高并发、低延迟、强事务的在线交易场景设计，核心是 B+树聚簇索引 + 行存储 + 主从复制，单机瓶颈明显。
- Doris 是 MPP OLAP 引擎，为海量数据下的多维分析、聚合查询、报表场景设计，核心是 FE/BE 分布式架构 + 列式存储 + 向量化执行 + 物化视图，能把一条 SQL 拆到几十台机器上并行跑。
这两个答案各占一半，但只答到这里还不够。面试官真正想听的是：你能不能用“一条 SQL 在这两个引擎里各自怎么执行”来把差异讲透？你能不能把“select * 被禁止”这件事和列式存储的裁剪机制联系起来？这些才是架构区别在实践里的投射。
这篇我会按照面试问答的逻辑来梳理，先拆架构，再讲性能来源，最后把“为什么大数据禁止 select *”这件事的账算清楚，末尾给出一套可以直接用的答题框架。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从一条SQL的执行路径拆 MySQL 和 Doris 的架构
架构区别如果只停留在“一个单机一个分布式”，那跟没答一样。最好的思路是：拿一条 SQL 分别走一遍两个引擎，看它们在哪一步分道扬镳。
假设有一条查询：
sql复制SELECT region, SUM(amount)
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY region;
2.1 存储引擎层：B+树聚簇索引 vs 列式 Tablet
在 MySQL（InnoDB）里，orders 表的数据按主键顺序组织在 B+树的叶子节点上，每一行所有字段连续存放在一起，这叫聚簇索引，也是行式存储的典型形态。执行这条 SQL 时，InnoDB 扫描 order_date >= '2024-01-01' 对应的索引（如果有的话），或者干脆全表扫描，然后把命中的每一行完整读进内存，再逐行计算 SUM(amount)。
这意味着两个问题：
- 就算你只需要
region和amount两个字段，行式存储也得把整行数据（比如 50 个字段）全部从磁盘搬到内存。 - 整个扫描过程只有一个线程在做，即使你开了 32 核 CPU，MySQL 也只利用其中一个核来执行这条 SQL。主从复制只解决读扩展问题，单条查询仍然跑在一台机器上。
在 Doris 里，orders 表的数据会被水平切分成Tablet，按照哈希或范围分桶规则分布到多个 BE（Backend）节点上，每个 Tablet 默认 3 副本。存储格式是列式的：region 这一列的所有值连续存放，amount 这一列的所有值连续存放，互不干扰。
所以同样这条 SQL，Doris 的 Scan 节点只需要读取 order_date、region、amount 这三列的数据块，其他 47 列连碰都不会碰。单表数据量有数十亿行，这个差别会直接放大到 IO 层面。
| 维度 | MySQL (InnoDB) | Doris |
|---|---|---|
| 存储模型 | 行式存储，聚簇索引组织 | 列式存储，Tablet 分片分布式存放 |
| 单条查询执行 | 单线程执行，最多并行复制读 | MPP 多节点并行，每个 BE 多线程扫描 |
| 数据压缩 | 页级压缩，通用算法 | 列级编码（RLE、字典、ZigZag 等），压缩率高得多 |
| 适合场景 | 高频增删改、事务型点查 | 大宽表聚合、多维筛选、报表分析 |
2.2 节点角色：单机执行 vs FE/BE 分布式调度
MySQL 的架构在节点层面很简单：一个主库负责写，若干从库通过 binlog 同步负责读，客户端连接任何一个节点执行 SQL，SQL 就只在这个节点上跑完。加从库能扛更多读请求，但单条慢查询该多慢还是多慢。
Doris 则把节点拆成了两个角色：
- FE（Frontend）：负责接收 SQL、解析、生成执行计划、调度查询、管理元数据。FE 之间通过选举机制选出一个 Leader，其他 FE 作为 Follower/Observer 提供元数据读服务，相当于“大脑”。
- BE（Backend）：负责数据存储和查询执行。BE 节点之间通过一致性协议同步副本，查询时每个 BE 把自己负责的那部分 Tablet 扫描完，再把中间结果往上层汇总，相当于“手脚”。
还是那条 GROUP BY region 的 SQL。Doris 的 FE 会把它拆成多个 Fragment（执行片段），每个 Fragment 分配到多个 BE 上并行执行，BE 先本地扫描、本地预聚合，再把结果 Shuffle 到上层 Fragment 做最终汇总。一个 10 个 BE 的集群，理论上可以把扫描和聚合任务拆成几十甚至上百个并行任务。
面试时只需要记住一个核心差异：MySQL 是“一个人干完所有活”，Doris 是“一个包工头把活拆开，让一群人同时干”。 这个比喻对面试官说出口，他基本就知道你是真的理解分布式执行的含义。
2.3 事务与一致性：ACID 强事务 vs 多副本最终一致
MySQL 的看家本领是事务。InnoDB 通过 redo log、undo log、MVCC、锁机制提供完整的 ACID 保证，一个订单扣库存、锁库存、更新订单状态，必须在一个事务里做到要么全成功要么全失败。这也是为什么交易系统至今离不开 MySQL 这类关系型数据库。
Doris 在事务上做了取舍。它支持单导入作业的原子性（一个导入事务要么全部可见，要么全部不可见），也支持多副本的强一致性读取（通过 Quorum 协议保证读取到最新版本），但不支持跨多张表、跨多个导入作业的分布式事务。如果你要在 Doris 里同时更新一张订单表和一张库存表，且要求要么都成功要么都失败，它是做不到的。
这种取舍是 OLAP 引擎的必然选择。分析型场景的特点是“批量导入、高频查询”，而不是“高频小事务”。Doris 把设计重心放在了导入吞吐和查询性能上，牺牲了跨表事务能力，换来的是几十亿行数据里做聚合还能秒级返回。
面试时问自己一个问题：如果你的业务要求“写 Doris 之后立刻能在另一张表里查到”，那 Doris 不一定是最优解，因为跨表一致性需要在上游用别的机制保证。能说出这一层，说明你真的理解 OLTP 和 OLAP 的边界在哪里。
2.4 索引与数据组织：InnoDB 二级索引 vs Doris 的排序键
MySQL InnoDB 的索引很好理解：主键是聚簇索引，叶子节点存整行数据；二级索引（普通索引）叶子节点存主键值，查询时先走二级索引找到主键，再回聚簇索引取整行，这叫回表。索引覆盖能避免回表，但覆盖的范围有限。
Doris 没有传统意义上的二级索引（1.2 版本起支持了倒排索引，也支持 Bloom Filter 索引，但机制不同）。它把建表时指定的 KEY 列作为排序键，数据在 Tablet 内按排序键有序排列。查询时如果 WHERE 条件命中了排序键的前缀，Doris 可以借助有序特性做二分查找，快速跳过大量无关数据——这和日常翻字典的原理一样，知道首字母就能跳过一大半页。
这意味着什么呢？在 Doris 里建表时选排序键，和 MySQL 里建索引同样重要，甚至更重要。 MySQL 的索引加错了顶多查询慢一点，Doris 的排序键选错了，整张表的查询都会慢，而且改排序键要重建表。
3. Doris 压过 MySQL 的分析性能来自哪里
面试官问完架构区别，大概率会接着问：“那 Doris 为什么快？它快在哪里？”这个问题的答案不是一个点，而是一条链路。
3.1 MPP 调度：把一条 SQL 拆成多机并行任务
Doris 的快，第一个来源是MPP（Massively Parallel Processing）架构。FE 生成执行计划时，会把一个查询拆成多个 Fragment，并发调度到多台 BE 上执行。每个 BE 内部还有线程池，同一台机器上多个扫描线程并行扫不同的 Tablet。
以 10 亿行数据、10 个 BE 节点为例，如果数据均匀分布，每个 BE 只需要扫描 1 亿行；如果每个 BE 有 8 核 CPU 并行扫描，相当于单机扫描的数据量降到了 1250 万行。这种水平扩展能力是 MySQL 做不到的——MySQL 即使挂 10 个从库，单条 SQL 还是在其中一个节点上执行。
一个很容易被忽略的细节是：MPP 调度不是免费的，它涉及节点间的数据 Shuffle（重分布）。比如 GROUP BY region 这种聚合查询，每个 BE 先做本地预聚合，再把聚合后的结果按 region 重新分发到对应节点做最终聚合，这中间的中间结果越多，网络开销越大。所以 Doris 的优化器很重视下推和预聚合，把能提前过滤、提前聚合的操作尽量推到扫描阶段完成。
3.2 向量化执行和列式压缩的乘法效应
Doris 的快，第二个来源是向量化执行引擎。传统 MySQL 的存储引擎和 SQL 执行层用的是迭代器模型，每行数据都要经过一遍函数调用、类型判断、表达式计算，CPU 的大部分时间其实花在了函数调用开销上，而不是真正的计算上。
向量化执行不一样。它一次处理一批数据（比如 1024 行），同一列的数据连续放在内存里，CPU 可以像流水线一样批量计算——SIMD 指令集就能用上，比如一次比较 8 个数值、一次累加 8 个字段。Doris 从 1.2 版本开始默认启用向量化执行引擎，官方数据显示，向量化之后典型的聚合查询能比非向量化版本快 3 到 5 倍，这个数字在我自己的压测里也基本吻合。
列式压缩给向量化执行加了第二层增益。列式存储天然适合压缩，因为同一列的数据类型一致、取值范围相近，重复值高的列用 RLE（Run-Length Encoding）压缩，基数低的用字典编码，浮点数列用 ZigZag 编码。同样是 100 GB 的原始数据，行式存储压缩完可能还有 40 GB，列式存储能压到 10 GB 甚至更低。磁盘读取量小了，IO 压力就小了，查询速度自然快。
3.3 物化视图命中：把预计算结果直接拿来用
Doris 的快，第三个来源经常被面试官拿来当加分项问：物化视图（Rollup）。
物化视图的本质是“把查询结果提前算好存起来”。比如你的报表每天都要跑 SELECT region, SUM(amount) FROM orders GROUP BY region，基础表有 10 亿行，每次跑都要扫全表。如果建立了一个按 region 分组的物化视图，数据导入时就把聚合结果算好了，查询直接扫物化视图——数据量可能只有几万行，速度差几个数量级。
物化视图命中的关键是前缀匹配。物化视图的排序列是原表排序列的前缀，比如原表排序列是 (order_date, region, channel)，那创建 (order_date, region) 的物化视图就能被 WHERE order_date = ? AND region = ? 的查询命中；如果查询按 channel 过滤，前缀匹配不上，物化视图就废了。
这里有一个业务选型上的坑：物化视图不是越多越好，每个物化视图在导入时都要额外计算一次，导入速度会下降。我见过一个团队为了“把所有查询都优化到极致”，建了十几个物化视图，最后数据导入慢到不可接受。物化视图应该只建给高频查询用，低频分析直接跑基础表。
3.4 选型边界与“Doris 替换 ES”的真实场景
聊到这里，你已经能理解为什么很多团队在日志分析场景用 Doris 替换 Elasticsearch（ES）了。ES 擅长全文检索，但在聚合统计、SQL 生态、存储压缩率上不如 Doris 直观：ES 的聚合需要扫描大量倒排索引，内存消耗高；Doris 的列式存储加上 SQL 接口，日志分析这种“写多读少、按时间范围聚合”的场景刚好打到优势上。
但“替换 ES”是有边界的。Doris 支持倒排索引和全文检索（包括中文分词），但它的全文检索在复杂查询语法、相关性算分上跟 ES 还有差距。你要是做“搜索关键词之后按相关性排序”的产品搜索，ES 依然是更好的选择；你要是做“从几亿条日志里筛出某几个条件的记录并统计趋势”，Doris 的性价比确实更高。
对 MySQL 来说，Doris 不是替代关系，而是互补关系。交易数据存在 MySQL，把同步链路接到 Doris 做分析，这是目前最常见的数据架构。Doris 有专门的 MySQL 协议兼容层，下游 BI 工具连 Doris 跟连 MySQL 几乎一样，迁移成本比想象中低很多。网上那些“doris mysql 实时同步”的资料，讲的其实就是这一类链路。
4. 大数据“禁止select *”不是洁癖，是一笔成本账
面试如果到这里还没结束，第二个高频追问马上就来：“既然 Doris 是列式存储，为什么还要求 SELECT 只带必要字段？为什么大数据团队普遍禁止 select *？”
这个问题看着简单，但能答得完整的人不多。大多数人只会说“select * 浪费 IO”，这个答案太浅了，我来把账一笔一笔算清楚。
4.1 IO 放大的倍数账：1 个字段和 200 个字段的差距
先做一个计算。假设一张订单表有 200 个字段，每行平均 1 KB，全表 10 亿行，总数据量约 100 GB。
SELECT id, amount FROM orders WHERE ...，只需要读 2 个字段，按 1% 的数据占比算，读取量 1 GB。SELECT * FROM orders WHERE ...，200 个字段全读，读取量 100 GB。
一条只差一个星号的 SQL，磁盘读取量差了 100 倍。即使命中率降低一点，几十倍的差距是跑不掉的。这个数据报给面试官，比空洞地说“浪费 IO”要有说服力得多。
在 Doris 这类列式存储里，情况更极端。SELECT * 会把所有列的数据块全部加载，包括那些根本没参与过滤、聚合、排序的字段。如果这张表里有几个字段存的是超长文本（比如 JSON、备注、HTML 片段），select * 会把整张表变成慢查询重灾区——我见过一个案例，某平台一张表加了两个 VARCHAR(5000) 的字段之后，一条本来 200 ms 能跑完的查询，因为代码里写了 select *，直接涨到 8 秒。
4.2 列式存储的裁剪机制被 select * 锁死
Doris 的列式存储有一个关键优化：列裁剪。查询需要的列越少，需要读取的数据块就越少。还有谓词下推：WHERE 条件里涉及的列，会提前到扫描阶段做过滤，只把满足条件的行传给上层算子。
这两个优化都建立在“明确需要哪些列”的基础上。一旦写了 select *，列裁剪直接失效，所有列都被读上来，谓词下推虽然还能帮你过滤行数，但过滤之后仍然要传输所有列。
面试中你可以这样表达：select * 让列式存储最引以为傲的两个优化，一个彻底废掉，一个作用减半。 这句话一出来，面试官基本能确认你不只是知道“不要用 select *”这个规则，而是知道规则背后的原理。
4.3 内存、网络和 Shuffle 的三重浪费
列裁剪只是表象，真正的成本在后面。
Doris/Spark 这类 MPP 引擎里，select * 出来的数据要被 Shuffle 到聚合节点做最终计算。数据越多，Shuffle 的数据量越大，网络带宽占用越高，下游节点接收数据的压力也越大。如果 SQL 里还带 ORDER BY 或 JOIN，数据还要进内存排序或 Hash 表。
举一个我实际碰到过的例子。一个数仓团队跑日活报表，SQL 里 select * from 用户表 关联行为表，用户表 3 亿行、每行 80 个字段，实际只需要 5 个字段做关联和统计。改为明确列名之后，Shuffle 数据量从 24 GB 降到 1.5 GB，整个任务从 40 分钟缩减到 9 分钟。没改 SQL 逻辑，没加计算资源，只是改掉了星号。
如果你的任务经常 OOM（Doris 有挺多 OOM 案例，核心原因大都是数据进入内存的量超出预期），排查时先看一眼是不是某条频率很高的 SQL 写了 select *，这个方向往往比调内存参数更有效。
4.4 隐性风险：Schema 演进和 insert as select
select * 还有一个更隐蔽的问题：Schema 演进。表结构不是不变的，加列、改列是常态。如果线上代码写的是 select * 然后按位置取字段，上游表一加列，下游可能取错数据，或者结果集会带上预期之外的字段，如果下游是写死的 Schema 就可能直接报错。
同样的风险在 INSERT INTO ... SELECT * 里更容易炸。MySQL 里两表 select * 互相插入，依赖的是列顺序一致；两边列顺序对不上，数据就插错了。网上很多人用 CREATE TABLE new_table AS SELECT * FROM old_table 来做备份，这个操作在小表上问题不大，但大表场景下我会建议改为显式列名，并且尽量避免从线上大表直接拉全量。
顺带说一句，MySQL 里 select * 单看性能惩罚没有 Doris 那么明显，因为行式存储天然要读整行，加了索引覆盖之后还能接受。但到了大数据体系里，一行几十个字段、一表几亿行是常态，星号带来的量级差异才会被放大到不可忽视。这也是面试题把“MySQL 与 Doris 架构区别”和“禁止 select *”放在一起问的用意——同一个写法，在不同架构里的代价完全不同。
4.5 别把锅全扣在 select * 上
最后泼一盆冷水：光禁止 select * 解决不了所有性能问题。 我见过有的团队把 select * 全改成显式列名之后，查询还是很慢，因为真正的问题在别处——排序键选错、物化视图没命中、数据倾斜、Join 没有等值条件。禁止 select * 是最容易执行的规范，但它只是底线，不是万能药。
面试到这一步，你别只顺着面试官的话说“对，应该禁止 select *”，你可以补一句：“这只是成本账的一部分，更重要的是通过列裁剪把数据量降下来之后，配合排序键和物化视图，才能把列式存储的优势全部发挥出来。”这句话会把你们从“背规则”带向“聊架构优化”，面试官的好感度完全不一样。
5. 面试现场怎么答：从第一句话到追问的攻防
讲完原理，最后给一套可以直接用的答题框架，以及我陪练过很多次之后总结出的追问应对方式。
5.1 答题骨架：结论先行，三层展开
当面试官抛出“MySQL 与 Doris 的架构区别”时，建议你这样组织回答：
第一层，给定位。 一句话说清本质：MySQL 是 OLTP 行式存储数据库，为事务型在线服务设计；Doris 是 MPP OLAP 分析型数据库，为海量数据聚合分析设计。定位不同，决定了后续所有架构差异。
第二层，讲机制。 从存储模型、执行模型、事务能力、扩展方式四个维度展开：
- 存储模型：MySQL 是 B+树聚簇索引 + 行存储，Doris 是列式存储 + Tablet 分布。
- 执行模型：MySQL 单条查询单节点执行，Doris 一条查询拆成多任务在多个 BE 并行执行。
- 事务能力：MySQL 完整 ACID，Doris 单导入原子性 + 副本一致性，不支持跨表事务。
- 扩展方式：MySQL 主从复制 + 分库分表，Doris 加 BE 节点水平扩展，数据自动均衡。
第三层，给结论。 丢一句临门一脚：实际项目里通常不是二选一，而是 MySQL 承载在线事务，通过同步链路把数据导入 Doris 做分析，两边各干各擅长的事。
这三层讲完大概三分钟，信息密度足够，又不会变成背文档。面试官如果还想深入，自然会沿着某一层往下追问。
5.2 面对追问：不要背官网口径
追问一：“Doris 的 FE 和 BE 分别是什么？”
支线答案：FE 是元数据管理和查询规划节点，Leader 负责写元数据，Follower/Observer 提供读，BE 负责存储和计算。重点补充一个细节：FE 的元数据通过 BDB JE 实现高可用，BE 之间通过一致性协议保证 Tablet 副本一致，理解这个才能理解 Doris 的扩展边界。
追问二：“Doris 的 Unique 模型和 Aggregate 模型有什么区别？”
支线答案：Aggregate 模型是导入时或查询时按聚合函数合并，适合 SUM、MAX 这类预聚合场景；Unique 模型保证主键唯一，适合更新场景。Doris 2.0 后 Unique 模型默认走 Merge-On-Write，导入时就完成合并，查询时不需要读多版本再做合并，性能明显更好。能说出 MOW 和 MOR 的区别，这是加分的深度。
追问三：“你说 select * 浪费 IO，那为什么 MySQL 8.0 里 select * 还能用？”
支线答案：MySQL 是行存储，聚簇索引天然携带整行数据，读多列和读整行的 IO 差距不大。但覆盖索引场景下 select 指定列可以避免回表，这就是 MySQL 里也会建议按需取列的原因。而大数据引擎里列存储 + 列裁剪的收益是指数级的，所以“禁止 select *”才成为硬性规范。能区分“行存储的代价”和“列存储的代价”，说明你是真的理解了。
5.3 结合项目经历：把架构说成你踩过的坑
如果你有真实项目经验，哪怕只是一个 demo，也要尽量用在你身上发生过的事情来承载回答。面试官想听的不是教科书，而是“你有没有被某个问题折磨过、怎么解决的”。
你可以说：“我之前在项目里维护过一个 Doris 集群，刚开始建表排序键选错了，导致某个报表查询要扫全表，后来把最常用的等值筛选条件放进排序键前缀，查询从 3 秒降到 300 ms。”也可以说：“有一次线上 MySQL 慢查询，排查发现是团队习惯 select *，一个 200 字段的表在报表接口里全量查询，改成字段列表之后接口 P99 明显下降。”
把自己定位成一个“踩过坑、看过性能报表、调过参数”的工程师，而不是一个“看过官方文档”的读者，这个区别在面试里非常明显。如果你确实没接触过 Doris，也照实说“我了解原理但生产环境用得少”，然后主动把话题引导到你知道的 MySQL 优化细节上——真诚地展示已知边界，比硬编一个好得多。
结尾
我自己把这道题从“背答案”到“真正想明白”，其实是花了一段时间的。最大的体会是：MySQL 和 Doris 的架构区别，最好的理解方式不是背一张对比表，而是拿一条 SQL、一张表、一个业务场景，分别想一想它在两种引擎里会发生什么。面试官问 select *，真正想考察的也不只是 SQL 规范，而是你有没有理解不同存储引擎的代价模型。
最后分享一个对面试和实际工作都有用的小技巧：多看看 EXPLAIN 输出的执行计划，MySQL 看过、Doris 也看过之后，你会发现 SQL 优化这件事的原理是相通的——无非是减少扫描数据量、减少中间结果、让计算尽量下推。搞懂了这一个核心，架构层面的差异在你眼里就会变成一套自然的推理，而不是需要死记硬背的考点。