性能与技巧练习

发表于 更新于 分类于 ， ， 阅读次数： 本文字数： 1.5k 阅读时长 ≈ 6 分钟

性能与技巧练习 (10题)

#practice #performance #best-practices #analysis-tools

相关概念

📌核心模式（点击查看）
关键词 答案
循环中的 SELECT 反模式 – 使用 JOIN 或预缓冲
标准表线性搜索 改用排序/哈希表
LOOP 中的 ASSIGNING 避免数据复制
代码检查器事务 SCI
SQL 跟踪事务 ST05
运行时分析提示 使用 Aggregation = None 变体

第1题 - 反模式：循环中的 SELECT [记忆]

为什么 LOOP 中的 SELECT 被视为性能反模式？

📌点击查看答案
每次迭代触发一次独立的数据库访问，导致：
  • 高网络开销（n 行需要 n 次往返）
  • 数据库因重复语句准备和执行而承受负载
  • 绕过潜在的缓冲优化

应改用 JOIN、FOR ALL ENTRIES 或在循环前将数据预缓冲到内表。

第2题 - 内表类型性能 [应用]

有一个包含 100,000 条记录的标准表，需要按键读取 50,000 次。做什么改变能带来最大的性能提升？

📌点击查看答案
改为使用读取键的哈希表：
1
2
3
4
5
" 之前：每次读取 O(n) = 100,000 * 50,000 次操作
DATA: itab TYPE STANDARD TABLE OF ...

" 之后：每次读取 O(1) = 50,000 次哈希查找
DATA: itab TYPE HASHED TABLE OF ... WITH UNIQUE KEY key_field

或者如果还需要索引访问，使用排序表。两者都比标准表线性搜索快得多。

第3题 - ASSIGNING 性能 [记忆]

LOOP AT itab ASSIGNING <fs> 相比 LOOP AT itab INTO wa 有什么性能优势？

📌点击查看答案
ASSIGNING 提供指向表行的直接引用 – 无数据复制。INTO wa 每次迭代都将整行复制到工作区，而 MODIFY itab FROM wa 又复制回去。

对于大型行结构或大量迭代，ASSIGNING 消除了所有复制开销。通过字段符号的更改直接修改表行。

第4题 - SELECT 优化 [应用]

程序读取 SELECT * FROM sbook WHERE customid = lv_id，但只使用 BOOKID、FLDATE 和 PRICE 字段。应如何优化？

📌点击查看答案
仅指定需要的列：
1
2
3
SELECT bookid fldate price FROM sbook
  INTO TABLE lt_bookings
  WHERE customid = lv_id.

好处：减少数据库数据传输、减少应用服务器内存、可能使用覆盖索引。

第5题 - 表缓冲策略 [应用]

何时应使用 SAP 表缓冲，何时应避免？

📌点击查看答案
使用缓冲的条件：
  • 表频繁读取但很少更改
  • 表相对较小（完全缓冲）或按泛型键访问
  • 与数据库的数据一致性不是关键（可接受轻微延迟）

避免缓冲的条件：

  • 表频繁更改（失效开销）
  • 表非常大（内存压力）
  • 需要实时数据（缓冲可能过期）
  • 访问始终通过 JOIN（缓冲会被绕过）

第6题 - 代码检查器使用 [记忆]

代码检查器使用什么事务？主要检查类别有哪些？

📌点击查看答案
事务 SCI。主要检查类别：
  • 通用检查：数据格式
  • 性能检查：WHERE 分析、缓冲绕过、低效表访问
  • 安全检查：跨客户端访问、不充分的权限检查
  • 语法检查/生成：扩展程序检查
  • 编程规范：命名规范
  • 搜索功能：令牌和语句搜索

第7题 - SQL 跟踪分析 [记忆]

SELECT 语句的 SQL 跟踪操作有哪些？各自做什么？

📌点击查看答案
  1. PREPARE：解析 SQL 文本，确定访问策略（优化器），创建执行计划
  2. OPEN/REOPEN：用实际值替换绑定变量，打开游标
  3. FETCH：将记录从数据库服务器传输到应用服务器

对于写操作，EXEC/REEXEC 替代 OPEN/REOPEN 和 FETCH。
SAP 游标缓存可以跳过相同 SQL 结构的 PREPARE。

第8题 - 运行时分析 [应用]

需要找出程序中最耗时的 ABAP 语句。描述使用运行时分析的步骤。

📌点击查看答案
  1. 调用运行时分析（事务 SAT 或 SE30）
  2. 创建 Aggregation = None 的变体以获取详细结果
  3. 输入程序名并执行
  4. 执行后点击分析
  5. 使用分组命中列表查看按调用类型（子程序、FM、方法、表操作）的时间分布
  6. 按总时间降序排列找到最耗时的操作
  7. 双击单个项目并按显示源代码查看精确的语句

第9题 - 性能比较 [分析]

一位同事建议在 1000 条记录的循环中使用 SELECT SINGLE，对比单次 FOR ALL ENTRIES。比较两种方案。

📌点击查看答案
方案 数据库调用 性能
循环中的 SELECT SINGLE 1000 次调用 非常差（1000 次往返）
FOR ALL ENTRIES 1 次调用（或少量） 好得多

FOR ALL ENTRIES 远优于循环方式，因为它将所有查找合并到单个 SQL 语句中。但需确保驱动表非空且不太大。

更好的方案：如果两个数据库表之间有关系，使用 JOIN，因为它完全避免了中间步骤。

第10题 - 新旧调试器对比 [分析]

何时需要使用新调试器而非传统调试器？

📌点击查看答案
在以下情况使用新调试器：
  • 调试转换出口或字段出口（旧调试器不支持）
  • 在调试会话之间保持调试器设置
  • 使用可配置 UI和多个桌面
  • 避免干扰应用程序的滚动区

新调试器在独立的外部会话中运行，消除了干扰。但它需要一个可用的外部会话（每用户最多 6 个 – 如果已打开 6 个，则无法启动新调试器）。

📌模式总结（点击查看）
关键词 答案
循环中的 SELECT 反模式；使用 JOIN/预缓冲
哈希表查找 O(1) vs 标准表的 O(n)
ASSIGNING 无复制，直接修改
SELECT * 反模式；指定列
何时缓冲 读多改少，小表
SCI 代码检查器事务
ST05 SQL 跟踪事务
PREPARE/OPEN/FETCH SELECT 的 SQL 跟踪操作