摘要本文从架构设计、存储模型、执行引擎等维度对比 MySQL 与 Doris/SelectDB 的核心差异清晰解释大数据场景为何需要专用 OLAP 数据库以及这类数据库更快的根本原因并重点说明大数据场景下严禁 select * 的底层逻辑。一、MySQL 标准架构OLTP 型MySQL 是面向联机事务处理设计的关系型数据库整体为集中式架构所有核心模块运行在单机或主从节点上。┌─────────────────────────────────────┐ │ MySQL 核心架构 │ ├─────────────────────────────────────┤ │ 连接管理 权限校验 │ ├─────────────────────────────────────┤ │ SQL 解析 → 语法检查 → 查询优化器 │ ├─────────────────────────────────────┤ │ 存储引擎抽象接口 │ ├─────────────────────────────────────┤ │ InnoDB 行存储 │ BufferPool 缓冲池 │ │ B 树索引 │ MVCC 事务机制 │ ├─────────────────────────────────────┤ │ 本地磁盘存储 │ └─────────────────────────────────────┘MySQL 核心特点存储模式行式存储适合单行点查询、单行更新架构模式单机 / 主从复制依赖垂直扩容事务能力强 ACID、行锁、表锁、MVCC索引结构B 树为主对等值查询极快适用规模GB ~ 中等 TB 级数据典型场景订单系统、用户中心、支付交易等业务库二、Doris / SelectDB 架构OLAP 型DorisSelectDB 为其商业化发行版是面向海量数据分析的分布式 MPP 数据库整体分为 FE 与 BE 两层可水平无限扩展。┌─────────────────────────────────────────┐ │ Doris 分布式架构 │ ├─────────────────────────────────────────┤ │ FE 前端节点集群 │ │ • Leader元数据、SQL 解析、计划生成 │ │ • Follower高可用、故障选主 │ │ • Observer只读查询、分担压力 │ ├─────────────────────────────────────────┤ │ BE 后端节点集群 │ │ • 数据分区 分桶分布式存储 │ │ • 列式存储 高比例压缩 │ │ • 向量化执行引擎 │ │ • 多副本高可用机制 │ ├─────────────────────────────────────────┤ │ MPP 大规模并行计算 │ └─────────────────────────────────────────┘Doris 核心特点存储模式列式存储只读取需要的字段架构模式分布式 MPP存算一体水平扩容执行引擎向量化执行CPU 批量处理数据索引体系前缀索引、分区裁剪、布隆过滤器、位图索引适用规模TB ~ PB 级海量数据典型场景实时大屏、BI 报表、用户画像、大表聚合分析三、MySQL vs Doris/SelectDB 核心对比表对比维度MySQLDoris / SelectDB架构类型单机 / 主从垂直扩展分布式 MPP水平扩展存储结构行存储列存储核心定位OLTP 事务、点查询OLAP 分析、大表聚合、多维统计数据量级GB ~ 中等 TBTB ~ 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 报表。
面试被问：MySQL 与 Doris/SelectDB 的架构区别。 大数据为什么禁止select *。
摘要本文从架构设计、存储模型、执行引擎等维度对比 MySQL 与 Doris/SelectDB 的核心差异清晰解释大数据场景为何需要专用 OLAP 数据库以及这类数据库更快的根本原因并重点说明大数据场景下严禁 select * 的底层逻辑。一、MySQL 标准架构OLTP 型MySQL 是面向联机事务处理设计的关系型数据库整体为集中式架构所有核心模块运行在单机或主从节点上。┌─────────────────────────────────────┐ │ MySQL 核心架构 │ ├─────────────────────────────────────┤ │ 连接管理 权限校验 │ ├─────────────────────────────────────┤ │ SQL 解析 → 语法检查 → 查询优化器 │ ├─────────────────────────────────────┤ │ 存储引擎抽象接口 │ ├─────────────────────────────────────┤ │ InnoDB 行存储 │ BufferPool 缓冲池 │ │ B 树索引 │ MVCC 事务机制 │ ├─────────────────────────────────────┤ │ 本地磁盘存储 │ └─────────────────────────────────────┘MySQL 核心特点存储模式行式存储适合单行点查询、单行更新架构模式单机 / 主从复制依赖垂直扩容事务能力强 ACID、行锁、表锁、MVCC索引结构B 树为主对等值查询极快适用规模GB ~ 中等 TB 级数据典型场景订单系统、用户中心、支付交易等业务库二、Doris / SelectDB 架构OLAP 型DorisSelectDB 为其商业化发行版是面向海量数据分析的分布式 MPP 数据库整体分为 FE 与 BE 两层可水平无限扩展。┌─────────────────────────────────────────┐ │ Doris 分布式架构 │ ├─────────────────────────────────────────┤ │ FE 前端节点集群 │ │ • Leader元数据、SQL 解析、计划生成 │ │ • Follower高可用、故障选主 │ │ • Observer只读查询、分担压力 │ ├─────────────────────────────────────────┤ │ BE 后端节点集群 │ │ • 数据分区 分桶分布式存储 │ │ • 列式存储 高比例压缩 │ │ • 向量化执行引擎 │ │ • 多副本高可用机制 │ ├─────────────────────────────────────────┤ │ MPP 大规模并行计算 │ └─────────────────────────────────────────┘Doris 核心特点存储模式列式存储只读取需要的字段架构模式分布式 MPP存算一体水平扩容执行引擎向量化执行CPU 批量处理数据索引体系前缀索引、分区裁剪、布隆过滤器、位图索引适用规模TB ~ PB 级海量数据典型场景实时大屏、BI 报表、用户画像、大表聚合分析三、MySQL vs Doris/SelectDB 核心对比表对比维度MySQLDoris / SelectDB架构类型单机 / 主从垂直扩展分布式 MPP水平扩展存储结构行存储列存储核心定位OLTP 事务、点查询OLAP 分析、大表聚合、多维统计数据量级GB ~ 中等 TBTB ~ 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 报表。
