性能分析示例
为了按照视频说明操作，请打开此处示例报告。
如何解读性能报告
使用HQbird，或者作为独立服务，通过cc.ib-aid.com上的IBSurgeon性能分析，您可以从Firebird跟踪日志生成性能报告。
该报告是一个强大的诊断工具，提供有关Firebird数据库中SQL查询执行的详细信息。本指南解释了如何系统地解读和使用跟踪报告来识别和解决性能瓶颈。
1. 性能报告结构
┌─────────────────────────────────────────┐
│ 性能报告 │
├─────────────────────────────────────────┤
│ 1. 性能摘要图表 │
│ ┌────────────────────────┐ │
│ │ 顶级查询 │ │
│ │ 顶级摘要 │ │
│ │ 顶级频率 │ │
│ │ 持续时间 │ │
│ │ 获取次数 │ │
│ │ 读取次数 │ │
│ │ 写入次数 │ │
│ │ 时间序列图 │ │
│ │ 持续时间 │ │
│ │ 查询数量 │ │
│ │ 获取次数 │ │
│ │ 读取/写入 │ │
│ └────────────────────────┘ │
├─────────────────────────────────────────┤
│ 2. 顶级查询分析 │
│ ┌────────────────────────┐ │
│ │ 查询排名 │ │
│ │ │ │
│ │ 按持续时间───┐ │ │
│ │ │ │ │
│ │ 按时间 ────┤ │ │
│ │ 摘要 │ │ │
│ │ │ │ │
│ │ 按计划 ──── │ │ │
│ │ 摘要 │ │ │
│ │ │ │ │
│ │ 按频率 ──────┤ │ │
│ │ │ │ │
│ │ 按计划 ─── │ │ │
│ │ 频率 │ │ │
│ │ │ │ │
│ │ 按获取次数 ──┤ │ │
│ │ │ │ │
│ │ 按读取次数 ──┤ │ │
│ │ │ │ │
│ │ 按写入次数 ──┘ │ │
│ │ │ │
│ └────────────────────────┘ │
├─────────────────────────────────────────┤
│ 3. 进程摘要 │
│ ┌────────────────────────┐ │
│ │ 每个进程统计 │ │
│ │ - 执行次数 │ │
│ │ - 获取次数等 │ │
│ │ - 持续时间指标 │ │
│ └────────────────────────┘ │
├─────────────────────────────────────────┤
│ 4. 地址摘要 │
│ ┌────────────────────────┐ │
│ │每个客户端地址统计 │ │
│ │ - 连接次数 │ │
│ │ - 持续时间 │ │
│ │ - 获取次数等 │ │
│ │ - 进程名称 │ │
│ └────────────────────────┘ │
└─────────────────────────────────────────┘
查询详情结构：
┌────────────────────┐
│ 查询信息 │
├────────────────────┤
│ - SQL文本 │
│ - 事务信息 │
│ - 执行计划 │
│ - 持续时间统计 │
│ - 资源统计 │
│ * 获取次数 │
│ * 读取次数 │
│ * 写入次数 │
│ * 标记次数 │
│ - 客户端信息 │
└────────────────────┘性能报告提供了数据库活动的分层视图：
- 性能摘要图表
- 关键指标随时间变化的可视化表示 - 您可以轻松看到活动/负载的高峰期。（HQbird的高级性能监控中还提供每分钟分析报告，其简化版本可在门户工具上获取 - 观看此视频了解详情）。
- 有助于识别模式和异常：将性能良好时期（例如上周/上月）的图表与性能问题时期的图表进行比较，有助于识别问题。
- 顶级查询分析
- 多角度排名，便于全面分析：最长的查询、最频繁的查询、最耗时的查询（按文本或计划分组）等。
-
每个维度都揭示了不同的优化机会
-
每个查询的详细统计信息包括：
-
持续时间指标（最小值、最大值、平均值、中位数）
-
资源消耗（获取次数、读取次数、写入次数）
-
执行模式 - 顶级查询的来源数量。
- 进程摘要
-
按执行进程分组统计
-
有助于识别有问题的应用程序
-
显示每个进程的资源消耗和数据库操作（连接、查询等）及指标（获取次数、读取次数等）
- 地址摘要
-
按客户端连接分组统计
-
揭示客户端之间的负载分布
-
有助于识别特定连接的问题
每个部分支持不同级别的性能分析：
-
系统范围模式（图表） - 查看问题通常在何时何地发生。
-
查询最显著的影响（顶级查询） - 识别应首先优化的查询。
-
应用程序级别问题（进程摘要） - 识别产生性能问题的应用程序。
-
客户端级别问题（地址摘要） - 识别查询流量最大的IP地址（工作站、客户端计算机）。
2. 时间摘要和计划摘要分析
建议从摘要部分开始分析性能状况。点击此处打开示例报告中的计划摘要部分。
时间摘要汇总了每个唯一SQL语句模式的总执行时间。
可以将其视为“成本中心”报告，显示哪些查询随时间消耗了最多的数据库资源。
如果查询未参数化，即SQL文本中明确包含参数值而不是参数占位符（:myparam1），则需要使用“计划摘要”部分来识别频率最高的查询。非参数化查询示例：SELECT * FROM COUNTRY WHERE COUNTRYID=2
参数化查询示例：SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid
Summary 部分中的每个查询，其头部包含以下关键部分：
- **Summary（摘要）**：总时间百分比，显示该查询占整体数据库时间的比例。
- **Frequency（频率）**：该查询模式出现的次数。
- **Fetch、Read、Write（获取、读取、写入）**：资源指标。
例如，如果有
```none hljs
Summary: 19.08% (3920272 of 20541791 ms)这告诉我们该查询模式消耗了将近 20% 的数据库总时间–这是一个相当大的比例，值得立即关注。
在 Plan-Summary 部分的头部下方，我们会看到用于分组查询的 SQL 执行计划；而在 Time-Summary 中，则是查询本身的文本。
由于查询模式代表多个具体查询，关于连接的具体信息取自与该模式对应的第一个查询：
在上面的截图中，您可以看到该模式示例语句的头部，它包含发起此 SQL 的应用程序名称、连接 ID 和事务 ID，以及 IP 地址和事务的详细信息。
接下来是执行计划（对于 Time-Summary；对于 Plan-Summary 则跳过，因为它在开头已经显示）、参数值（按出现顺序）以及每个表的统计信息：
请记住，在 Plan-Summary 中，我们使用执行计划对 SQL 进行分组，这意味着只有执行计划对该模式是固定的；而在 Time-Summary 中，我们使用 SQL 语句文本来分组，其他内容（参数值、执行时间等）可能不同。请将此信息作为执行模式的示例（在 99% 的情况下，这足以重现问题）。
下面我们有一个针对该特定查询执行的单独图表。如您所见，该查询是在我们在概览图表中注意到的高负载期间启动的。
最后，我们有一个非常重要的统计集合，涵盖与该模式对应的所有查询，以及来源地址列表：
在这些统计信息中，我们可以看到最小值、最大值、平均值和中位数执行时间，以及获取、读取、写入和标记（缓存刷新操作）的相同统计信息。
2.1. 如何使用时间摘要（Time Summary）：
-
首先识别消耗不成比例时间的查询（它们是本部分的前 3 名–#1、2、3）
-
将时间消耗与频率进行比较
-
在查询部分底部查看平均执行时间（总时间 / 频率）（见下文）
-
寻找以下模式：
-
高时间 + 低频率 = 低效的单个查询
-
高时间 + 高频率 = 可能低效但使用频繁的查询
-
3. 频率分析：频率和计划频率（Frequency and Plan-Frequency）
使用频率分析来了解查询运行的频繁程度。可以把它想象成统计在高峰时段某条特定道路被使用了多少次。
如果查询未参数化，即 SQL 文本中显式包含参数值而不是参数占位符（:myparam1），则有必要使用“Plan-Summary”部分来识别频率最高的查询。
非参数化查询示例：'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
参数化查询示例：'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'3.1. 理解频率影响
频率查询模式的表示与 Plan/Time Summary 非常相似：
高频率查询就像繁忙的交叉路口–即使每辆车（查询）移动得很快，巨大的车流量也会导致拥堵。这会影响：
-
数据库连接（就像停车位–数量有限）
-
网络带宽（就像道路容量）
-
CPU 使用率（就像交通管制员不堪重负）
-
缓存效率（就像不得不反复访问相同的信息）
要评估高频率查询的影响，请使用参数 threshold = 0 收集跟踪信息。3.2. 频率影响类别
| 每秒执行次数 | 影响级别 | 潜在问题 |
|---|---|---|
| >1000 | 严重 | 就像高峰时段的交通–系统资源不堪重负 |
| 100-1000 | 高 | 类似于稳定的交通流–显著但可管理的负载 |
| 10-100 | 中等 | 像偶尔的交通–监控模式 |
| <10 | 低 | 交通量小–除非查询非常慢，否则影响最小 |
| 高频率并不总是坏事–如果查询优化良好，它们可以频繁运行而不会出现问题。关键是确保它们尽可能高效。实际上，这意味着前 3 个最频繁查询的查询中位执行时间应为 0 毫秒（即小于 1 毫秒），并且不超过总查询执行次数的 50%。 |
3.3. 示例分析
让我们检查我们跟踪报告中的一个真实案例：
Frequency: 4,428 executions (24.43% of total)
Impact: Critical - high volume of SALES table queries
Root Cause: Repetitive customer balance checks
Optimization Priority: High
Explanation: This query is running thousands of times, similar to a
busy intersection. Even though each execution might be quick, the
cumulative impact is significant. The application might be checking
balances more often than necessary.4. 分析 xx-Summary 和 Frequency 部分中顶级查询的统计信息
在分析 Firebird 跟踪报告时，每个查询分组都包含详细的聚合统计信息，这些信息为性能模式提供了关键见解。让我们分解每个指标并理解其对数据库优化的意义。
4.1. 聚合统计分析
让我们检查这组示例统计信息：
Total: 4428 items:
Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);
Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);
Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);
Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
From 1 unique addresses: TCPv6:::1 (4428)4.2. 执行次数分析
4.2.1. 总项目数
Total: 4428 items
这表示在跟踪期间该特定查询模式被执行的次数。
理解这个数字有助于您：
-
计算每次执行的资源使用情况
-
确定查询缓存是否有益（或者只是减少执行频率）
高执行次数可能表明存在以下机会：
-
使用预准备语句（和参数化）–相同的查询，相同的频率，如果参数化并准备重复执行，将需要更少的资源
-
添加结果缓存–缓存结果值以供长时间操作甚至更长时间（用户会话期间）使用，可以减少频繁执行查询的需要
-
批量操作–考虑一次执行查询以返回或处理多条记录，这将消除执行查询的开销（准备、网络传输等）。
4.3. 持续时间指标
4.3.1. 持续时间组成部分示例
Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);| 指标 | 值 | 意义 |
| 最小值 | 351ms | 最佳情况执行时间，有助于理解最佳条件 |
| 最大值 | 3919ms | 最差情况执行时间，有助于识别潜在问题 |
| 平均值 | 457.70ms | 典型执行时间，但可能受异常值影响 |
| 中位数 | 455.00ms | 中间值，对于偏态分布通常比平均值更具代表性 |
| 总和（%） | 2026710 (20.29%) | 消耗的总时间及占整个跟踪持续时间的百分比 |
4.3.2. 持续时间分析
-
中位数与平均值接近（457.70 毫秒对比 455.00 毫秒），表明性能表现稳定
-
最大值/最小值比率（约 11 倍）表明存在一定的波动性
-
占总时间的 20.29% 是显著的–此查询是否在频率或计划频率部分的前三名中？（是的，确实如此。）
4.4. 资源使用指标
4.4.1. 获取操作
Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);获取操作代表行检索：
-
获取次数一致（最小值与最大值仅相差 33）表明结果集稳定
-
相对较高的获取次数（每次执行超过 7000 次）可能表明：
-
如果返回大量记录，则需要限制结果集大小和/或进行分页。
-
查询优化的潜力–如果查询在频率/计划频率的前三名中，这一点尤其有意义。
4.5. 读取操作
Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);物理读取表示磁盘访问：
-
中位数为零但最大值非零，表明偶尔发生缓存未命中
-
占总读取量的 8.22% 表明 I/O 影响适中
-
最小值（0）与最大值（6995）之间的巨大差距表明缓存效率存在差异。
4.6. 写入操作
Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);如果查询不执行写入操作，通常这是一个只读操作。
4.7. 标记操作
Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);标记操作与数据页缓存管理相关：
-
零标记表示没有数据页被标记为需要刷新，这在简单的 SELECT 查询中很常见
-
非零标记操作与缓存相关
4.8. 客户端连接分析
From 1 unique addresses: TCPv6:::1 (4428)这显示了查询来源分布：
-
单一客户端地址表明这是特定于应用程序的查询
-
本地连接（::1 是 IPv6 本地回环地址）
-
所有 4428 次执行均来自同一来源
4.9. 使用这些指标进行优化
4.9.1. 性能模式分析
执行一致性
-
比较最小/最大持续时间
-
查找资源使用中的异常值
-
检查中位数与平均值之间的差异以了解波动性
资源使用模式
-
高获取次数 → 审查结果集大小
-
高读取次数 → 检查索引覆盖范围
-
高标记次数 → 检查锁争用情况
客户端影响分析
-
多个客户端 → 连接池大小调整
-
单一客户端 → 应用程序优化
4.9.2. 优化优先级
基于这些指标，按以下优先级进行优化：
-
结果集大小
-
每次执行 7000 次获取
-
考虑添加 LIMIT/OFFSET
-
审查 SELECT 列列表
缓存策略
-
频繁执行（4428 次）
-
结果大小一致
-
不涉及写入操作
可能此查询可以降低执行频率。索引使用
-
读取次数变化较大
-
读取中位数为零但最大值较高
-
审查索引覆盖范围
5. 实际应用
针对此特定示例：
短期改进：
-
实施结果缓存（执行次数高，获取次数一致）
-
审查结果集大小（每次执行超过 7000 次获取）
中期优化：
-
分析索引使用模式
-
考虑使用预编译语句
-
审查应用程序逻辑以降低执行频率
长期考虑：
-
随时间监控执行模式
-
规划索引维护策略
-
考虑数据访问模式的变化
| 请记住，这些指标应综合分析，而非孤立看待。某一类别中的高数值在其他指标表现最优时可能是可以接受的。对跟踪指标的全面理解有助于为数据库优化策略做出明智决策。 |
6. 持续时间分析
持续时间分析检查单个查询执行所需的时间。可以把持续时间想象成对每个查询计时的秒表–查询耗时越长，越可能导致性能问题。
6.1. 理解持续时间指标
持续时间指标至关重要，因为它们直接影响用户体验，即用户抱怨"系统很慢"。就像顾客在长队中等待会感到沮丧一样，当查询耗时过长时用户也会感到不满。长时间运行的查询会导致：
-
屏幕加载时间过长，用户体验不佳
-
系统资源长时间被占用
-
其他查询在慢查询后面排队等待
-
应用程序中可能出现超时问题
6.2. 影响分类
| 持续时间范围 | 影响级别 | 建议措施 |
|---|---|---|
| >10 秒 | 严重 | 这些查询就像高速公路上的交通事故–它们会阻塞后方所有交通，需要立即处理 |
| 1-10 秒 | 高 | 就像黄色交通灯，这些查询是需要尽快关注的警示信号 |
| 100 毫秒-1 秒 | 中等 | 类似于缓慢移动的交通，这些查询需要监控但并非关键问题 |
| <100 毫秒 | 低 | 这些查询运行顺畅，仅在发生频率极高时才需要关注 |
6.3. 示例分析
Duration: 77,793ms
Impact: Critical - single query consuming 77.7 seconds
Root Cause: Complex aggregation in PRC_COLLECT_RANKCATEGORY
Optimization Priority: Immediate
Explanation: This query is taking over a minute to execute, which is like
a complete traffic stoppage. The stored procedure is likely processing
too much data or using inefficient algorithms.7. 实施策略
可以把优化想象成改进交通系统–你需要识别问题、规划解决方案并谨慎实施变更。
7.1. 优先级矩阵
此矩阵帮助您决定哪些问题需要优先处理，就像对城市中的交通问题进行分流一样：
| 指标 | 高影响 | 中等影响 | 低影响 |
|---|---|---|---|
| 持续时间 | 交通堵塞（>10 秒） | 交通缓慢（1-10 秒） | 通行顺畅（<1 秒） |
| 频率 | 高峰时段（>1000 次/秒） | 稳定流量（100-1000 次/秒） | 低流量（<100 次/秒） |
| 获取次数 | 移动仓库（>1000 万） | 大批量运输（100 万-1000 万） | 小批量配送（<100 万） |
| 读取次数 | 全市范围搜索（>10 万） | 社区范围搜索（1 万-10 万） | 街道范围搜索（<1 万） |
7.2. 分步优化流程
- 识别关键查询
-
查找最大的交通堵塞（慢查询）
-
找到最繁忙的交叉路口（高频率查询）
-
发现低效路线（高资源使用）
- 分析执行计划
-
研究当前路线（索引使用）
-
检查交通模式（连接方法）
-
检查瓶颈（排序操作）
- 实施优化
-
修建新道路（索引）
-
重新设计路线（重构查询）
-
添加捷径（缓存）
- 验证改进效果
-
测量新的交通流量（新的跟踪报告）
-
比较优化前后的指标
-
记录有效的方法
如有任何问题，请联系 IBSurgeon
如有任何疑问，欢迎随时联系我们：[email protected]。