我接手一个零售数据平台时，业务方指着监控屏说：“并发只是从600涨到1500，P95延迟却从1.2秒变成8秒，能不能加机器？”我当时的判断是：加机器没用，至少不是第一选择。因为这是典型的数据分析高并发问题，不是请求量压垮了服务，而是每一层都在用重复计算和全量扫描，消耗原本稀缺的 CPU、IO 和连接资源。最终我们做了五个阶段的治理，把 P95 压到 320 毫秒，P99 压到 780 毫秒，同时只增加了 18% 的计算成本。
这篇文章我会把完整的判断逻辑、误区、过程和取舍讲清楚，希望你能少走弯路。
数据分析接口和高并发 Web 接口不一样。Web 接口通常读单行数据，瓶颈在 IO 次数；分析接口的核心是聚合计算，瓶颈在扫描行数、缓存命中率和资源等待。并发一高，最先崩溃的往往不是服务器数量不足，而是同一个数据库、同一批连接、同一套缓存被反复打。
所以我的核心结论是：并发量大不是逼你买更多机器，而是逼你回答一个问题，系统里有多少计算是重复的、有多少扫描是不该发生的。我见过太多团队在并发上来之后直接扩容，结果从 6 台加到 14 台，延迟反而更高。
我们后来把优化方法抽象成三句话：减少扫描、减少重复、减少等待。
任何一个动作做到极致，都能明显改善性能；但只做其中一个，很快会遇到天花板。
我们团队在优化前做了一次压测和链路分析，发现数据库扫描占耗时 48%，连接池等待占 18%，应用层计算只占 8%。如果当时直接加应用服务器，能优化的空间只有 8%，而数据库的连接池和 CPU 依然会是瓶颈。这也是为什么“加机器”解决不了问题的根本原因。
这个零售数据平台负责订单分析、库存分析、用户画像、渠道投放归因，支持约 200 个 API 接口和 80 多个报表。底层是一套 MySQL 业务库加上 Redis 缓存，另有一批定时任务提前生成报表。整体数据量并不算夸张：订单明细 3 亿行，用户表 1.2 亿行，日志事件每天新增约 6000 万条。
架构也不复杂：Java 应用层 -> Redis -> MySQL。大部分分析接口在 MySQL 上做实时聚合，少量报表跑预计算结果。这套架构在业务初期完全够用，但到了大促阶段，1000 多个数据看板同时刷新，并发立刻上去。
我们在促销活动开始前做了一轮压测，模拟真实用户行为。QPS 从 600 逐步升到 1500，结果非常难看：P95 延迟从 1.2 秒涨到 8 秒，P99 甚至到了 12 秒。数据库 CPU 持续 99%，慢查询数量从每小时 200 多条涨到 1200 多条，Redis 命中率只有 31%，大部分请求都穿透到数据库。
进一步看，真正可怕的是延迟并非线性上涨。QPS 只翻了 1.5 倍，P95 却翻了接近 7 倍。这说明系统内部已经发生了严重的排队和资源争抢。
当时最自然的反应是扩资源。我团队先加了三台应用服务器，带宽和负载均衡也都提升了，但压测结果几乎没有变化。原因是：所有请求还是会打到同一个 MySQL，连接池在 1500 QPS 下早就被打满。新增应用节点只是让更多请求在数据库门口排队，而不是被处理。
这就是数据分析场景最典型的“放大效应”：应用层可以很轻松地横向扩容，但存储和计算层一旦成为共享瓶颈，横向扩容反而会加重下游负担。
我见过大量团队在并发升高时使用以下五种方案，它们看起来都有道理，但大多数没有理解问题本质。
堆机器在无状态服务层有效，但在共享存储和计算层会快速失效。我们的压测数据显示：增加 3 个应用节点后，整体 TPS 只提升了约 12%，而数据库连接等待和 CPU 占用反而上升。原因很简单，请求被发放到更多应用节点，每个节点都在建立连接，数据库的连接数和管理开销更大。
如果真想堆机器，也应该先确认瓶颈确实在应用层。否则就是“把 100 个水龙头接到同一个水管上”，水压不会增加。
异步化能释放 Web 线程，缓解应用层超时，但底层查询仍然在消耗资源。我们曾经把报表导出和复杂分析全部扔到消息队列里异步执行，前台是快了，后台任务却大量堆积，消费者线程把数据库连接池占满，反而拖垮了实时接口。
异步只转移了问题发生的位置，并没有减少计算总量。没有资源隔离的异步化，等于把风险从入口移到了内部。
缓存是数据分析性能优化的重要工具，但不是所有数据都适合缓存。我们最开始把所有查询结果都放进 Redis，设置 5 分钟过期。结果在 1500 QPS 下，同一批热点 key 在过期时全部失效，瞬间穿透数据库，造成缓存击穿。Redis 的命中率只有 31%，大量 key 只被访问过一次，缓存反而增加了序列化和网络开销。
正确的做法是：区分热点数据、冷数据和不可缓存数据，分层设计缓存策略。
团队里有人建议把 MySQL 直接换成内存数据库，甚至有方案要把 300GB 明细加载到内存表。我们做了一次小规模验证，发现如果业务 SQL 不改造，换引擎后依然全表扫描，依然慢。内存数据库只是把磁盘瓶颈换成了内存瓶颈，查询复杂度没有变化。
更危险的是，迁移成本极高，业务连续性风险大。某个评测中，我们模拟强制加载 300GB 数据，内存直接 OOM，系统重启了 20 分钟。
限流可以保护系统，但也会让 P99 无限拉长。大促期间，如果只是让请求排队，用户体验是“一直在转圈”，而且排队的请求一旦超过客户端超时时间，就会重复提交，形成更大的洪峰。我们早期用简单限流时，P99 从 8 秒变成 15 秒，用户投诉反而增加。
限流只能作为最后一道安全网，不应该作为性能优化的替代方案。
正确的优化路径应该是：先让系统“可观测”，再用数据找到瓶颈，最后用最小改动验证。不要一开始就选技术方案，更不要一上来就重构。
我们重新定义了性能观测指标，不只盯平均延迟，只盯平均值会掩盖很多问题。以下是我认为最重要的六条：
这六个指标缺一不可。我们当时只盯 QPS 和 CPU，完全忽略了扫描行数和连接池等待，导致定位方向错误。
我们对每个 API 请求做了分布式追踪，把耗时拆成网关、应用、缓存、数据库、序列化五段。结果发现，数据库扫描占到 48%，连接池等待占 18%，应用层只占 8%。也就是说，即使把应用层性能优化三倍，整体延迟也改善有限。
链路追踪的价值不是给你一张调用图，而是帮你判断“时间到底花在谁身上”。
我们抓取了一小时内的全部慢查询，按照“调用次数 × 扫描行数”排序，做了查询热力分析。结论触目惊心：Top 5 查询只占接口数量的 2%，却吃掉了 87% 的扫描行数。
其中订单汇总这个接口，每次查询会扫描 65 亿行，但最终只返回 100 行聚合结果。这个接口被 28% 的请求调用，相当于系统 80% 的计算都在做无用功。
我们不想在没验证的情况下做大规模重构，于是选了 Top1 慢查询做实验：给订单表增加分区，并按业务日期下推谓词。改动很小，但扫描行数从 65 亿降到 3000 万，查询耗时从 7 秒降到 0.4 秒。这个实验验证了判断，也给了团队信心。
最小可行优化的原则是：先证明瓶颈判断正确，再决定是否投入更大成本。
接下来是实际执行过程。我们按“成本低、见效快、风险小”的顺序分五步推进。每一步都有明确目标和验证结果。
这一阶段的核心目标是减少扫描。我们做了三件事：
效果非常明显：扫描行数从 148 亿降到 1.8 亿，慢查询数量从每小时 1200 次降到 208 次，P95 延迟从 8 秒降到 2.5 秒。这一步没有增加任何硬件成本，只花了 3 天开发时间。
扫描行数下降后，系统可以支撑更高并发，但重复请求仍然很多。我们统计发现，80% 的看板请求都在查询最近一小时或最近一天的数据，这些数据在几分钟内不会变化。
我们引入了两个机制：
缓存命中率从 31% 提升到 89%。应用层对数据库的请求从 1500 QPS 降到约 200 QPS。P95 降到 980 毫秒。
SQL 治理和缓存已经解决了一部分问题，但临时分析、多维度筛选、大范围时间对比仍然会打到 MySQL。这时候我们决定引入列存 OLAP 引擎，具体选择时重点考虑三点：列式存储、向量化计算、分布式读写分离。
我们把订单明细、用户事件明细从 MySQL 同步到 OLAP 引擎，由 Flink 消费 Kafka 数据，每 30 秒批量写入一次。线上报表和即席查询统一走 OLAP，MySQL 只保留结构化数据和事务操作。
这里最关键的优化是：把数百个指标拆成原子指标和派生指标，查询引擎根据条件自动下推计算。比如“华东区昨日新客GMV”会被拆成“新客标识”和“订单金额”两个原子指标，在扫描阶段就过滤，而不是先把明细捞出来再算。
这一步完成后，P95 降到 420 毫秒，P99 降到 1.2 秒。列存引擎的 CPU 使用率稳定在 30% 左右。
OLAP 引擎上线后，系统又遇到新的问题：一个大查询可能占用几十核 CPU，把实时看板接口拖慢。我们做了资源隔离。
首先，在 OLAP 引擎里把高频看板、临时分析、ETL 任务分别放到不同队列。高频看板拥有最高优先级，临时分析只能使用剩余资源。
其次，在应用层增加自适应限流：以 P95 延迟为反馈信号，当延迟超过阈值时，自动降低非核心请求的并发数；延迟恢复后，再逐步放开。这套机制就像“交通信号灯”，主动削峰，而不是让所有请求一起堵死。
优化后 P99 从 3.5 秒稳定在 780 毫秒，大促期间没有再出现雪崩。
最后一步是清理基础参数。MySQL 连接池从 500 降到 200，反而让连接等待时间减少，因为每个连接都在更快地完成任务，不再长时间占用。应用层把堆内存调到 16GB，并改为 G1 GC，GC 暂停从平均 2.1 秒降到 120 毫秒。
同时，我们把接口返回的 JSON 做了裁剪和压缩，大数据字段只在详情接口返回，列表接口只给摘要。这一步减少了 30% 的网络传输量。
最终压测结果：QPS 可以支撑到 3000，P95 320 毫秒，P99 780 毫秒，MySQL CPU 从 99% 降到 32%。整个项目耗时 6 周，计算成本增加约 18%。
上面这套方案并不适合所有团队。你需要根据自身数据量、QPS、团队能力和预算选择起点。我按常见场景给出建议。
不要过度设计。先做 SQL 治理，把扫描行数打下来；再用 Redis 缓存热点查询；最后做索引优化。这个阶段通常不会遇到连接池争抢，不要引入 OLAP 引擎，更不要上实时流。
我见过很多团队在日活只有几万时就开始搭数据湖，最后维护成本超过业务收益。轻量场景的核心是保持简单。
这是我前面讲的案例场景。建议按顺序做四件事：Top SQL 治理、预聚合、两级缓存、引入列存 OLAP 引擎。每一件做完都要压测验证，不要一次性全部切换。
OLAP 引擎建议优先选托管版本，避免自建带来的运维负担。
如果业务要求秒级更新，比如实时大屏、实时转化路径、实时风控，不要指望 MySQL + 缓存能扛住。直接用 Flink 做实时预聚合，结果写入 KV 存储或 OLAP 引擎。查询 SQL 必须被限制在近 5 分钟、近 1 小时等小时间窗内。
这种场景的难点不是查询引擎，而是流计算与最终结果的一致性。需要做好窗口边界和数据延迟补偿。
如果你的团队没有专业数仓和运维人员，不要碰自建分布式。先把离线报表迁移到云数仓，在线接口继续用 MySQL 和 Redis。云数仓天然支持大规模扫描和弹性扩展，而且按量付费，初期成本很低。
成本敏感时，优先选择“预聚合 + 定时任务”的方案，甚至可以把最重的报表结果在凌晨算好，白天只读结果表。
大促前必须做全链路压测，并制定降级预案。常见做法是：非核心报表降级为静态数据、临时分析任务暂停、实时看板延迟提高到 5 分钟。同时设置熔断阈值，当 P95 超过 1 秒时自动拒绝低于优先级的请求。
不要在大促前临时换架构，只能做参数调优和资源扩容。把风险控制在已有系统内。
优化不是免费的，每个方案都有代价。我的经验是：在动手前就和业务方谈清楚“你要快，还是要准？要灵活，还是要省？”否则后期会反复拉扯。
缓存和预聚合都会引入数据延迟。我们曾为了让报表实时更新，把缓存失效时间设为 1 秒，结果命中率掉到 40%，数据库压力又回来了。最后我们按数据域分别设置：财务域 T+0 强一致，运营域允许 1 分钟延迟，用户画像允许 5 分钟延迟。
不要试图对所有数据用同一套一致性策略。不同业务方对“新鲜度”的容忍度完全不同。
OLAP 引擎的副本数直接决定查询延迟和成本。副本从 2 提升到 3，P95 可能降低 20%，存储成本却增加 50%。我们的建议是：先用 2 副本跑，CPU 利用率超过 60% 时再加副本，而不是一开始就堆资源。
同时要关注“成本效率”：花同样的钱，是买更多副本，还是买更大的内存做缓存？我们的经验是，优先提升缓存命中率，再考虑加副本。
预聚合能带来百倍性能提升，但会降低灵活性。比如我们已经做了“按天、按小时、按SKU”的聚合，业务方突然要按“用户注册城市”分析时，就要回到底层明细查询。预聚合的粒度决定了业务能够回答的问题边界。
解决方法是把指标层和明细层分开：高频固定指标用预聚合，即席探索用即席查询池。即席查询池可以慢，但不能影响在线任务。
实时计算延迟低，但语法复杂、状态管理成本高；批量计算灵活稳定，但延迟至少 5 分钟。我们最终的架构是 Lambda 模式：离线结果处理大范围历史数据，实时结果处理近 30 分钟数据，两层结果合并后返回给前端。
这种方式会增加开发量，但能同时满足“大范围对比”和“秒级刷新”。如果业务不需要秒级，建议只用批量计算，成本会低很多。
数据分析并发优化，本质上是一个“算得少、算得快、不算重复”的问题。我的核心建议是：不要被“并发大”三个字牵着走，先把瓶颈找出来，再决定做什么。
下一步你可以按照这个清单执行：
如果只选一句话带走：先减少扫描，再减少重复，最后才是减少等待。按这个顺序做，你的系统会走得很稳。
最近系统一压测就挂，DBA说SQL有慢查询要优化，架构师说直接上Redis缓存。我作为负责这个模块的人很迷茫，到底先做哪个？
我的经验是：先看缓存命中率，再决定加不加缓存；不加分析条件直接上缓存，大概率无效。之前接手过一套每日2000万次查询的报表系统，团队第一反应是上Redis，结果命中率不到30%，因为数据分析大多带随机筛选条件，同一个key几乎只被访问一次。
真正有效的第一步是抓慢查询日志，找出重复执行的“固定大查询”。比如一个TOP10用户报表，不同业务方会频繁查同一时间段，这类结果用缓存最合适。我会把数据按小时做聚合，然后缓存聚合结果，TTL设5分钟，命中率提升到70%，数据库压力下降一半。
如果你的查询都是随机透视、自定义筛选，缓存只能做兜底，不能当主力。请记住：缓存是缓存结果，不是缓存热点数据；合理使用前先确认你的查询是否重复出现。
我把where条件、group by字段都加了联合索引，结果接口还是几百毫秒，并发一高数据库连接池就爆。是不是我索引建得不对？
因为数据分析查询的瓶颈往往不在单行查找，而在扫描和聚合。索引能加速等值查询，但当你执行“SELECT city, COUNT(*) FROM orders WHERE day BETWEEN ?AND ?GROUP BY city”时，数据库必须扫描几千万元组再聚合；
即使有索引，也只能减少取样范围，不能避免计算。我见过一个案例：订单表2亿行，加了(day, city)联合索引后，单次查询仍要1.2秒，并发50时数据库CPU就100%。后来改成每日预聚合表，把数据压缩到20万行，查询降到80ms，CPU降到20%。另一个坑是索引可能带来写入放大。
数据分析系统通常要同步业务库数据，频繁更新索引会拖慢导入任务。我的建议是：把大表拆成“明细表”和“聚合表”两层；实时并发查询走聚合表，需要下钻时才查明细表。另外，查询时尽量加时间范围限制，避免全表聚合，这个比任何索引都管用。
我看网上都说高并发要加消息队列、做异步，但我的业务是查询报表，又不是下单，异步化怎么处理？是不是只有数据导入场景才用得上？
查询也可以异步化，但要有选择地用。对于数据导入，异步写入能削峰填谷，这是常见的。对于查询，你要区分两类：一类是用户在线等待、需要秒开的查询，这类不能异步化，因为异步只改变返回方式，不减查询工作量；
另一类是导出报表、生成大看板、批量处理等非交互场景，完全可以拆成任务，先让它跑着，再通过轮询或推送返回结果。我曾经优化过一个运营数据平台，每天早晚高峰有人导出近90天明细，这些请求把MySQL拖到全库慢查询。我把导出改成任务队列，接口收到请求后立刻返回“生成中”，任务执行完写OSS，前端轮询状态。
结果接口平均响应时间从8秒降到300毫秒，数据库负载降低40%，用户体验反而提升，因为不再白等。要注意异步化的代价：用户需要等待任务完成，所以你要做好进度条和失败重试机制。不适合异步的查询别硬改，不然用户以为页面卡死了。
现在MySQL还能跑，但并发越来越高，领导让我评估要不要上ClickHouse或者Doris，我担心迁移成本和运维难度，是不是应该提前换？
不要因为并发大就直接换引擎；先把数据量和查询模式算清楚。我的判断标准是：如果你的单表超过1亿行，查询经常扫描大部分列并且需要秒级返回，MySQL显然兜不住，这时候OLAP引擎值得上。如果只是几千万元素、查询带固定索引和高命中缓存，先优化SQL和聚合表，往往省下一整年运维成本。
我们团队也做过一次迁移：广告点击明细3.2亿行，MySQL慢查询平均2.5秒，复制到某开源列式存储引擎后，明细聚合降到200毫秒，但代价是从原来一个库变成两套系统，数据同步、权限、查询语法都要改。过程中踩过两个坑：一是明细数据更新频率高，OLAP引擎的流式写入不稳定，需要改用批量写入；
二是并发高过300时，列式引擎的CPU调度也会打满，需要控制查询并发数。所以我建议采用混合架构：业务事务和中等规模分析留在MySQL，大明细分析走OLAP引擎。先做预聚合，再评估是否引入新组件，这样性价比最高。不要因为别人的技术栈就照搬，你的业务特点才是决策依据。
读者评论
文章把“并发高”和“资源利用低效”区分得比较清楚，尤其是扫描行数、连接池等待和缓存命中率这些指标，对定位瓶颈很有参考价值。
案例数据比较完整，从P95、P99到慢查询占比都有说明，能够直观看出单纯扩容应用层的局限。不过部分优化结果仍依赖具体数据库和业务结构，落地时需要重新压测验证。
按“减少扫描、减少重复、减少等待”推进优化，思路比较实用。分区、预聚合和资源隔离的组合值得借鉴，但文中后续五步的实施细节如果再展开一些，会更方便读者复现。