单元 3：表访问性能练习（8 道题）
单元 3：表访问性能练习（8 道题）
#practice #abap #abap-dictionary #abap-performance
相关概念
📌关键模式（点击展开）
| Keyword (关键词) | Answer (答案) |
|---|---|
| 主索引 | 键字段上自动创建，ID 为 0 |
| 二级索引命名 | 客户创建以 Y 或 Z 开头 |
| 索引使用范围 | 只到最后一个在 WHERE 中指定的字段 |
| 完全缓冲触发 | 访问任一记录时加载全表 |
| 缓冲性能提升 | 10 到 100 倍 |
| /$TAB | 重置表缓冲（仅修复不一致） |
问题 1 - 主索引与二级索引 [recall]
主索引和二级索引有什么区别？
📌显示答案
| 对比项 | 主索引 | 二级索引 |
|---|---|---|
| 创建方式 | 自动创建 | 手动创建 |
| 索引 ID | 0 | 客户创建以 Y 或 Z 开头 |
| 基于字段 | 键字段 | WHERE 中频繁使用的非键字段 |
| 唯一性 | 始终唯一 | 可设为 Unique 或 Non-unique |
问题 2 - 索引使用规则 [recall]
当 WHERE 子句中使用了索引字段，但跳过了中间某个字段时，索引还能被完全利用吗？解释原因。
📌显示答案
不能。索引只能使用到最后一个在 WHERE 中指定的字段。跳过中间字段后，后续字段无法使用索引。因此：
- WHERE 中出现频率高的字段应放在索引前面
- 跳过索引中间字段会导致后续字段查找退化为全表扫描
- 只有显著减少数据量的字段才有意义加入索引
问题 3 - 缓冲类型 [recall]
ABAP 字典提供哪三种表缓冲类型？分别适用于什么场景？
📌显示答案
| 缓冲类型 | 触发条件 | 加载内容 | 适用场景 |
|---|---|---|---|
| 完全缓冲 (Full) | 访问任一记录 | 全表所有记录 | ≤10,000 条，读频繁，很少修改 |
| 通用缓冲 (Generic) | 访问某记录 | 同一左键前缀的所有记录 | 按键前缀分组访问 |
| 单记录缓冲 (Single-record) | 访问某记录 | 仅该条记录 | 大表、随机访问 |
问题 4 - 缓冲同步机制 [recall]
当某个应用服务器修改了被缓冲的表数据时，其他应用服务器的缓冲如何处理？
📌显示答案
数据修改时，所有应用服务器的缓冲被标记失效。失效后的第一次访问需要从数据库重新加载。同步是异步执行的。这意味着在短暂时间窗口内，其他服务器可能读取到旧数据。
问题 5 - 索引设计建议 [recall]
创建二级索引时，有哪些关键考虑因素？
📌显示答案
| 考虑因素 | 建议 |
|---|---|
| 字段顺序 | 高频 WHERE 字段在前 |
| 字段数量 | 选择区分度高的字段 |
| 表修改频率 | 频繁修改的表不要太多索引（每次修改都需调整索引排序） |
| 索引互斥性 | 同一表的索引尽量不相交 |
| 数据库特定 | 可指定只在特定 DB 上创建 |
| 唯一性 | 如有键功能，设为 Unique Index |
问题 6 - 缓冲选择决策 [application]
一个自定义表 ZCONFIG 有 500 条配置数据，每天被读取数千次，每月只修改 1-2 次。应该选择哪种缓冲类型？为什么？
📌显示答案
应选择完全缓冲 (Full Buffering)：
- 数据量小（500 条，远低于 10,000 条阈值）
- 读取频率高（每天数千次）
- 修改频率极低（每月 1-2 次）
- 完全缓冲在首次访问时加载全表到内存，后续读取直接从内存获取，性能提升 10-100 倍
- 修改频率低意味着缓冲失效很少发生
问题 7 - 索引使用分析 [application]
表 SPFLI 有二级索引 A11，字段顺序为 (CITYFROM, CITYTO)。以下哪个 WHERE 子句能充分利用该索引？
- (a)
WHERE cityto = 'TOKYO'- (b)
WHERE cityfrom = 'NEW YORK' AND cityto = 'TOKYO'- (c)
WHERE cityfrom = 'NEW YORK' AND carrid = 'AA' AND cityto = 'TOKYO'
📌显示答案
- (a) 不能使用索引 — 跳过了第一个字段 CITYFROM，直接使用 CITYTO 无法利用索引
- (b) 可以完全利用索引 — 两个字段都按顺序指定
- (c) 只能使用索引的 CITYFROM 部分 — 因为中间出现了非索引字段 carrid，CITYTO 无法利用索引（索引只能使用到最后一个连续指定的字段）
问题 8 - 性能优化综合分析 [analysis]
一个大型事务表（100 万+行）被多用户频繁按 (CARRID, CONNID, FLDATE) 查询，同时也经常按 CARRID 单独统计。表的数据每天批量更新一次。请设计索引和缓冲策略。
📌显示答案
索引策略：
- 主索引（已有）：键字段上自动创建
- 二级索引 1：(CARRID, CONNID, FLDATE) — 用于频繁的组合查询
- 二级索引 2：(CARRID) — 用于按 CARRID 的统计查询
- 由于是事务表且每天更新，索引数量应控制在 2-3 个以内
缓冲策略：
- 不建议缓冲 — 因为是大表（100 万+行）且频繁修改
- 完全缓冲不适合（数据量太大）
- 单记录缓冲也不适合（频繁批量更新会导致缓冲不断失效）
- 应通过合理的索引来优化查询性能
📌模式总结（点击展开）
| Keyword (关键词) | Answer (答案) |
|---|---|
| 主索引 | 自动创建，ID 为 0，基于键字段 |
| 二级索引 | 手动创建，Y/Z 开头 |
| 索引使用规则 | 只到最后一个连续 WHERE 字段 |
| 完全缓冲 | 访问任一记录加载全表，≤10,000 条 |
| 通用缓冲 | 按键前缀加载 |
| 单记录缓冲 | 仅加载访问的记录 |
| 缓冲同步 | 修改时所有服务器标记失效，异步执行 |
| /$TAB | 重置缓冲，仅修复不一致 |