摘要：本文从架构设计、存储模型、执行引擎等维度，对比 MySQL 与 Doris/SelectDB 的核心差异，清晰解释大数据场景为何需要专用 OLAP 数据库，以及这类数据库更快的根本原因，并重点说明大数据场景下严禁 `select *` 的底层逻辑。
一、MySQL 标准架构（OLTP 型）
MySQL 是面向联机事务处理设计的关系型数据库，整体为集中式架构，所有核心模块运行在单机或主从节点上。
┌─────────────────────────────────────┐ │ MySQL 核心架构 │ ├─────────────────────────────────────┤ │ 连接管理 & 权限校验 │ ├─────────────────────────────────────┤ │ SQL 解析 → 语法检查 → 查询优化器 │ ├─────────────────────────────────────┤ │ 存储引擎抽象接口 │ ├─────────────────────────────────────┤ │ InnoDB 行存储 │ BufferPool 缓冲池 │ │ B+ 树索引 │ MVCC 事务机制 │ ├─────────────────────────────────────┤ │ 本地磁盘存储 │ └─────────────────────────────────────┘
MySQL 核心特点
-
存储模式：行式存储，适合单行点查询、单行更新
-
架构模式：单机 / 主从复制，依赖垂直扩容
-
事务能力：强 ACID、行锁、表锁、MVCC
-
索引结构：B+ 树为主，对等值查询极快
-
适用规模：GB ~ 中等 TB 级数据
-
典型场景：订单系统、用户中心、支付交易等业务库
二、Doris / SelectDB 架构（OLAP 型）
Doris（SelectDB 为其商业化发行版）是面向海量数据分析的分布式 MPP 数据库，整体分为 FE 与 BE 两层，可水平无限扩展。
┌─────────────────────────────────────────┐ │ Doris 分布式架构 │ ├─────────────────────────────────────────┤ │ FE 前端节点集群 │ │ • Leader：元数据、SQL 解析、计划生成 │ │ • Follower：高可用、故障选主 │ │ • Observer：只读查询、分担压力 │ ├─────────────────────────────────────────┤ │ BE 后端节点集群 │ │ • 数据分区 + 分桶分布式存储 │ │ • 列式存储 + 高比例压缩 │ │ • 向量化执行引擎 │ │ • 多副本高可用机制 │ ├─────────────────────────────────────────┤ │ MPP 大规模并行计算 │ └─────────────────────────────────────────┘
Doris 核心特点
-
存储模式：列式存储，只读取需要的字段
-
架构模式：分布式 MPP，存算一体，水平扩容
-
执行引擎：向量化执行，CPU 批量处理数据
-
索引体系：前缀索引、分区裁剪、布隆过滤器、位图索引
-
适用规模：TB ~ PB 级海量数据
-
典型场景：实时大屏、BI 报表、用户画像、大表聚合分析
三、MySQL vs Doris/SelectDB 核心对比表
| 对比维度 | MySQL | Doris / SelectDB |
|---|---|---|
| 架构类型 | 单机 / 主从，垂直扩展 | 分布式 MPP，水平扩展 |
| 存储结构 | 行存储 | 列存储 |
| 核心定位 | OLTP 事务、点查询 | OLAP 分析、大表聚合、多维统计 |
| 数据量级 | GB ~ 中等 TB | TB ~ PB 级 |
| 执行方式 | 逐行标量执行 | 向量化批量执行 |
| 扩展能力 | 弱，分库分表复杂 | 强，加节点即可线性提升性能 |
| 事务一致性 | 强 ACID | 最终一致性，侧重高吞吐写入 |
| 典型查询延迟 | 毫秒级点查 | 亚秒 ~ 秒级海量数据分析 |
四、为什么大数据必须使用专用数据库？
1. 数据量级完全不同
-
MySQL 设计基于单机资源，数据达到 TB 级后查询严重卡顿
-
大数据场景数据量可达 PB 级，必须分布式分片存储与并行计算
2. 查询模式完全不同
- MySQL：高频、简单、单行查询
SELECT * FROM user WHERE id = 10086;
- Doris：复杂、批量、全表/大分区聚合查询
SELECT region, goods_type, SUM(amount) FROM order_detail WHERE dt BETWEEN '2024-01-01' AND '2024-12-31' GROUP BY region, goods_type;
3. 行存储不适合大数据分析
行存储必须读取整行数据，哪怕只用到一个字段，造成巨大 IO 浪费。 列存储只加载需要的列，IO 可减少 80%~95%。
五、Doris/SelectDB 为什么在大数据下更快？
1. 列式存储 + 高压缩
同类型列压缩比极高（5:1 ~ 15:1），大幅降低磁盘 IO、网络 IO。
2. MPP 分布式并行计算
大表被切分为多个分片，多节点同时计算，最后汇总结果，算力随节点线性提升。
3. 向量化执行引擎
抛弃逐行处理，采用 CPU SIMD 指令批量计算，执行效率提升 3~10 倍。
4. 多层索引快速过滤
分区裁剪、前缀索引、布隆过滤器、位图索引联合使用，实现能不扫的数据坚决不扫。
六、为什么大数据场景严禁 `select *`？
1. 废掉列存储核心优势
列存价值 = 按需取列 `select *` = 强制读取所有列 = 退化为低效行存储
2. IO 与网络流量爆炸
-
磁盘 IO 暴增
-
节点间数据传输暴增
-
内存占用飙升
查询从秒级变分钟级，甚至拖垮整个集群。
3. 无意义消耗集群资源
大量不需要的字段参与扫描、传输、反序列化，完全浪费 CPU、内存、网络资源。
正确写法示例
-- 严禁 select * from order_detail where dt = '2025-03-22'; -- 推荐 select user_id, pay_amount, create_time from order_detail where dt = '2025-03-22' group by user_id;
七、总结
-
MySQL 擅长事务，Doris 擅长分析，二者不是替代关系，而是业务架构互补。
-
大数据专用数据库更快，源于分布式 MPP + 列存储 + 向量化执行三大核心架构优势。
-
大数据开发第一准则：严禁 `select *`，否则再强的 OLAP 引擎也会被拖垮。
-
企业通用最佳实践：MySQL 承载业务 + Doris 构建实时数仓 / BI 报表。