数据库存：架构师复盘框架：系统重构如何定位查询速度慢

系统重构后，接口从几十毫秒变成数秒，最容易出现的判断是：“数据库有慢查询，赶紧加索引。”但我在性能复盘中反复遇到一个相反结论：真正拖慢接口的，往往不是某一条 SQL 突然变差，而是查询次数、事务边界、连接池等待和数据返回量发生了变化。如果只盯着慢查询日志，可能会把一个调用链问题误判成索引问题，最后索引加了，写入变慢，接口尾延迟却没有改善。

本文不把慢查询定位简化成“查看日志、执行 EXPLAIN、添加索引”三步，而是从系统重构复盘的角度，建立一条完整证据链：先确认接口究竟慢在哪里，再把请求关联到 SQL，区分执行慢、等待慢和调用次数过多，最后通过对照实验验证修复是否真的有效。

一、先讲核心结论：查询慢不是一个点，而是一条链

1. 先定位“慢在哪一层”，不要先定位“哪条 SQL”

一个接口的总耗时，通常由多个阶段组成：网关转发、应用线程排队、获取数据库连接、SQL 执行、锁等待、结果传输、ORM 映射以及业务计算。数据库监控看到的 SQL 执行时间，只覆盖其中一部分。

例如，一个接口总耗时为 2.4 秒，数据库中某条 SQL 的执行时间只有 80 毫秒，但应用线程在连接池中等待了 1.7 秒，那么“优化 SQL”并不是第一优先级。相反，如果接口只执行了一次 SQL，但扫描了数百万行，才应该优先研究访问路径和索引。

我的第一条判断原则是：先拆分总耗时，再决定是否进入 SQL 优化。没有链路拆分之前，任何“数据库就是根因”的结论都只能算猜测。

2. 要同时看单次耗时、调用次数和总耗时贡献

慢查询排查中，一个很容易被忽略的指标是调用次数。一条单次耗时 1 秒、每小时执行 10 次的报表 SQL，和一条单次耗时 40 毫秒、每秒执行 2000 次的查询，对在线系统的影响完全不同。

我通常会把 SQL 按“总耗时贡献”重新排序，而不是简单按照单次平均耗时排序。一个 SQL 模板的总耗时可以粗略理解为：单次执行耗时乘以执行次数。对于高并发接口，还要额外关注 P95、P99 和超时次数，因为平均值会掩盖极端参数和锁等待。

如果只看“最慢的一条 SQL”，很可能会错过真正消耗数据库资源最多的查询。这也是为什么我在复盘表中会单独记录 SQL 模板、调用次数、总耗时和尾延迟，而不是只记录一条慢查询样本。

3. 执行计划是证据，不是结论

执行计划可以告诉我们优化器打算如何访问数据，但它不能直接说明线上实际发生了什么。一个计划显示使用了索引，并不代表扫描行数足够少；一个计划显示全表扫描，也不一定代表有问题，因为小表全表扫描可能比走低选择性索引更快。

我会把执行计划放在四类信息中一起看：估算行数、实际扫描行数、实际返回行数和等待状态。若估算行数与实际行数相差很大，统计信息、数据分布或参数敏感性就值得怀疑；若执行时间增长主要来自锁等待，继续改索引通常不会解决根因。

二、背景和真实场景：系统重构为什么会让查询突然变慢

1. 重构改变的不是一条 SQL，而是数据访问方式

系统重构常常从代码层面开始：拆分服务、替换 ORM、重写数据访问层、调整缓存、扩展查询字段或重新设计事务边界。开发人员看到的是模块变得更清晰，数据库看到的却可能是查询次数增加、连接持有时间变长和返回数据量扩大。

例如，重构前的订单接口可能先查订单，再通过一次关联查询获得用户和商品信息；重构后为了“职责分离”，订单、用户和商品被拆成三个 Repository。业务代码在循环中分别调用它们，最终形成一条订单查询加几十条关联查询。

单条关联 SQL 可能只有十几毫秒，但当一次请求返回 50 条订单时，数据库往返次数会快速放大。高并发下，连接池、网络和对象映射同时承压，接口 P99 就可能从几十毫秒滑向数秒。

2. 以九数云这类数据分析场景为例，慢不一定来自事务查询

以九数云这类面向企业数据分析、报表和多源数据整合的平台为例，查询场景和典型交易系统不完全相同。用户可能同时筛选时间、组织、渠道、产品和客户等维度，系统还要完成多表关联、聚合、排序和图表数据返回。

在这种场景中，不能简单套用“给查询字段加索引”的交易型思路。一个分析查询变慢，可能是筛选范围扩大、聚合层级增加、数据源刷新、宽表字段增多，或者多个图表在同一次页面加载中分别发起查询。

以下案例是我按照这类平台常见架构整理的情景复盘，数据为模拟值，用来展示定位方法，不代表九数云内部系统或真实客户的统计结果。案例的价值不在于某个品牌，而在于说明：当数据分析页面变慢时，应该如何把页面体验拆成可验证的技术证据。

3. 真实场景中的第一个误判：数据库 CPU 没打满，所以数据库没问题

数据库 CPU 没有达到 90%，并不能排除数据库相关问题。锁等待、连接池耗尽、磁盘延迟、网络传输和事务持有时间，都可能让接口变慢，却不会让 CPU 持续打满。

相反，数据库 CPU 很高，也不意味着应该立即扩容。高 CPU 可能由重复查询、错误的分页方式、低选择性索引或某个批处理任务引起。扩容只能把问题推迟，不能修复访问模式。

我在复盘时会把“资源是否高”和“资源是否被错误使用”分开记录。前者是容量问题，后者是设计问题。两者都需要处理，但处理顺序不同。

三、常见误区：为什么很多慢查询优化最后没有效果

1. 误区一：接口慢，就直接把问题归因于数据库

接口延迟是用户看到的结果，不是根因。一个请求可能在应用线程池中排队 500 毫秒，获取连接等待 800 毫秒，真正的 SQL 执行只用了 60 毫秒。此时即使把 SQL 优化到 20 毫秒，接口也不会从 1.36 秒恢复到几十毫秒。

正确做法是先建立时间预算。把一个请求的耗时记录成多个区间，并在同一条 Trace 中关联请求、连接获取、SQL 执行和结果处理。没有时间区间，就没有根因定位。

2. 误区二：发现慢 SQL 就加索引

加索引是有效工具，但不是默认答案。索引是否有收益，至少取决于过滤条件的选择性、联合索引顺序、排序方式、返回列数量、数据分布和写入比例。

例如，对状态字段建立单列索引，在“成功”记录占总数据 98% 的表中，可能无法有效减少扫描量。索引还会增加插入、更新和删除成本。如果业务是高频写入系统，盲目新增多个索引，可能让写延迟和存储成本一起上升。

3. 误区三：平均耗时下降，就认为优化成功

平均值适合观察整体趋势，但不适合判断线上体验。一次接口平均耗时从 900 毫秒降到 300 毫秒，看起来改善明显；如果 P99 仍然是 8 秒，用户依旧会在高峰期遇到卡顿。

我更关注 P95、P99、超时率和最差参数分布。尤其是多租户、报表和搜索场景，不同租户的数据量可能相差几十倍。小租户的平均值很漂亮，并不能代表大租户的真实体验。

4. 误区四：测试环境执行很快，线上应该没有问题

测试环境通常缺少线上数据规模、真实参数分布和并发竞争。一个只有 10 万行的测试表，可能让全表扫描看起来毫无问题；到了生产环境，数据量达到数亿行，同样的 SQL 就会出现明显延迟。

此外，测试环境往往只有少数请求，线上却存在缓存失效、锁竞争、连接池排队和后台任务争抢资源。性能验证必须尽量复制线上数据规模和参数分布，而不是只在客户端点几次执行。

5. 误区五：执行计划显示“走索引”，就认为查询路径正确

“走索引”只说明访问路径的一部分。索引可能返回大量候选记录，之后仍需要回表、排序和过滤；也可能因为覆盖列不足，产生大量随机 IO。

我会重点比较估算行数与实际行数。如果优化器估算返回 100 行，实际扫描了 500 万行，计划中的“使用索引”就不具有足够的解释力。此时应该进一步检查统计信息、数据倾斜和参数敏感性。

6. 误区六：把一次故障修复当成长期治理

临时改 SQL 可以恢复服务，但不能保证同类问题不再出现。系统重构后如果没有建立 SQL 数量、慢查询比例、连接池等待和大结果集监控，下一次代码变更仍可能重复引入问题。

一次完整复盘至少要留下三类成果：可回滚的修复、可量化的验证结果、能提前发现问题的监控或规范。只有这样，排查经验才会从个人记忆变成团队能力。

四、专业判断逻辑：用“现象，证据，假设，验证”定位根因

1. 第一步：先建立重构前后的性能基线

没有基线，就无法判断“变慢”到底发生在何时、哪个版本和哪类请求。基线不应只记录平均响应时间，至少要包括吞吐量、P50、P95、P99、超时率、数据库 QPS、连接池等待和资源使用率。

如果重构前没有完整数据，可以从访问日志、监控平台、数据库审计日志和用户反馈中拼接出近似基线，并明确标注数据可信度。复盘不要求所有历史数据完美，但必须区分“观测事实”和“团队推断”。

基线的价值不只是记录数字，而是帮助我们建立可比较的实验条件。如果重构前后的流量、缓存状态和数据规模完全不同，单纯比较两个响应时间没有意义。

2. 第二步：把总耗时拆成可观测的时间区间

我会在应用链路中至少增加三个时间点：开始获取连接、成功获取连接、数据库执行完成、结果处理完成。这样可以把“数据库慢”拆成连接等待、SQL 执行和应用处理三个部分。

对于已有链路追踪的系统，可以将数据库调用作为 Span，并记录 SQL 指纹、数据库实例、表或业务模块、返回行数和错误类型。生产环境不建议默认记录完整参数，应该对敏感字段脱敏，并采用采样策略控制日志成本。

请求总耗时
├── 应用排队耗时

├── 获取数据库连接耗时

├── SQL执行耗时

│ ├── 排队等待

│ ├── 锁等待

│ └── 实际执行

├── 结果集传输耗时

└── 业务处理与序列化耗时

如果暂时没有完整链路，也可以先通过应用日志记录 SQL 模板、执行开始时间、执行结束时间和请求标识，再与数据库慢查询日志按时间窗口和 SQL 指纹进行关联。这个方法不如分布式追踪精确，但通常足以发现查询次数暴增和连接池等待。

3. 第三步：确认是“单条 SQL 慢”还是“查询次数多”

这是系统重构中最有价值的一步。很多 N+1 查询问题不会让某一条 SQL 看起来特别慢，因为每条 SQL 都能在几十毫秒内完成；真正的问题是一次请求执行了几十甚至几百条 SQL。

我会为每个请求计算三个值：SQL 总数、不同 SQL 模板数、重复模板比例。若一次请求执行 80 条 SQL，其中 70 条属于同一个模板，只是参数不同，就应该优先考虑批量查询、预加载或缓存，而不是先为每个字段添加索引。

4. 第四步：判断是执行慢、等待慢，还是返回慢

我会把数据库相关问题分为三类。第一类是执行慢，表现为扫描数据量大、排序聚合成本高、磁盘读取多；第二类是等待慢，表现为锁等待、连接等待、线程资源不足；第三类是返回慢，表现为 SQL 已经执行完成，但结果集太大，传输和序列化占用了大量时间。

三类问题的修复方向完全不同。执行慢可能需要改变 SQL 或索引；等待慢可能需要缩短事务和调整并发；返回慢则需要减少字段、限制行数或改变数据接口。把三类问题混在一起，是优化无效的常见原因。

5. 第五步：用执行计划确认访问路径和数据分布

以 MySQL 为例，常规执行计划可以使用如下命令查看访问路径；如果版本支持运行时分析，还应尽量结合实际执行信息，而不是只看静态估算。

EXPLAIN
SELECT

order_id,

customer_id,

order_status,

created_at

FROM orders

WHERE tenant_id = 1024

AND order_status = 'PAID'

AND created_at >= '2026-01-01'

ORDER BY created_at DESC

LIMIT 50;

我通常重点看以下内容：访问类型、候选索引、实际使用索引、估算行数、过滤比例、连接顺序、额外排序以及临时表。如果是 PostgreSQL，则应关注 EXPLAIN ANALYZE 中的实际行数、计划行数、节点耗时和 Buffers；不同数据库的字段名称不同，但判断逻辑相近。

执行计划分析不能脱离参数。对于同一条 SQL，查询一个小租户和查询一个大型租户，可能得到完全不同的执行成本。建议至少选择小数据量、中位数据量和大数据量三类参数进行对比。

6. 第六步：检查重构引入的事务和连接池变化

系统重构经常扩大事务范围。原来只有一次写入的事务，可能因为服务编排而包住多个查询、远程调用和业务计算。数据库连接在整个事务结束前都无法归还连接池，最终表现为连接池等待和接口尾延迟上升。

判断事务问题时，我会同时看事务持续时间、连接占用时间、锁等待和回滚率。如果事务平均只执行 30 毫秒，但连接占用时间达到 600 毫秒，说明连接可能在 SQL 执行外被长时间持有。

连接池也不能简单通过“把最大连接数调大”解决。连接数扩大后，数据库并发执行压力可能更高，锁竞争和上下文切换反而加剧。连接池配置必须和数据库承载能力、应用实例数量及 SQL 并发模型一起评估。

五、具体案例与数据观察：一个分析页面为什么会从流畅变卡顿

1. 案例背景：页面拆分后，查询入口变多

假设某企业经营分析页面接入订单、客户、商品和渠道等数据。重构前，页面由服务端一次性准备主要数据；重构后，为了让组件独立加载，首屏拆成多个图表接口，每个图表分别查询自己的数据。

这种设计在代码结构上更灵活，却带来一个容易忽视的变化：页面打开一次，数据库不再面对少量聚合查询，而是面对多个并发查询。部分图表还会根据筛选条件再次刷新，用户改变一次日期范围，可能触发十几条查询。

为了便于说明，下面数据采用情景模拟。实际排查时，应使用应用链路、数据库监控和真实流量压测结果替换这些数字。

这里最值得注意的不是单条查询平均耗时，而是页面请求数、数据库查询数和页面尾延迟同步变化。重构后平均查询耗时只从 48 毫秒升到 71 毫秒，增长并不夸张；但查询数量从 6 条增加到 24 条，连接竞争和结果处理成本被放大，最终让用户感知到明显卡顿。

2. 第一个证据：单条 SQL 并不算特别慢

排查初期，团队从慢查询日志中找到几条平均耗时 70 毫秒左右的查询。按照常见阈值，这些 SQL 不一定会被认定为严重慢查询，因此最初没有引起足够重视。

但将请求日志与 SQL 指纹关联后发现，页面一次加载会重复执行同一类查询。某个图表需要客户标签，另一个图表也需要客户标签，两个模块各自查询，没有共享结果；筛选器变化时，部分查询又被重复触发。

最终，问题从“某条 SQL 太慢”变成了“同一请求中 SQL 调用过多且重复率过高”。这类问题的关键指标不是慢查询阈值，而是每请求 SQL 数量、重复模板比例和数据库往返次数。

3. 第二个证据：聚合发生得太晚

重构后的部分接口先从数据库取出较多明细数据，再在应用层进行分组和汇总。这样做可以复用一套业务代码，但会把数据库本来擅长完成的过滤、聚合和排序转移到应用层。

在模拟数据中，数据库返回行数从 1.8 万行增加到 7.4 万行，最终页面实际只展示几十个聚合结果。应用需要接收、解析、转换和序列化大量中间数据，数据库连接也会被占用更长时间。

我的判断是：如果用户只需要汇总结果，却把明细数据跨网络传到应用层，性能问题往往不是索引缺失，而是计算位置不合理。这时应考虑在数据库侧聚合、建立汇总表、构建读模型或使用适合分析场景的预计算机制。

4. 第三个证据：连接池等待比 SQL 执行更值得优先处理

当首屏同时发起多个接口时，每个接口都可能从连接池申请连接。如果应用实例数量较多，即使单实例连接数没有超过上限，整个数据库实例也可能出现连接数堆积。

案例中，连接池等待占比从 3% 上升到 29%。这意味着部分请求甚至还没有开始执行 SQL，就已经在等待可用连接。此时直接增加数据库索引不会减少连接等待，盲目扩大连接池也可能让数据库同时处理更多竞争请求。

更合理的顺序是：先统计应用实例总连接上限，再观察实际活跃连接、事务连接占用时间和 SQL 并发，之后决定是减少查询数量、缩短事务、限制并发，还是调整连接池上限。

5. 优化后的验证不能只看页面速度

批量查询和预聚合让页面 P95 恢复，并不代表所有问题都结束了。批量查询可能增加单条 SQL 的返回结果，预聚合可能增加数据刷新成本，缓存还可能引入数据时效性和一致性问题。

因此，我会同时观察读取性能、写入性能、刷新耗时、缓存命中率、数据库资源和数据准确性。尤其是分析平台，用户更关心的不只是“快”，还关心筛选后的数字是否及时、口径是否一致。

六、不同根因下的行动建议：先选对问题，再选择工具

1. 如果是单条 SQL 执行慢

当单条 SQL 占据主要耗时，且实际扫描行数、排序量或聚合量明显偏高，可以按以下顺序排查。

• 确认过滤条件是否能够有效缩小数据范围。
• 检查是否对索引列进行了函数运算或隐式类型转换。
• 比较联合索引列顺序与过滤、排序条件是否匹配。
• 检查是否查询了实际不需要的字段。
• 比较不同参数、不同数据规模下的执行计划。
• 核实统计信息是否及时，数据是否存在严重倾斜。
• 评估是否需要分区、汇总表、读模型或专用分析存储。

如果查询属于在线交易路径，优先控制扫描行数和返回行数；如果属于报表或分析路径，不要只追求单条 SQL 极限速度，还要评估刷新、并发和资源隔离。

2. 如果是 SQL 调用次数过多

当单条 SQL 耗时正常，但每请求 SQL 数量异常，优先检查业务代码和数据访问层，而不是索引。

• 确认是否在循环中查询关联对象。
• 检查 ORM 懒加载是否在序列化或模板渲染时被触发。
• 将多个单条查询改为批量查询。
• 对同一请求内重复参数增加短生命周期的请求级缓存。
• 对跨请求的稳定数据评估共享缓存，但要明确失效和一致性策略。
• 对多个图表的公共维度数据进行复用，避免每个组件独立读取。

批量查询并不意味着一次性把所有数据取出来。批量接口仍需设置数量上限、超时、分页和参数校验，否则只是把很多小问题合并成一条超大查询。

3. 如果是连接池等待

连接池等待通常与三个问题有关：连接数量不足、连接归还不及时、数据库执行时间过长。排查时不要只看最大连接数，而要看连接生命周期。

• 记录获取连接耗时和归还连接耗时。
• 确认异常分支是否存在连接未释放。
• 检查事务是否包住远程调用、文件处理或复杂业务计算。
• 比较活跃连接数、等待连接数和数据库实际并发能力。
• 核实应用实例扩容后，连接上限是否按实例数线性放大。
• 在连接池耗尽时设置合理超时和降级策略。

如果连接占用时间远大于 SQL 执行时间，优先缩短连接持有范围；如果 SQL 执行本身很慢，则需要先处理数据库访问路径，否则单纯增加连接只会放大资源争抢。

4. 如果是锁等待或慢事务

锁等待问题通常表现为高峰期突发、平均值不一定明显、P99 和超时率却快速恶化。数据库 CPU 可能正常，甚至偏低，因为大量请求处于等待状态。

• 找出持锁时间最长的事务。
• 确认事务中是否包含远程调用、用户交互或非必要查询。
• 检查多个业务流程是否以不同顺序更新相同资源。
• 减少大事务，将非关键操作移出事务。
• 对热点行设计串行化、分段更新或异步处理。
• 设置锁等待超时、告警和阻塞链路记录。

索引有时可以减少锁定范围，但不能替代事务设计。特别是更新条件不准确、事务范围过大时，建立新索引只是降低部分扫描成本，根因仍然存在。

5. 如果是结果集和序列化过大

当数据库执行时间不高，但返回行数、响应体和应用 CPU 同时上升，应把注意力转移到数据接口设计。

• 只返回页面真正需要的列。
• 为列表、详情和导出设计不同的数据接口。
• 限制默认时间范围和最大分页深度。
• 避免把大批量导出放在同步请求中。
• 对大结果集使用异步任务、分片读取和文件化交付。
• 将聚合计算尽量推到合适的数据处理层完成。

6. 如果是重构后分析页面整体变慢

对于九数云这类多维分析、报表和数据整合场景，建议把问题拆成四条链：数据刷新链、查询计算链、页面请求链和结果呈现链。每条链都有自己的瓶颈，不能仅通过数据库慢查询日志覆盖全部过程。

七、不同方案的取舍：不是越快越好，而是满足业务约束

1. 加索引与改数据模型的取舍

加索引通常上线快、回滚相对直接，适合访问条件明确、数据选择性较高、写入压力可控的场景。但索引越多，写入维护成本越高，表结构变更和空间管理也更复杂。

改数据模型、建立汇总表或读模型，往往能获得更稳定的读取性能，但会增加数据同步、刷新、校验和运维成本。它适合读取模式稳定、查询聚合复杂、在线访问量较大的场景。

2. 缓存与实时性的取舍

缓存可以显著降低重复查询，但它不是免费的性能。缓存命中时速度很快，缓存失效时可能产生并发回源；缓存中的数据如果没有明确刷新策略，还可能导致用户看到旧数据。

对于经营分析页面，应先确认指标的时效要求。实时库存、实时支付状态和风险控制通常不能简单使用长时间缓存；日报、周报和经营趋势则更适合采用预计算或短周期缓存。

我建议在方案评审中明确写出三个数字：允许的数据延迟、缓存有效期和缓存失效后的最大回源并发。只写“增加缓存”而不写这三个约束，后续几乎一定会出现一致性或缓存击穿问题。

3. 数据库侧聚合与应用侧聚合的取舍

数据库侧聚合能够减少网络传输和应用内存使用，通常适合结构化的分组、求和、计数和筛选。但复杂业务规则如果全部塞进 SQL，可能降低可读性和可测试性。

应用侧聚合更容易复用业务代码，也方便处理复杂规则，但在数据量大时会产生传输和内存成本。我的判断标准不是“聚合必须放在哪里”，而是比较三项成本：数据移动成本、计算成本和一致性维护成本。

4. 在线查询与离线任务的取舍

如果用户点击一次就触发数亿行扫描，即使优化索引也可能无法满足交互体验。此时应把问题从“如何让在线请求更快”改成“哪些计算应该提前完成”。

在线接口适合处理范围明确、响应数据有限、延迟目标严格的查询；大范围导出、复杂经营分析和跨周期聚合，更适合异步任务、预计算或专用分析链路。把所有工作都塞进同步接口，是架构层面的性能债务。

八、一次完整的慢查询复盘应该怎么写

1. 先写清楚故障现象，而不是先写技术结论

好的复盘开头应包含接口、时间、影响范围和用户表现。例如：“某经营分析页面在版本发布后，高峰期 P95 从 1.2 秒升至 4.6 秒，部分大租户出现超过 10 秒的加载延迟；订单写入成功率正常，主要影响查询和页面加载。”

这种描述比“数据库性能下降”更有价值，因为它明确了影响边界，也避免把尚未验证的根因写成事实。

2. 把证据按时间线排列

1. 记录版本发布时间和性能指标开始变化的时间。
2. 确认流量、数据量和数据库版本是否同时发生变化。
3. 对比重构前后的接口数量、SQL数量和参数分布。
4. 检查数据库资源、连接池、锁等待和慢查询趋势。
5. 抽取代表性请求，关联具体 SQL 和执行计划。
6. 形成一个或多个根因假设，并设计可重复的验证实验。
7. 上线修复后观察尾延迟、资源、数据准确性和副作用。

时间线的作用是区分相关性和因果性。版本发布后变慢，不代表版本中的某条 SQL 一定是根因，也可能是发布同时改变了缓存预热、数据刷新或实例数量。

3. 每个根因都要有“证据”和“反证”

如果判断是索引问题，应提供扫描行数、过滤比例和执行计划变化；如果判断是锁等待，应提供阻塞事务和等待时长；如果判断是 N+1，应提供单请求 SQL 数量和重复模板比例。

同时还要记录反证。例如数据库 CPU 没有持续升高、单条 SQL 执行时间正常，就说明“CPU不足”或“某一条 SQL 极慢”可能不是主要根因。反证能够防止团队在错误方向上继续投入。

4. 用对照实验代替“感觉变快了”

一次有效的性能实验，至少要固定数据库版本、数据规模、查询参数、缓存状态和并发模型。若只能在生产环境验证，应采用影子流量、小比例灰度或只读副本，避免直接把未经验证的索引和 SQL 改动推向全部用户。

优化前后的对比也要覆盖副作用。新增索引可能降低写入性能，预聚合可能延长数据刷新，缓存可能带来短暂旧数据，批量查询可能增加单次返回量。只有把收益和代价放在同一张表中，决策才完整。

九、不同阶段的行动建议：今天、这周和长期分别做什么

1. 线上正在故障：先止血，再求根因完整

如果接口已经大面积超时，第一目标是恢复服务，而不是当场完成架构优化。可以根据业务影响采取限流、降级、关闭非核心图表、缩小默认查询范围、暂停重型报表任务或临时切换只读数据源等措施。

止血期间要保留证据。至少记录故障开始时间、版本、请求量、SQL模板、连接池状态、锁等待和资源曲线。没有证据的紧急操作，事后很容易只能凭记忆争论。

• 优先关闭重复刷新和非核心查询。
• 限制大范围日期、超大租户和深分页请求。
• 暂停与在线业务争抢资源的批处理任务。
• 对异常SQL设置超时和熔断，避免拖垮连接池。
• 保留一份异常参数样本，供后续复现。

2. 故障已恢复：在二十四小时内完成证据闭环

恢复服务后，不应立即把临时措施当成最终方案。建议在较短时间内完成版本差异、调用次数、耗时分布、数据库状态和执行计划的对照。

如果团队没有足够的观测数据，应把“缺少哪些数据”本身列为复盘结论。例如没有记录连接获取时间，就无法确认连接池是否是瓶颈；没有 SQL 指纹，就无法判断查询次数是否暴增。

3. 一周内完成修复验证和灰度

修复方案应尽量拆成小变更。先解决最确定、收益最大的访问方式问题，再评估索引、缓存和数据模型调整。每次变更只改变一个主要变量，才能知道收益来自哪里。

• 为核心接口补充 P95、P99 和超时率告警。
• 记录每请求 SQL 数量和重复模板比例。
• 为慢查询关联调用方和业务接口。
• 增加连接池等待、事务持续时间和锁等待监控。
• 对大租户、大时间范围和深分页建立专项测试。

4. 长期治理：把性能约束写进研发流程

系统重构评审不能只审模块边界和代码可维护性，还要审数据访问行为。每次拆分服务或 Repository，都应回答：一次请求会新增多少数据库往返？事务范围是否变化？查询结果集是否扩大？缓存和数据刷新是否需要重新设计？

对于高频接口，可以建立查询预算。例如规定一次列表请求默认不超过若干条 SQL、默认返回行数不超过某个范围、单接口连接等待不能超过总体延迟预算的一定比例。预算不是绝对规则，但能让性能风险在上线前被讨论。

十、工具与命令：工具应该回答问题，而不是成为命令清单

1. 慢查询日志回答“哪些 SQL 值得看”

慢查询日志适合发现执行时间超过阈值的 SQL，但阈值必须结合业务。在线接口可能需要几十毫秒级监控，后台报表可以接受更高阈值。不要把一个固定阈值当成所有业务的“慢”定义。

日志分析时，建议按 SQL 指纹聚合，而不是逐行阅读。重点排序维度包括平均耗时、P95、调用次数、总耗时贡献和错误次数。

2. EXPLAIN 回答“优化器准备怎么访问”

执行计划适合验证访问路径，但要结合实际参数和运行时状态。对于复杂查询，应保存优化前后的计划文本，并标注数据库版本、统计信息更新时间和测试参数，否则后续无法判断计划变化的原因。

3. 链路追踪回答“这条 SQL 来自哪里”

数据库监控能够告诉你 SQL 慢，却未必能告诉你哪个接口、哪个代码路径和哪个用户动作触发了它。链路追踪把 SQL 与请求关联起来，特别适合定位重构后的重复调用、跨服务查询和页面多接口并发。

4. 应用指标回答“数据库之外发生了什么”

线程池、连接池、GC、序列化和网络指标，是判断接口慢因的重要补充。若数据库执行时间只占总耗时很小一部分，就不应该继续把排查资源全部投入数据库。

十一、可直接复用的慢查询复盘模板

1. 故障事实

• 受影响接口或页面：
• 首次发现时间：
• 影响租户、用户或业务范围：
• 重构版本与上线时间：
• 重构前后的 P50、P95、P99：
• 是否伴随错误率、超时率或吞吐变化：

2. 链路证据

• 网关和网络耗时：
• 应用线程排队耗时：
• 数据库连接获取耗时：
• SQL执行耗时：
• 锁等待耗时：
• 结果传输和对象映射耗时：

3. SQL证据

• SQL模板或指纹：
• 每请求SQL数量：
• 重复模板比例：
• 单次平均耗时与P95：
• 执行次数和总耗时贡献：
• 估算行数与实际扫描行数：
• 实际返回行数和响应字节数：

4. 根因与反证

• 主要根因假设：
• 支持该假设的证据：
• 不支持该假设的反证：
• 排除过的其他原因：
• 最终根因的确定方式：

5. 修复和验证

• 临时止血措施：
• 最终修复措施：
• 灰度范围和观察时间：
• P95、P99和超时率变化：
• 数据库CPU、IO和连接变化：
• 写入、刷新和数据准确性副作用：
• 回滚条件：

6. 长期治理

• 新增了哪些监控：
• 增加了哪些告警：
• 代码评审增加了哪些检查项：
• 哪些查询需要建立预算：
• 是否需要调整数据模型或架构：

十二、最后的专业判断：真正要优化的是“单位请求的数据库工作量”

1. 不要只追求更快的 SQL

我更愿意把数据库性能问题定义为：一次业务请求为了完成目标，迫使系统完成了多少无效或重复的数据库工作。这比单纯比较某条 SQL 的执行时间更接近架构问题。

如果一条 SQL 从 100 毫秒优化到 50 毫秒，但每个请求仍然执行 100 次，系统的总体压力依然很大。相反，将 20 次 30 毫秒的查询合并为一次 80 毫秒的批量查询，通常更能改善整体吞吐和尾延迟。

2. 重构评审要同时评估代码复杂度和数据访问复杂度

模块拆分、接口拆分和 Repository 拆分可以改善代码组织，但它们也可能增加数据库往返、网络跳数和事务协作。架构设计不能只看“代码是否解耦”，还要看“数据是否被重复读取”。

我建议每次涉及数据访问的重构，都补充一张前后对照表，至少记录每请求 SQL 数量、最大返回行数、事务持续时间、连接占用时间和高峰期 P99。它不需要很复杂，但必须在设计阶段就出现，而不是故障后才补。

3. 性能优化的终点不是一次恢复，而是下一次可预测

一次优化把 P99 从 8 秒降到 2 秒，当然是收益；但如果团队仍不知道为什么变慢、哪些参数最危险、什么时候会触发连接池耗尽，那么系统只是暂时恢复，并没有真正获得稳定性。

真正成熟的结果应该是：任何一次查询速度异常，都能沿着固定路径找到请求、SQL、参数、执行计划、等待状态和版本差异；任何一次修复，都能用相同指标进行对照；任何一次重构，都能提前评估数据库工作量变化。

4. 下一步怎么做

如果你现在正面对一个变慢的接口，不要从加索引开始。先完成下面四件事：

1. 记录该接口的 P50、P95、P99、超时率和高峰期流量。
2. 拆分应用排队、连接获取、SQL执行、锁等待和结果处理耗时。
3. 统计一次请求执行了多少条 SQL，以及重复模板比例。
4. 为最具代表性的参数保存执行计划，并进行优化前后对照实验。

如果结果显示是单条 SQL 扫描过多，再讨论索引和 SQL 改写；如果结果显示是查询次数暴增，先处理批量化和调用方式；如果结果显示是连接或锁等待，就回到事务、并发和资源治理；如果结果显示是结果集过大，就重新设计接口和计算位置。

系统重构后的慢查询定位，核心不是找到一条“最慢的 SQL”，而是解释一次请求为什么让数据库做了过多、过久或不必要的工作。这条判断一旦建立起来，排查就不再依赖个人经验，优化也不再停留在“试着加个索引看看”。

免费注册

咨询方案

扫码咨询方案