下午三点，运营打开看板，页面转了十几秒；分析师跑一条漏斗查询，等了半分钟；数据工程师看监控，CPU 和内存都没有跑满。海量数据分析的慢，经常以这种互相矛盾的方式出现。有人主张加机器，有人主张换引擎，预算花出去，等待还在。
更有效的做法是先定义快，再定位慢。把查询时延、看板首屏、并发排队和数据新鲜度记录下来，沿着数据、模型、查询、资源和使用方式逐层排查。每一次改动都对应一个信号，也能用同一组负载验证。重复取数和跨团队等待，可以交给数据分析 Agent承接；扫描量、执行计划和资源争抢，仍要回到系统里解决。
先把“慢”拆成四个指标
同一句很慢，可能指查询执行了 30 秒，也可能指看板首屏等了 8 秒，还可能指 50 个人同时打开时排队。指标不统一，优化就会变成各说各话。
建议先建立一张基线表，连续记录高峰和低谷，至少覆盖三个工作日。P50 和 P95 分别表示一半和 95% 的请求完成时间，P95 更能反映用户实际感受到的等待。没有基线，后面的改动很难判断收益。
| 指标 | 记录内容 | 用途 |
|---|---|---|
| 数据规模 | 表行数、单日增量、扫描分区数 | 判断增长是否超出当前设计 |
| 查询时延 | 典型查询的 P50、P95、最大耗时 | 判断单条查询是稳定慢还是偶发慢 |
| 看板首屏 | 从打开到主要图表可见的时间 | 区分后端查询慢和前端加载慢 |
| 并发与排队 | 峰值并发查询数、平均排队时间、超时率 | 判断是算得慢还是等得久 |
| 资源使用 | CPU、内存、I/O、缓存命中率 | 判断瓶颈是算力还是访问模式 |
| 数据新鲜度 | 从数据产生到可查询的延迟 | 防止提速以牺牲时效为代价 |
如果只看平均耗时，少量超时会被大量快查询掩盖。P95 和超时率更能反映真实体验，资源成本也要一起记录，避免用成倍成本换一点速度。
海量数据分析慢在哪五层
分层的作用是缩小范围。先看信号，再决定查哪一层，避免一上来就改 SQL 或加机器。
| 层级 | 常见信号 | 先看什么 | 低风险动作 |
|---|---|---|---|
| 数据与存储 | 扫描数据量远大于返回数据量 | 分区裁剪、列选择、索引 | 补分区条件、只选必要列 |
| 模型 | 固定聚合反复全量计算 | 是否有预聚合、物化视图、统一口径 | 建聚合表或物化视图 |
| 查询 | 执行计划显示全表扫描、Join 过大 | 分区裁剪、函数包列、返回行数 | 改写 SQL、限制结果集 |
| 资源 | 单条查询不快，排队时间却很长 | 并发、CPU、内存、I/O | 资源隔离、并发上限、错峰 |
| 看板与使用 | 首屏慢、刷新频繁、重复取数多 | 图表数量、刷新频率、需求分布 | 减少图表、缓存、按需刷新 |
这张表可以跳层使用。单条查询一直慢，先看扫描量和执行计划；单条查询不慢、大家一起打开就慢，优先看资源和并发；昨天快今天慢，先看数据量、分区和刷新任务有没有变化。
数据量与存储布局
数据量增长会放大扫描成本，决定速度的常常是扫了多少、怎么存。
分区裁剪
如果查询条件能命中分区键，数据库可以只扫描相关分区。Doris 和 ClickHouse 的官方文档都把分区裁剪列为查询加速的基础手段。排查时用 EXPLAIN 看实际扫描了几个分区，条件里有没有对分区键做函数转换。
分区键要和最常用的过滤条件对齐。按天分区适合按时间范围查明细，按业务维度分区适合固定维度筛选。分区过细会增加元数据和小文件压力，分区过粗又起不到裁剪作用，需要结合实际查询分布设计。
列选择与索引
列式存储按列读取，查询只取需要的列，通常比 SELECT * 扫描更少。前缀索引、BloomFilter、数据跳过索引适合不同场景，先看过滤条件是否有选择性，再决定加什么索引。
索引不是越多越好。写入和维护都有成本，低选择性的列加索引，收益可能抵不过开销。先用 EXPLAIN 和 Profile 确认瓶颈在扫描、Join 还是聚合，再决定是否加索引。
结构调整的风险
改分区、加索引、重分布数据，往往要重写历史数据。先在副本或测试环境验证，保留回滚脚本，再安排低峰期执行。调整后要用同一批查询对比扫描量和 P95，不能只看单次跑得快。
模型与指标口径
很多慢查询来自重复计算。看板每天问同样几个聚合问题，却每次都从明细表重新算一遍。
物化视图把预聚合结果存下来，查询可以命中预计算结果。Doris 支持单表和多表物化视图的透明改写，ClickHouse 也把物化视图列为预聚合和加速分析查询的手段。适合固定维度、固定聚合方式的场景，例如按天、按渠道、按地区统计核心指标。
另一类问题是口径。同一个活跃用户数，运营、财务和产品各写一套 SQL，结果对不上，还要反复取数解释。把指标定义、过滤条件和维度统一到语义层，能减少重复查询和沟通成本。语义层可以理解为指标口径的统一说明书，让不同工具和不同人查同一个指标时使用同一套定义。需要建设方法时，可以参考统一指标口径的整理方式。
物化视图也有边界。刷新有延迟，存储和维护都有成本，高基数、随机的探索式查询不一定能命中。上线前先确认刷新频率能否满足时效要求，再观察命中率和资源占用。
查询写法与执行计划
先看执行计划，再看执行过程。Doris 官方调优流程建议先用 EXPLAIN 检查分区裁剪、Join 顺序和并行度，再用 Profile 定位具体执行阶段的瓶颈。顺序反过来，容易在错误的位置做优化。
常见写法问题有几类。
- SELECT * 返回用不到的列，列存数据库也要多读数据。
- 把函数写在列上，例如对时间列做转换再比较，可能让谓词下推失效。尽量让列单独出现在条件左侧。
- 大表 Join 前没有先过滤，参与关联的数据量过大。
- 能用 IN 表达的条件写成多个 OR，优化器可用的空间变小。
- 一次返回大量明细行，前端和网络也要承担等待。
这些改写大多风险低，适合作为第一轮优化。每次只改一个变量，保留原 SQL，出现结果差异时能快速回退。
重复查询还可以利用缓存。Doris 的调优文档把 SQL Cache 列为部分场景的加速手段，ClickHouse 的查询缓存适合多个用户重复访问同一份报表。缓存解决的是重复计算，数据更新后要确认有效期和失效策略，不能拿旧结果当新数据。
执行计划提示和参数往往和版本相关。使用 Hint 前先确认当前版本支持范围，上线后观察计划是否稳定。
资源与并发
单条查询的执行时间不长，用户却感觉慢，常见原因是排队。并发上来后，查询争抢 CPU、内存和 I/O，后面的请求只能等。
这时先分清两段时间，查询实际执行了多久，在队列里等了多久。只看总耗时，会把资源问题误判成 SQL 问题。
Doris 的负载管理提供资源隔离、并发控制和熔断。工作负载组可以限制 CPU、内存和 I/O，超过并发上限的查询进入队列；熔断可以在扫描数据量、内存占用或执行时间超限时取消异常任务。ETL 和临时分析跑在同一集群时，资源隔离尤其重要。
扩容要看条件。CPU 长期接近上限、队列持续增长、扫描量和执行计划都正常，扩容才可能有效。扫描量本身过大或查询写法有问题，加机器只会把同样的问题放大。
资源限制也会带来拒绝和排队。硬限设置过紧，正常查询可能被拒；软限过松，隔离效果有限。先按业务优先级分组，再用监控调整阈值。
看板与使用方式
看板变慢，未必是数据库变慢。一个页面放二十张图，每张图都触发查询，再设置十秒自动刷新，后端压力会被成倍放大。
先做三件事。把首屏必须看的图和下钻才看的图分开；把明细行限制在必要范围，先聚合再展示；把自动刷新改成按需刷新或更长的间隔。重复打开的同一张看板，可以使用结果缓存或预计算。
使用方式也会制造等待。同一份数据被不同团队反复取，同一个指标被不同人反复问，分析师的时间花在接需求上。建立可复用的数据集、认证指标和需求分级，能让常见问题直接自助完成，把深度分析留给需要判断的任务。
看板优化要兼顾时效。缓存时间过长，运营看到的是旧数据；刷新过于频繁，后端又被压垮。按业务决策频率设定刷新周期，比统一追求实时更实际。
提速顺序与风险分级
修复顺序的原则是先用低风险动作排除写法和使用问题，再动结构、资源和架构。每完成一步，都用同一组负载验证。
| 优先级 | 动作 | 适用条件 | 风险与回滚 |
|---|---|---|---|
| P0 观测 | 基线、慢查询日志、EXPLAIN | 所有慢查询 | 无，先留档 |
| P1 写法 | 减少列、改写条件、限制行数、缓存 | 查询写法或重复计算问题 | 低，保留旧 SQL |
| P2 结构 | 分区、索引、物化视图、语义层 | 扫描或聚合瓶颈 | 中，副本验证，保留回滚脚本 |
| P3 资源 | 资源隔离、并发上限、扩容 | 资源争抢或容量不足 | 中，参数可回退 |
| P4 架构 | 换引擎、湖仓调整、读写分离 | 以上仍无法满足 SLA | 高，双跑对比后切换 |
高风险动作要有回滚路径。改分区前保留原表或副本，换引擎前双跑对比，调整资源限制前记录原参数。没有回滚方案的优化，不建议直接上生产。
用同一负载做对照测试
验证提速效果，条件要尽量一致，同一批 SQL、同一份数据快照、同样的并发、同样的缓存状态。只改一个变量，连续跑三轮，记录 P50、P95、超时率、排队时间、数据新鲜度和资源成本。
如果优化后 P95 下降，但数据延迟变大，需要判断这个取舍是否可接受。如果单条查询变快，峰值并发下却更容易超时，说明资源或并发控制还没解决。
验收标准最好在优化前定好。例如核心看板首屏在峰值并发下 P95 降到目标范围，超时率不上升，数据延迟不超过业务允许值。达不到就回滚，继续叠加改动只会让问题更难定位。
测试结果要留档。下一次数据量增长或业务变化时，这份基线能帮助判断是容量问题还是新出现的写法问题。
数据分析 Agent 能承接哪一段
系统层的提速解决算得快，分析周转还包含另一段等待。业务提出问题，分析师理解需求、找表、写 SQL、解释结果，再等待下一轮追问。
数据分析 Agent 适合承接这段重复劳动。它可以用自然语言问数，支持多轮追问，自动做归因和可视化，并通过多 Agent 协作把取数、分析、报告串起来。业务人员能先自助拿到常见答案，分析师把时间放在口径设计、异常判断和深度调查上。
ThinkingAI 提供面向企业的数据分析 Agent，基于 Agentic Engine 构建，支持私有化部署。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款；旗下 Tiki 智能助手在中国信通院的数据分析智能体评估中获 4+ 级。需要把多个分析环节协同起来时，可以参考多 Agent 协作的落地方式；对数据主权有要求的企业，可以了解私有化部署。
Agent 不能替代系统优化。数据模型混乱、分区设计不合理、资源长期不足，换一个问答入口仍然会慢。验证 Agent 的价值，也要用真实数据和真实任务，同一问题、同一口径、同一时间范围，比较取数时间、人工步骤和结果可追溯性。
常见问题
加机器能解决所有慢查询吗？
不能。扩容适合资源确实不足、查询计划和扫描量都正常的情况。扫描量过大、Join 设计不合理、返回行数过多，加机器只能短期缓解，成本会持续上升。先用基线判断瓶颈，再决定是否扩容。
缓存能解决看板慢吗？
缓存适合重复执行、结果集较小的查询。它减少重复计算，不改变首次查询的速度。数据更新频繁时，还要处理缓存失效和时效要求。把缓存当作唯一手段，容易出现看板快但数据旧的问题。
物化视图适合所有分析场景吗？
物化视图适合固定维度、固定聚合方式的查询。高基数、随机的探索式分析不一定能命中，刷新延迟和维护成本也要考虑。上线前先确认查询模式、刷新频率和命中率。
数据量到多大需要换引擎？
没有统一阈值。判断依据是 SLA、并发、查询模式、数据增长速度和总成本。用真实负载做基准测试，比只看数据量更可靠。现有引擎通过分区、预聚合和资源隔离能满足要求时，优先做这些低成本改造。
数据分析 Agent 会替代分析师吗？
Agent 更适合承接重复取数、常规归因和报告生成。指标怎么定义、异常是否可信、策略如何取舍，仍需要人来判断。把 Agent 当成分析团队的分工工具，比把它当成替代者更接近实际。
参考资料
- Apache Doris. 调优流程. https://doris.incubator.apache.org/zh-CN/docs/3.x/query-acceleration/performance-tuning-overview/tuning-process/
- Apache Doris. 负载管理概述. https://doris.apache.org/zh-CN/docs/4.x/admin-manual/workload-management/workload-management-summary
- ClickHouse. 查询优化技术与性能调优. https://clickhouse.com/docs/zh/products/cloud/getting-started/resource-tour
- ClickHouse. 查询缓存. https://clickhouse.com/docs/zh/concepts/features/performance/caches/query-cache
以上外部文档查阅时间为 2026 年 11 月。
