SAP 性能优化最佳实践
SAP 系统性能优化是一个系统工程，涉及 ABAP 代码、数据库、系统配置和前端表现等多个层面。本文从实际项目经验出发，系统梳理了各层面的优化最佳实践，并提供了具体的工具使用指南和代码示例。
一、ABAP 层面优化
1.1 SELECT 语句优化
SELECT 语句是 ABAP 性能问题的首要来源，以下是最关键的优化要点：
（1）避免 SELECT *
" ❌ 不推荐：读取所有字段
SELECT * FROM bkpf INTO TABLE @DATA(lt_bkpf) WHERE bukrs = @p_bukrs.
" ✅ 推荐：只读取需要的字段
SELECT belnr, gjahr, blart, budat FROM bkpf
INTO TABLE @DATA(lt_bkpf)
WHERE bukrs = @p_bukrs.（2）合理使用 WHERE 条件
" ❌ 不推荐：在 ABAP 层过滤
SELECT * FROM bkpf INTO TABLE @DATA(lt_bkpf).
DELETE lt_bkpf WHERE bukrs <> p_bukrs.
" ✅ 推荐：在数据库层过滤
SELECT belnr, gjahr FROM bkpf
INTO TABLE @DATA(lt_bkpf)
WHERE bukrs = @p_bukrs
AND budat IN @s_budat.（3）使用 UP TO n ROWS 限制结果集
" 仅需检查是否存在记录时
SELECT SINGLE matnr FROM mara INTO @DATA(lv_matnr) WHERE matnr = @p_matnr.
" 需要限制行数时
SELECT matnr, maktx FROM makt
INTO TABLE @DATA(lt_makt) UP TO 100 ROWS
WHERE spras = @sy-langu.（4）使用 JOIN 替代嵌套 SELECT
" ❌ 不推荐：嵌套 SELECT（N+1 问题）
SELECT vbeln, kunnr FROM vbak INTO TABLE @DATA(lt_vbak).
LOOP AT lt_vbak INTO DATA(ls_vbak).
SELECT name1 FROM kna1 INTO @DATA(lv_name1) WHERE kunnr = @ls_vbak-kunnr.
ENDLOOP.
" ✅ 推荐：使用 JOIN
SELECT vbak~vbeln, vbak~kunnr, kna1~name1
FROM vbak
INNER JOIN kna1 ON vbak~kunnr = kna1~kunnr
INTO TABLE @DATA(lt_result)
WHERE vbak~vbeln IN @s_vbeln.（5）合理使用 FOR ALL ENTRIES
" 使用前务必检查内表是否为空
IF gt_vbak IS NOT INITIAL.
SELECT vbeln, posnr, matnr FROM vbap
INTO TABLE @DATA(lt_vbap)
FOR ALL ENTRIES IN @gt_vbak
WHERE vbeln = @gt_vbak-vbeln.
ENDIF.注意
在 HANA 数据库上，JOIN 通常比 FOR ALL ENTRIES 性能更好，因为 HANA 对 JOIN 有专门的优化引擎。优先使用 JOIN，仅在无法用 JOIN 表达时才使用 FOR ALL ENTRIES。
1.2 内表操作优化
| 优化点 | 不推荐写法 | 推荐写法 | 性能提升 |
|---|---|---|---|
| 遍历修改 | LOOP AT itab INTO wa. MODIFY itab. ENDLOOP. | LOOP AT itab ASSIGNING FIELD-SYMBOL(<fs>). | 避免数据复制 |
| 内表查找 | STANDARD 表 + 顺序查找 | SORTED/HASHED 表 + 二分/哈希查找 | O(n) → O(log n) 或 O(1) |
| 嵌套循环 | 两层 LOOP AT ... WHERE | 内层使用 SORTED 表的表表达式 | 数量级提升 |
| 删除重复 | 循环 + READ TABLE 判断 | SORT itab. DELETE ADJACENT DUPLICATES. | 显著提升 |
| 批量插入 | 循环 APPEND | itab = VALUE #( FOR ... ) | 预分配内存 |
1.3 缓冲表使用
对访问频率高、数据量小、更新少的表启用 SAP 表缓冲：
- 完全缓冲：适用于配置表（如 T001、T000、T005），首次访问时整表加载
- 通用缓冲：适用于按通用键（如集团）访问的表
- 单记录缓冲：适用于大表但单条记录频繁访问（如 KNA1、LFA1）
最佳实践
开启缓冲后，使用 ST05 跟踪缓冲命中率。如果命中率低于 90%，说明该表不适合缓冲或缓冲类型配置不当。对于频繁更新的表（如 BKPF、BSEG），不建议开启缓冲。
1.4 并行处理
对于可拆分的计算密集型任务，可以使用 ABAP 异步并行处理：
" 使用异步函数模块实现并行处理
DATA: lt_task TYPE TABLE OF indx.
DO 10 TIMES.
CALL FUNCTION 'Z_PARALLEL_PROCESS'
STARTING NEW TASK lv_taskname
DESTINATION IN GROUP p_group
PERFORMING task_result ON END OF TASK
EXPORTING
iv_index = sy-index
EXCEPTIONS
system_failure = 1
communication_failure = 2
resource_failure = 3
OTHERS = 4.
ENDDO.
" 等待所有任务完成
WAIT UNTIL lv_completed = lv_total.注意：并行处理需要足够的对话工作进程（DIA WP），在 RZ12 中配置服务器组。
二、数据库层面优化
2.1 HANA 数据库优化
SAP HANA 是内存数据库，优化策略与传统磁盘数据库有所不同：
| 优化项 | 说明 | 相关事务码/工具 |
|---|---|---|
| 列存储 vs 行存储 | 分析型查询优先使用列存储，事务型操作可用行存储 | DBACOCKPIT → Tables |
| 内存管理 | 监控 HANA 内存使用，确保无内存泄漏 | DBACOCKPIT → Performance → Memory |
| Delta 存储 | 频繁更新的表会产生 Delta 存储，需定期合并（Merge） | DBACOCKPIT → Delta Storage |
| SQL 计划缓存 | 清理过时的 SQL 执行计划 | DBACOCKPIT → SQL Cache |
| 分区策略 | 大表按年份或公司代码分区，提升查询和维护效率 | DBACOCKPIT → Table Partitioning |
2.2 索引策略
正确的索引策略是数据库性能的关键：
- 主键索引：SAP 所有表自动创建主键索引，无需手动处理
- 二级索引：为常用查询条件创建二级索引（通过 SE11 → Indexes 创建）
- 索引设计原则：
- 选择性高的字段放在索引前面
- 避免在索引中包含频繁更新的字段
- 一个表的二级索引不超过 5 个
- 定期检查未使用的索引（通过 DBACOCKPIT）
索引使用检查
使用 ST05 SQL Trace 可以查看某条 SQL 语句是否使用了索引。如果出现全表扫描，考虑创建或调整索引。在 HANA 上，还可以使用 EXPLAIN PLAN 查看执行计划。
2.3 SQL 监控
持续监控 SQL 性能是优化的重要环节：
- ST05：SQL Trace，跟踪特定用户的数据库访问
- DBACOCKPIT：全面的数据库监控工具，包含 SQL、内存、锁等各维度
- ST03N：系统级性能分析，查看哪些事务码和程序最耗时
- HANA Studio / SAP HANA Cockpit：HANA 专属的监控和管理工具
三、系统层面优化
3.1 内存参数调优
SAP 系统的内存参数直接影响性能，关键参数包括：
| 参数 | 说明 | 推荐值/调整方法 |
|---|---|---|
| ztta/roll_area | ROLL 区大小（每个工作进程） | 默认通常足够，不建议大幅调整 |
| ztta/roll_extension | 扩展内存大小 | 根据用户数和程序复杂度调整 |
| em/initial_size_MB | 扩展内存初始大小 | 建议物理内存的 50-70% |
| abap/heap_area_dia | 对话工作进程堆内存上限 | 防止单个会话占用过多内存 |
| abap/heap_area_nondia | 非对话工作进程堆内存上限 | 后台作业通常需要更大堆内存 |
| rsdb/uni/buffer_size | UNI 缓冲区大小 | 影响表缓冲效率 |
调整方法：通过 RZ11（动态参数，立即生效）或 RZ10（静态参数，需重启）修改。
3.2 工作进程配置
工作进程数量和类型配置是系统性能的基础：
| 工作进程类型 | 功能 | 配置建议 |
|---|---|---|
| DIA（对话） | 处理用户交互 | 按用户数配置，通常最多 |
| UPD（更新） | 处理 V1 更新（关键业务数据） | 至少 2 个 |
| UP2（更新2） | 处理 V2 更新（统计数据等） | 至少 1 个 |
| BGD（后台） | 执行后台作业 | 根据作业量配置 |
| SPO（假脱机） | 打印请求处理 | 至少 1 个 |
| ENQ（入队） | 锁管理 | 通常 1 个即可 |
通过 RZ04 配置工作进程数量，SM50 监控工作进程状态。
3.3 ST03N 性能分析
ST03N 是 SAP 系统级性能分析的核心工具：
- 查看方式：ST03N → Expert Mode → 选择时间范围和实例
- 关键指标：
- 平均响应时间（目标 < 1 秒）
- 数据库请求时间（占总响应时间的比例）
- CPU 时间
- 等待时间（排队等待工作进程的时间）
- GUI 时间（网络传输时间）
- 分析思路：
- 响应时间突然增加 → 检查是否有大量后台作业占用资源
- 数据库时间占比过高 → 检查是否有慢 SQL 或缺少索引
- 等待时间过长 → 增加对话工作进程或优化长时间运行的对话
四、前端层面优化
4.1 SAP GUI vs Fiori 性能对比
| 对比维度 | SAP GUI | SAP Fiori |
|---|---|---|
| 协议 | DIAG/SAPGUI 协议（二进制压缩） | HTTPS + OData（REST API） |
| 数据传输量 | 较小（仅传输增量数据） | 取决于 OData 调用设计 |
| 首次加载 | 需要安装 SAP GUI 客户端 | 浏览器直接访问，但首次加载需下载资源 |
| 交互延迟 | 极低（本地渲染） | 依赖网络延迟（建议 < 100ms） |
| 批量操作 | 支持批量输入（BDC） | 支持批量操作（取决于 App 设计） |
| 适用场景 | 内部网高速环境、大量数据录入 | 移动办公、决策支持、自助服务 |
4.2 网络优化
网络延迟是影响 Fiori 性能的关键因素：
- SAP GUI：使用 SAP Router 或 VPN 减少网络跳数；启用 SAP GUI 压缩（参数
sapgui/compress） - Fiori：
- 启用 CDN 加速静态资源
- 使用 HTTP/2 减少连接开销
- 优化 OData 请求，避免 $expand 过深嵌套
- 启用浏览器缓存（Fiori Launchpad 的缓存策略）
4.3 ALV 报表性能
ALV 是 SAP 中最常用的报表展示方式，性能优化要点：
- 限制数据量：使用选择屏幕充分过滤，避免一次加载数十万行
- 优化排序：在 SQL 层面完成排序（
ORDER BY），而非 ABAP 层面SORT - 延迟加载：先显示汇总数据，用户点击后再加载明细
- 使用 ALV 标准功能：如过滤、排序等由前端处理，不需要重新查询数据库
五、监控工具详解
5.1 工具速查表
| 事务码 | 工具名称 | 主要用途 | 使用场景 |
|---|---|---|---|
| ST05 | SQL Trace | 跟踪 SQL 语句执行 | 分析慢查询、检查索引使用、缓冲命中率 |
| ST03N | Workload Monitor | 系统负载分析 | 查看响应时间趋势、识别热点事务码 |
| SAT | ABAP Runtime Analysis | ABAP 程序运行时分析 | 定位程序中耗时最长的方法/语句 |
| SE30 | Runtime Analysis（旧版） | ABAP 运行时分析（旧版） | 兼容性用途，建议使用 SAT |
| SM50/SM66 | Process Overview | 查看工作进程状态 | 检查阻塞、长运行进程、系统负载 |
| DBACOCKPIT | DBA Cockpit | 数据库管理监控 | HANA 内存、SQL 监控、备份、分区管理 |
| SM21 | System Log | 系统日志 | 查看系统错误、警告信息 |
| ST22 | ABAP Dump Analysis | ABAP 运行时错误 | 分析程序中断原因 |
5.2 ST05 SQL Trace 使用详解
- 启动跟踪：ST05 → 勾选 SQL Trace → Activate Trace
- 执行业务操作：在目标会话中执行需要分析的操作
- 停止跟踪：Deactivate Trace
- 查看结果：Display Trace → 按需排序
分析重点：
- 按 Duration 降序排列，找出最慢的 SQL
- 按 Records 降序排列，找出读取最多行的 SQL（可能缺少索引）
- 按 Statement 分组，找出重复执行的 SQL（可能存在 N+1 问题）
- 查看 Buffer 列，统计缓冲命中/未命中的比例
5.3 SAT 运行时分析使用详解
- 创建测量：SAT → 创建测量请求，指定事务码或程序名
- 执行测量：SAT 自动跟踪指定程序的执行
- 分析结果：
- Hierarchical（层次视图）：查看调用链中各方法的耗时
- Hit List（命中列表）：按耗时排列所有执行单元
- Timeline（时间线）：查看执行过程中各阶段的时间分布
优化方向：如果大部分时间花在数据库访问上，优化 SQL；如果大部分时间花在 ABAP 处理上，优化内表操作和算法。
5.4 性能优化检查清单
| 层面 | 检查项 | 目标值 | 工具 |
|---|---|---|---|
| ABAP | 是否存在 SELECT * | 全部改为字段列表 | ST05, ATC |
| ABAP | 内表类型是否合理 | 查找频繁的表使用 SORTED/HASHED | SAT, Code Review |
| ABAP | 是否存在嵌套循环 | 替换为 JOIN 或 SORTED 表查找 | SAT |
| ABAP | 缓冲命中率 | > 90% | ST05 |
| 数据库 | 慢 SQL 数量 | 响应时间 < 1 秒 | ST05, DBACOCKPIT |
| 数据库 | 索引使用情况 | 无全表扫描 | ST05, EXPLAIN PLAN |
| 数据库 | HANA 内存使用率 | < 80% | DBACOCKPIT |
| 系统 | 平均响应时间 | < 1 秒 | ST03N |
| 系统 | 对话等待时间 | < 10% 总响应时间 | ST03N |
| 系统 | 工作进程利用率 | 峰值 < 90% | SM50, ST03N |
| 前端 | Fiori 页面加载时间 | < 3 秒 | 浏览器 DevTools |
| 前端 | 网络延迟 | < 100ms | Ping, Traceroute |
来源说明：本文内容由作者基于多年 SAP 性能优化项目经验整理，仅用于内部技术分享与学习交流。