1. 这不是选数据库是选一套数据处理逻辑开篇直击本质Doris 和 ClickHouse这两个词最近在数据团队的会议室里出现频率高得离谱。我上个月帮三家不同行业的客户做实时数仓架构选型每次聊到“我们到底该用 Doris 还是 ClickHouse”会议室里总会陷入一种微妙的沉默——不是没人发言而是每个人说的“理由”都像隔靴搔痒有人说“ClickHouse 查询快”有人接话“但 Doris 写入更稳”还有人翻着文档念“Doris 支持物化视图ClickHouse 要靠 ReplacingMergeTree 模拟”。听起来都对但没一个能让人拍板“就它了”。问题出在哪出在大家默认把它们当成了“同构产品”来比参数。就像拿电饭煲和空气炸锅比“谁加热更快”——它们确实都用电但设计目标、工作路径、适用场景根本不在一条线上。Doris 的核心设计哲学是“让 OLAP 查询像 OLTP 一样简单可靠”它从第一天起就把自己嵌进 MySQL 协议栈、兼容标准 SQL、内置事务协调器、默认开启自动 Compaction而 ClickHouse 的基因是“单点极致吞吐”它把所有资源押注在列式压缩、向量化执行、稀疏索引这三把刀上连 JOIN 都默认禁用写入走的是异步批量追加后台合并的“非即时一致性”路径。所以这张表不是罗列差异而是还原它们各自在真实生产环境里“怎么活下来”的底层逻辑。比如“SQL 兼容性”这一项表面看都是支持标准 SQL但 Doris 的INSERT INTO SELECT默认走两阶段提交失败可回滚ClickHouse 同样语句实际触发的是异步写入后台 Merge中间任何环节崩溃你得自己查_tmp表、手动清理、重试。这不是 Bug是设计选择——前者为业务系统兜底后者为吞吐率让路。再比如“湖仓一体”这个热词现在人人都喊但 Doris 的 External Table 是直接对接 Hive Metastore S3/HDFS元数据变更秒级可见建表语句里写ENGINEHive就能当本地表用ClickHouse 的File或S3引擎则要求你手动维护分区路径、显式指定格式、甚至要自己写ALTER TABLE ... ADD COLUMN去同步 Hive 字段变更。前者是“湖即仓”后者是“湖仓分治”。这张表背后真正决定选型的从来不是 QPS 数字而是你的团队有没有人愿意每天凌晨三点爬起来修 Merge 失败的分区或者能不能接受 BI 工程师写的LEFT JOIN在 Doris 里跑出 200ms在 ClickHouse 里直接 OOM。我把这六个维度拆开不讲理论只说上周刚踩过的坑、监控截图里的真实毛刺、以及运维同学发给我的那条带时间戳的钉钉消息“Doris BE 节点磁盘用了 92%但SHOW PROC /frontends显示 FE 内存只占 45%——这俩压根不共享内存池啊”2. 核心差异全景拆解6 个维度背后的工程真相2.1 架构模型分布式协同 vs 单机引擎集群Doris 采用Shared-Nothing Coordinator-Worker 分层架构FEFrontend负责元数据管理、SQL 解析、查询规划、任务调度BEBackend专注存储与计算。FE 是无状态的可水平扩展BE 是有状态的每个节点独立持有数据分片。关键在于FE 和 BE 之间通过 Thrift 协议通信所有查询计划由 FE 统一生成后下发到 BE 执行BE 之间通过 RPC 直接交换中间结果如 Shuffle 数据。这意味着 Doris 的查询是“中心调度边缘执行”天然支持复杂多表 JOIN、子查询嵌套、窗口函数下推。ClickHouse 则是单机引擎集群化部署。每个节点既是存储又是计算没有中心调度器。当你执行SELECT * FROM table1 JOIN table2 ON ...ClickHouse 实际上是在每个节点上分别读取本地分片的table1和table2然后在本节点内存中完成 JOIN除非用Distributed引擎跨节点广播小表。它的分布式能力完全依赖Distributed引擎的路由规则而这个引擎本身不参与计算只做请求转发和结果合并。因此ClickHouse 的 JOIN 性能高度依赖数据分布策略——如果JOIN键和DISTRIBUTED BY键不一致就会触发全量数据广播网络带宽瞬间打满。提示Doris 的 FE 不参与计算所以 FE 节点 CPU 使用率常年低于 30%而 ClickHouse 的每个节点都在疯狂计算CPU 峰值常达 90%。这意味着 Doris 的扩容更“精准”——查不动了加 BE管不动了加 FEClickHouse 扩容则是“整机复制”新节点加入后必须等数据 Replicate 完才能承接流量期间旧节点压力不减反增。实操对比某电商客户要做“用户行为宽表关联商品维度”Doris 直接CREATE TABLE user_behavior AS SELECT u.*, p.category FROM user_log u JOIN product_dim p ON u.pid p.pid耗时 8.2 秒ClickHouse 同样语句在 16 节点集群上跑了 47 秒监控显示 3 个节点网卡被打满至 98%最终因内存不足被 Kill。后来改用Distributed引擎预聚合才压到 12 秒但代价是每天多跑 3 个定时任务维护预聚合表。2.2 数据写入模型强一致性事务 vs 最终一致性追加Doris 的写入走两阶段提交2PC协议。当你执行INSERT INTO table VALUES (...)FE 先协调所有相关 BE 节点预留写入资源类似数据库的 Prepare 阶段全部成功后才统一 Commit。如果某个 BE 在 Commit 阶段宕机FE 会持续重试直到超时然后主动 Rollback 其他节点已 Prepare 的数据。这种机制保证了“要么全成功要么全失败”且失败后不会留下脏数据碎片。ClickHouse 的写入是纯异步追加 后台 Merge。INSERT语句只是把数据块写入磁盘的_tmp目录然后立即返回成功。真正的数据可见性取决于后台 Merge 线程何时将_tmp中的块合并到主分区并更新parts元数据。这个过程可能延迟几秒到几分钟且 Merge 可能因磁盘空间不足、内存溢出、索引冲突而失败失败后_tmp块不会自动清理需要 DBA 手动干预。注意Doris 的INSERT默认开启enable_insert_strict遇到类型转换失败、NULL 插入非空字段等情况直接报错ClickHouse 默认容忍这些错误把异常行转成默认值如字符串变空串、数字变 0导致数据质量隐患肉眼难查。实操细节某金融客户要求“交易流水写入后 1 秒内可查”Doris 开箱即用满足ClickHouse 则必须调大background_pool_size默认 16、降低merge_tree的parts_to_throw_insert参数默认 300并配合SYSTEM FLUSH DISTRIBUTED强制触发 Merge但即便如此仍有约 0.3% 的批次延迟超 2 秒。他们最后在应用层加了一层 Kafka 缓冲用 Flink 消费后按分钟级微批写入才勉强达标。2.3 查询执行引擎向量化 MPP vs 纯向量化 单机Doris 的执行引擎是MPPMassively Parallel Processing架构查询计划被切分成多个 Fragment片段每个 Fragment 包含算子 DAG如 Scan - Filter - HashJoin - Agg由 FE 分发到多个 BE 并行执行。BE 之间通过 ExchangeNode 交换数据支持 Broadcast Join、Shuffle Join、Local Join 等多种 Join 策略。更重要的是Doris 在 BE 内部实现了完整的向量化执行器——所有算子包括复杂函数如JSON_EXTRACT、REGEXP_REPLACE都基于 SIMD 指令优化CPU 利用率峰值可达 95%。ClickHouse 的执行引擎是单机向量化引擎。它没有跨节点的 Query Plan 分发机制所有计算都在单个节点内存中完成。它的向量化做得极深从数据读取Page Cache 预加载、表达式计算LLVM JIT 编译、到聚合Streaming Aggregation全部向量化。但这也意味着当查询需要跨节点数据时如Distributed表的GROUP BYClickHouse 必须先在各节点本地聚合再把中间结果汇总到查询发起节点做最终聚合——这个“两阶段聚合”无法避免网络传输和单点瓶颈。关键区别Doris 的EXPLAIN输出能看到清晰的 Fragment 划分和 Exchange 节点ClickHouse 的EXPLAIN只显示单节点执行树看不到分布式调度逻辑。性能实测在 10 亿行订单表上执行SELECT province, count(*) FROM orders GROUP BY province ORDER BY count(*) DESC LIMIT 10Doris8 BE耗时 1.8 秒CPU 平均使用率 62%ClickHouse16 节点耗时 3.4 秒查询发起节点 CPU 达 99%其他节点平均 45%。Doris 的优势在于它把GROUP BY的 Shuffle 和 Reduce 分散到了所有 BE而 ClickHouse 的 Reduce 阶段全压在一台机器上。2.4 存储引擎与数据组织智能分区分桶 vs 手动分区跳数索引Doris 的存储基于ColumnStore 自适应分区分桶。建表时只需指定PARTITION BY如dt和DISTRIBUTED BY如user_idDoris 会自动为每个分区生成多个 Tablet数据分片每个 Tablet 内部按DISTRIBUTED BY字段哈希分桶。更关键的是Doris 的 Tablet 具备自动 Compaction 能力——当小文件Delta 文件累积到阈值后台线程会自动合并成大文件并重建 Bitmap 索引、ZoneMap 索引。整个过程对用户透明无需手动OPTIMIZE TABLE。ClickHouse 的存储依赖MergeTree 系列引擎数据按PARTITION BY划分目录每个分区下是多个part数据块。part的生成完全由写入批次决定小批次写入必然产生大量小part。ClickHouse 提供OPTIMIZE TABLE命令触发 Merge但这是个阻塞操作且 Merge 过程中part仍可读写可能导致查询看到部分合并中的数据。此外ClickHouse 的索引是跳数索引Skip Index需在建表时显式声明SKIPPING INDEX且索引粒度granularity必须与index_granularity默认 8192 行对齐否则无效。实操陷阱ClickHouse 的ALTER TABLE ... MODIFY COLUMN会重写整个分区1TB 分区可能耗时数小时Doris 的同样操作只修改元数据毫秒级生效。某客户曾因误操作在生产环境执行 ClickHouseALTER导致下游报表服务中断 4 小时。数据组织对比Doris 的SHOW PARTITIONS FROM table直接列出分区及 Tablet 数量、副本数、数据量ClickHouse 的SELECT partition, name, rows, bytes FROM system.parts WHERE databasedb AND tablet返回的是每个part的明细需人工聚合统计分区总量。Doris 的运维视角是“分区级”ClickHouse 是“part 级”。2.5 SQL 兼容性与功能完备性MySQL 生态平移 vs 自研语法扩展Doris 宣称100% 兼容 MySQL 协议这意味着连接驱动可用mysql-connector-java、pymysql、mysqlclientSQL 语法支持WITHCTE、WINDOW函数ROW_NUMBER()、RANK()、INSERT ... ON DUPLICATE KEY UPDATE、REPLACE INTODDL 支持在线ADD COLUMN、DROP COLUMN、MODIFY COLUMN事务支持START TRANSACTION、COMMIT、ROLLBACK仅针对 Unique Key 模型。ClickHouse 的 SQL 是自研方言虽借鉴了 SQL 标准但关键差异明显连接需用clickhouse-jdbc驱动不兼容 MySQL 驱动WITHCTE 仅支持简单形式嵌套 CTE 或 CTE 引用自身会报错WINDOW函数支持有限RANGE帧不支持ROWS BETWEEN是唯一选项DDL 不支持DROP COLUMN只能ALTER TABLE ... DROP COLUMN本质是重写分区无事务概念INSERT即最终写入。重点提醒Doris 的UNION ALL默认走 MPP 并行执行10 个子查询会分配到不同 BE 并行跑ClickHouse 的UNION ALL是顺序执行前一个子查询完成才启动下一个除非用UNION ALLDistributed引擎强制并行。案例某 SaaS 公司将 MySQL 数仓迁移到 OLAP 引擎原 SQL 含大量WITH t1 AS (SELECT ...), t2 AS (SELECT ...) SELECT * FROM t1 JOIN t2。Doris 无缝运行ClickHouse 报错Unsupported type of WITH clause需重写为子查询或临时表开发成本增加 3 人日。2.6 湖仓一体能力元数据直连 vs 文件路径映射Doris 的湖仓一体通过External Table实现核心是元数据联邦。建表语句CREATE EXTERNAL TABLE hive_table (id Int, name String) ENGINEHive PROPERTIES(hive.metastore.urithrift://metastore:9083, hive.databasedefault, hive.tableuser_log)。Doris 会定期默认 5 分钟拉取 Hive Metastore 的元数据变更自动同步分区列表、字段类型、SerDe 信息。查询时Doris 直接下发谓词下推Predicate Pushdown到 Hive只读取匹配分区的 ORC/Parquet 文件。ClickHouse 的湖仓一体依赖Table Function 或 Engine本质是文件路径映射。例如SELECT * FROM s3(https://bucket/path/{dt}/data.parquet, access_key, secret_key, Parquet)或CREATE TABLE s3_table (...) ENGINES3(https://bucket/path/, Parquet)。它不感知 Hive Metastore分区信息需硬编码在路径模板{dt}中字段类型、Schema 变更必须手动修改建表语句。ClickHouse 6.0 引入Hive引擎但仍需配置hive_metastore_host等参数且不支持自动分区发现必须显式指定PARTITION BY字段。关键差异Doris 的 External Table 可以和本地表JOIN执行计划中会自动选择最优路径如 Hive 表走谓词下推Doris 表走本地索引ClickHouse 的 S3 表JOIN本地表时所有 S3 数据必须先下载到本地内存再计算极易 OOM。实测某客户用 Doris 查询 Hive 中 500 个分区的用户日志总数据量 20TBWHERE dt BETWEEN 2024-01-01 AND 2024-01-07下推后只扫描 7 个分区耗时 4.3 秒ClickHouse 同样查询需先列出所有 500 个 S3 路径再逐个读取 Parquet 文件头判断分区耗时 22 秒且内存占用峰值达 16GB。3. 实战决策树什么场景该选 Doris什么场景 ClickHouse 更合适3.1 Doris 的黄金场景需要“开箱即用”的业务闭环Doris 的设计目标非常明确让业务团队能像用 MySQL 一样用 OLAP。所以当你的需求包含以下任意一项Doris 是更安全的选择BI 报表实时性要求高比如电商大促期间运营同学需要每 5 分钟刷新一次“实时 GMV 仪表盘”且不能接受查询偶尔超时或返回不一致数据。Doris 的强一致性写入 MPP 查询保证了每次刷新都是确定性结果而 ClickHouse 的 Merge 延迟可能导致同一时间点两次查询返回不同数值。SQL 开发者技能栈偏传统团队主力是熟悉 MySQL/Oracle 的 DBA 或 BI 工程师不熟悉 ClickHouse 的ARRAY JOIN、FINAL关键字、ReplacingMergeTree的特殊语义。Doris 的INSERT ... SELECT、UPDATE、DELETEUnique Key 模型语法几乎零学习成本上线周期可缩短 40%。混合负载场景同一个集群既要跑 T1 的离线 ETL大批量 INSERT又要支撑在线 API 查询高频点查。Doris 的 FE/BE 分离架构让查询和写入资源隔离BE 节点可配置不同规格查多的配高 CPU写多的配高 IOClickHouse 的单机模型下ETL 任务会抢占查询资源必须拆成两个集群运维复杂度翻倍。需要与现有生态深度集成比如已用 Flink 做实时计算希望 Flink SQL 直接INSERT INTO doris_table或已有 Spring Boot 应用只需改spring.datasource.urljdbc:mysql://doris-fe:9030/db即可接入。Doris 的 MySQL 协议兼容性让这种迁移变成配置变更而 ClickHouse 需要重写 JDBC URL、调整连接池参数、处理驱动特有异常。实操心得我们给一家在线教育公司部署 Doris 时他们原有 MySQL 数仓的 200 张报表 SQL90% 直接替换jdbc:mysql://为jdbc:mysql://doris-fe:9030/就能跑通剩下 10% 只需把DATE_FORMAT(NOW(), %Y%m%d)改成date_format(now(), %Y%m%d)函数名大小写差异。整个迁移测试只用了 3 天。3.2 ClickHouse 的制胜场景追求极致吞吐的单一目标ClickHouse 的存在意义就是把“单点查询吞吐”做到物理极限。当你的场景符合以下特征ClickHouse 可能带来数量级提升日志类海量数据秒级分析比如 CDN 厂商要分析 10 亿/天的访问日志查询模式固定为SELECT ip, count(*) FROM log WHERE time now() - 3600 GROUP BY ip ORDER BY count(*) DESC LIMIT 100。ClickHouse 的向量化执行 稀疏索引能在 1 秒内完成而 Doris 同样查询需 3~5 秒——因为 Doris 的 MPP 调度开销、FE-BE 网络传输、以及更复杂的执行计划生成对这种简单聚合反而成了负担。硬件资源极度受限比如边缘计算场景只有 4 核 16GB 的 ARM 服务器。ClickHouse 的单机轻量级部署一个二进制文件 config.xml能轻松跑起来内存占用常低于 2GBDoris 的 FE 至少需 4GB 内存BE 也需 2GB 以上同等硬件下 Doris 可能连启动都困难。数据写入模式高度规律比如 IoT 设备每 10 秒上报一次传感器数据写入批次稳定、字段固定、无乱序。ClickHouse 的ReplacingMergeTreeORDER BY (device_id, ts)能完美处理重复数据Merge 过程高效而 Doris 的 Unique Key 模型在高并发写入时主键冲突检测会成为瓶颈需额外加REPLACE语义或业务层去重。允许接受最终一致性比如舆情监控系统只要求“事件发生后 5 分钟内可查到趋势”不苛求每一秒的精确性。ClickHouse 的异步写入 Merge 延迟完全可接受且其高压缩比ZSTD能让 1TB 原始日志存成 100GB存储成本大幅降低。注意事项ClickHouse 的“快”是有前提的——查询必须能利用到索引。我们曾遇到客户用SELECT * FROM table WHERE text LIKE %keyword%在 10 亿行表上跑了 12 分钟。后来改用tokenbf_v1跳数索引 hasToken函数降到 1.2 秒。但这个优化需要 DBA 深刻理解数据分布和索引原理不是开箱即用的。3.3 混合架构不是非此即彼而是分层协作现实中很多头部企业早已放弃“二选一”转而构建Doris ClickHouse 混合架构各司其职ClickHouse 作为原始数据层Raw Layer接收 Kafka 原始日志、Flink 清洗后的宽表承担最高吞吐写入和最粗粒度的探索式查询如“全站 UV 趋势”。利用其高压缩比和单点极致性能存储成本压到最低。Doris 作为服务层Service Layer通过INSERT INTO doris_table SELECT * FROM clickhouse_table定时如每 15 分钟抽取 ClickHouse 中的聚合结果或维度表对外提供低延迟、高并发的 API 查询服务。Doris 的 MySQL 协议让 BI 工具、Web 应用无缝接入且其物化视图可自动刷新减少 ETL 作业。数据流向示例Kafka → Flink清洗/聚合→ ClickHouse存原始事实表ClickHouse定时任务→ Doris存日报/周报聚合表 用户维度表前端应用 ← Doris响应 500ms这种架构下ClickHouse 解决“数据存得下、算得快”Doris 解决“数据查得稳、用得爽”。某短视频平台采用此方案后日志查询 P95 延迟从 8 秒降至 1.2 秒ClickHouse 层API 服务 P99 延迟稳定在 320msDoris 层运维人力投入反而减少 30%——因为不再需要每天半夜处理 ClickHouse Merge 失败告警。4. 避坑指南那些文档里不会写的实战雷区4.1 Doris 的隐形门槛FE 内存与 BE 磁盘水位Doris 的 FE 节点看似无状态但元数据缓存会吃掉大量内存。默认配置下FE 会将所有 Tablet 的元数据约 2KB/个全量加载到内存。假设你有 10 万张表每张表 100 个 Tablet光 Tablet 元数据就占 2GB 内存。如果 FE 内存不足会出现OutOfMemoryError导致整个集群不可用。解决方案调大 FE JVM 参数-Xmx建议 ≥16GB并启用tablet_meta_checkpoint_interval_sec默认 300 秒控制元数据落盘频率。更激进的做法是设置max_backend_count限制 BE 节点数间接控制 Tablet 总量。BE 节点的磁盘水位更是“定时炸弹”。Doris 的 Compaction 会生成临时文件当磁盘使用率超过 85%Compaction 会降级为LOW优先级小文件堆积加速超过 90%Compaction 停止新写入拒绝。但SHOW PROC /backends只显示capacity_used_pct不区分数据盘和日志盘——很多用户把doris_be.conf的storage_root_path配在系统盘结果/var/log满了BE 直接退出。实操技巧在 BE 启动脚本中加入磁盘健康检查#!/bin/bash if [ $(df -h /data | awk NR2 {print $5} | sed s/%//) -gt 85 ]; then echo WARN: Disk usage 85% | logger -t doris-be # 触发告警或自动清理旧日志 fi4.2 ClickHouse 的“静默失效”跳数索引与分区裁剪失效链ClickHouse 的跳数索引Skip Index极易“静默失效”表现是查询变慢但日志里没有任何报错。常见原因索引粒度granularity与index_granularity不匹配index_granularity是 ClickHouse 读取数据的基本单位默认 8192 行跳数索引的granularity必须是它的整数倍。如果设GRANULARITY 1000而index_granularity8192索引实际无效。分区键未出现在WHERE条件中ClickHouse 的分区裁剪Partition Pruning只认PARTITION BY字段。比如PARTITION BY toYYYYMM(dt)但查询写WHERE dt 2024-01-01由于dt是日期类型而分区是字符串202401无法匹配导致全分区扫描。FINAL关键字滥用SELECT * FROM table FINAL WHERE ...会强制触发 Merge但FINAL只对ReplacingMergeTree有效且 Merge 过程锁表。某客户在高并发场景下滥用FINAL导致查询排队P95 延迟飙升 10 倍。排查命令用EXPLAIN indexes 1查看索引是否被使用EXPLAIN indexes 1 SELECT * FROM hits WHERE URL LIKE %google% AND EventDate 2014-03-23; -- 如果输出中没有 Using primary index 或 Using skip index说明索引未生效4.3 迁移陷阱DDL 兼容性与数据类型鸿沟从 MySQL 迁移到 Doris/ClickHouse最大的坑不在数据量而在数据类型隐式转换MySQL 的DATETIMEvs Doris/ClickHouse 的DATETIMEMySQL 的DATETIME精度是秒Doris 的DATETIME默认精度是秒但可通过DATETIME(6)支持微秒ClickHouse 的DateTime固定精度为秒DateTime64才支持纳秒。迁移时若未显式指定精度MySQL 的2024-01-01 12:34:56.123456在 Doris 中会截断为2024-01-01 12:34:56在 ClickHouse 中直接报错。字符串长度限制MySQL 的VARCHAR(255)在 Doris 中对应VARCHAR(255)但在 ClickHouse 中String类型无长度限制FixedString(255)才是等价的。如果用String存VARCHAR(255)数据后续GROUP BY时内存占用会暴增。NULL 处理差异MySQL 的COUNT(*)统计所有行COUNT(col)忽略 NULLDoris 一致但 ClickHouse 的COUNT(*)和COUNT(col)在Nullable类型下行为不同——COUNT(col)会统计NULL值必须用COUNTIf(col IS NOT NULL)才等价。迁移 checklist导出 MySQL 表结构用正则替换VARCHAR(\d)→VARCHAR($1)Doris或FixedString($1)ClickHouse对DATETIME字段Doris 加(6)ClickHouse 改用DateTime64(6)对TINYINT(1)布尔字段Doris 用BOOLEANClickHouse 用Bool全量数据导入后执行SELECT COUNT(*) FROM mysql_tablevsSELECT COUNT(*) FROM doris_table确保数值一致。4.4 性能调优的“幻觉”盲目调参不如读懂执行计划很多团队一遇到慢查询第一反应是调参数set max_threads64、set max_bytes_before_external_group_by20000000000……但实际效果甚微。真正有效的调优始于读懂执行计划Doris 的EXPLAIN分三层EXPLAIN逻辑计划→EXPLAIN PLAN物理计划含 Fragment 划分→EXPLAIN ANALYZE实际执行耗时含每个算子的 Rows、Time、Memory。重点关注ExchangeNode的数据量是否 Shuffle 过载、ScanNode的Predicates谓词是否下推、AggNode的Rows Before Agg是否提前过滤。ClickHouse 的EXPLAIN有四种模式EXPLAIN AST语法树→EXPLAIN SYNTAX重写后 SQL→EXPLAIN PLAN执行计划→EXPLAIN PIPELINE流水线详情。PIPELINE最有用能看到每个Processor的输入/输出行数、CPU 时间、等待时间。如果SourceProcessor 的Rows很大但FilterProcessor 的Rows很小说明谓词下推成功反之则失败。实操案例某查询SELECT count(*) FROM table WHERE status IN (A,B,C)在 Doris 中慢EXPLAIN ANALYZE显示ScanNode扫描了 1 亿行但FilterNode只保留 10 万行。原因是status字段未建 BloomFilter 索引。加PROPERTIES(bloom_filter_columnsstatus)后扫描行数降至 10 万耗时从 8.2 秒降到 0.3 秒。5. 常见问题速查表一线运维的真实反馈问题现象根本原因快速排查命令解决方案Doris 查询偶发超时但SHOW PROC /current_queries显示无长查询FE 节点 GC 频繁导致查询调度延迟jstat -gc fe_pid查看 GC 次数和时间调大 FE JVM-Xmx启用 G1GC-XX:UseG1GC设置-XX:MaxGCPauseMillis200ClickHouseSELECT * FROM table很快但加WHERE条件后变慢 10 倍谓词未下推或跳数索引未生效EXPLAIN PIPELINE SELECT ... FROM table WHERE ...查看FilterProcessor 输入行数检查WHERE字段是否在ORDER BY中确认跳数索引GRANULARITY设置正确用system.parts查看分区是否被裁剪Doris BE 节点磁盘使用率持续上涨SHOW PROC /backends显示used_capacity高但data_total_capacity未变Compaction 生成的临时文件未清理ls -lh /path/to/be/storage/*/tablet/*/delta_files/查看临时文件手动执行ADMIN CLEAN TRASH;清理回收站或调大min_file_remaining_time_sec默认 3600ClickHouseINSERT报错Code: 241. DB::Exception: Memory limit (total) exceededmax_memory_usage被单个查询打爆而非系统内存不足SELECT query, memory_usage, peak_memory_usage FROM system.processes ORDER BY memory_usage DESC LIMIT 5降低max_memory_usage如10000000000或用SETTINGS max_memory_usage...在 SQL 中指定DorisUNION ALL查询结果行数少于子查询行数之和子查询中有LIMITDoris 的 MPP 优化器可能提前终止部分 FragmentEXPLAIN PLAN查看各 Fragment 的LimitNode是否被下推在UNION ALL外层加LIMIT或子查询中避免LIMIT改用WHERE过滤ClickHouseDistributed表JOIN本地表时 OOMDistributed表的数据被全量拉到查询节点内存EXPLAIN PIPELINE查看RemoteProcessor 的Rows改用
