用途
Debug Slow SQL / OData 用于找出 ABAP SQL 或 Fiori-Elements OData 请求变慢的根本原因，并提出修复建议。它优先使用 ARC-1 做无 GUI 诊断，只有在需要更深层信号时才升级到 SAP GUI / Fiori 应用。目标不是确认“它很慢”，而是回答为什么慢：哪条语句慢、扫描了什么、该改什么。
适用触发场景包括：慢报表或慢事务、慢 OData/Fiori 列表、长时间运行的 CDS 视图、高负载下的超时或 dump，以及“这个查询在某次变更后变慢”等。
主要能力
诊断按从低成本的“诊断阶梯”自上而下进行，在某一步能解释问题时就停止：
- 第 0 级：定位。通过 SAPContext 读取 CDS/ABAP 源码并评估影响，检查常见可疑点，如
LIKE '%term%'、无键 WHERE 的 SELECT、SELECT *、循环中的嵌套 SELECT（N+1）、客户端过滤等。同时区分手写 SQL 与由搜索帮助、SADL/RAP 或框架生成的 SQL，追踪生成器而非字面 SQL。 - 第 1 级：时间花在哪。对 OData/Fiori 请求用 SAPDiagnose(action="odata_perf") 判断耗时归属：db（数据库）进入第 2 级；app（ABAP/SADL 逻辑）进入第 3 级；framework（元数据/冷缓存）可重新预热探测；auth（授权开销）单独处理。
- 第 2 级：数据库瓶颈。用 SAPDiagnose(action="cds_sql") 查看 CDS 编译出的原生视图，再用 SAPQuery 结合真实过滤条件测量 queryExecutionTimeMs、totalRows 等指标，判断是否为扫描或选择性差。
- 第 3 级：应用瓶颈。使用 SAPDiagnose(action="traces") 列出并分析 ABAP 性能跟踪，查看热点调用路径与 dbAccesses 表访问次数。
- 第 4 级：精确 SQL 与执行计划。用 SAPDiagnose 启停 ST05 SQL 跟踪，并通过深链在 TMC Fiori 应用或 SAP GUI ST05 中查看记录；ARC-1 无法通过 ADT 读取 SQL 记录。
- 第 5 级：静态检查。随时可用 SAPDiagnose(action="atc", variant="PERFORMANCE_DB") 静态标记性能反模式。
技能还提供根因目录（症状 → 可能原因 → 确认方式 → 修复），覆盖全表扫描、前导通配符 LIKE、N+1、过度获取、开发环境快生产环境慢、SADL 应用层耗时、首次调用慢、负载下超时及内存 dump 等模式。
使用方式
使用时需向用户确认缺失的输入：慢的是什么（OData URL、CDS/DDLS 名称、ABAP 程序/类/报表、事务码，或表加访问模式）；有多慢、多频繁；能否按需复现及在哪个系统和哪个 SAP 用户下复现；是否有近期变更。
关键调用包括 SAPContext、SAPRead、SAPSearch、SAPNavigate、SAPDiagnose 和 SAPQuery。获取 OData URL 时从浏览器 DevTools 的 Network 标签复制主机后的路径。输出应是一份紧凑的诊断报告，包括：结论（附证明数字，引用 SAP 的 gwtotal/gwappdb 而非 wallClockMs）、问题语句、一句话根因、最小修复方案、证据（运行过的 ARC-1 调用及跟踪记录），并始终解除已开启的跟踪。
适用场景
- 定位单次慢调用的具体 SQL。
- 区分数据库、应用、框架或授权层导致的慢。
- 排查 N+1、全表扫描、选择性差等性能反模式。
- 在无 SAP GUI 的环境下做初步诊断。
限制
- 第 3–4 级需要 SAP_ALLOW_WRITES、S_ADT_RES 及相关后端授权，且 NW 7.50 上不存在。若无法开启跟踪，则停留在第 2 级，向用户提供 ST05/SAT 的具体步骤。
- odata_perf 需要 SAP_ALLOW_DATA_PREVIEW，URL 必须是 SAP 主机上 /sap/opu/odata 或 /sap/opu/odata4 下的相对路径，且只做 GET。
- SAPQuery 不暴露 HANA 执行计划或缓冲区状态，且无法用其验证 CONTAINS / 模糊搜索类修复，因为 ADT 自由端点只接受 Open-SQL。
- 读取 SQL 跟踪记录和执行计划需要升级到 SAP GUI（ST05）或 TMC Fiori 应用（SQL Trace Analysis），且后者需激活 /sap/bc/stmc SICF 节点。
- 生产环境应优先只读信号，开启 ST05 跟踪或改动状态前需明确批准。