哥们，我太懂这种SAP里碰到底层性能问题又不敢动索引的憋屈了！既然不能加索引怕影响SAP支持，咱们从SQL写法、SAP专属优化和数据处理策略这几个方向来抠性能，给你整理几个靠谱的方案：

• 尽早过滤数据：把WHERE里的筛选条件（比如日期范围、特定客户类型）尽可能前置，别等关联完所有表再过滤。比如如果只需要近一年的数据，直接在销售订单表（T1）和发票表（T3）上加T1."DocDate" >= '2023-01-01' AND T3."DocDate" >= '2023-01-01'，从源头减少后续关联的数据量。
• 用SAP标准关联字段：SAP业务表（比如ORDR、OINV）之间的关联，优先用系统默认的BaseEntry+BaseType组合，比如T1（销售订单）关联T3（发票）时，写T1."DocEntry" = T3."BaseEntry" AND T3."BaseType" = '17'（17是销售订单的BaseType编码），别用非标准字段关联——这些默认关联字段哪怕没显式索引，SAP底层也有隐性优化逻辑。
• 砍掉冗余字段和计算：别用SELECT *，只保留你实际需要的字段；像ISNULL(T2."PriceBefDi"*T2."Quantity", 0)这种 runtime 计算，看看有没有SAP预存的字段（比如行项目表的LineTotal）可以直接用，避免重复计算开销。

• 开启批量读取模式：如果是在SAP系统内运行查询（比如ABAP程序、SQVI），用PACKAGE SIZE分批次拉取数据，别一次性把百万条记录塞进内存；如果是直接跑数据库SQL，调整数据库的批量fetch参数（比如SQL Server的SET ROWCOUNT，HANA的LIMIT分段读取）。
• 加数据库专属Hint：针对SAP常用的数据库，加Hint引导优化器走更高效的执行计划：
  • HANA数据库：在查询开头加/*+ INDEX_COST_RATIO(100) */，让优化器优先依赖系统统计信息而非强制找索引；
  • SQL Server：在查询末尾加OPTION (RECOMPILE)，避免陈旧的执行计划拖慢速度。
• 避开业务高峰：SAP高峰时段CPU、IO资源都被业务占满，哪怕优化过的查询也跑不快，尽量在凌晨或低峰期执行。

• 用临时表分阶段处理：先把需要的主表数据（比如ORDR、OINV、RDR1）导出到数据库临时表，再在临时表上做关联——临时表数据量小，关联效率高，还不会影响SAP正式表。比如：

-- 先导出销售订单行项目到临时表
SELECT "DocEntry", "ItemCode", "PriceBefDi", "Quantity" INTO #TempRDR1 FROM RDR1 WHERE "DocDate" >= '2023-01-01'
-- 再导出发票行项目到临时表
SELECT "BaseEntry", "DocNum", "DocDate" INTO #TempOINV FROM OINV WHERE "BaseType" = '17' AND "DocDate" >= '2023-01-01'
-- 最后关联临时表和其他表
SELECT T5."CardCode", T5."CardName", T4."ItemCode", T4."ItemName",
       T1."DocNum", T1."DocDate", T3."DocNum", T3."DocDate",
       ISNULL(T2."PriceBefDi"*T2."Quantity", 0)
FROM ORDR T1
JOIN #TempRDR1 T2 ON T1."DocEntry" = T2."DocEntry"
JOIN #TempOINV T3 ON T1."DocEntry" = T3."BaseEntry"
JOIN OITM T4 ON T2."ItemCode" = T4."ItemCode"
JOIN OCRD T5 ON T1."CardCode" = T5."CardCode"

• 拆分层级关联：把多层关联拆成多个小查询，先得到销售订单和发票的关联结果，再和物料、客户表关联，每一步都控制数据量，避免一次性关联所有表导致的资源过载。

测试的时候记得先拿小数据集验证逻辑，没问题再跑全量，别把系统搞崩了！

内容的提问来源于stack exchange，提问作者RVG90