《SAP FICO系统配置从入门到精通共40篇》037、FICO性能优化：索引、表分区与归档：那些年我们追过的慢查询

037、FICO性能优化索引、表分区与归档那些年我们追过的慢查询上周生产环境月结同事半夜打电话过来说F-02记账界面卡了十五分钟还没响应。远程连上去一看DB13里BSEG表的全表扫描像疯了一样。这场景太熟悉了——又是索引惹的祸。从一次真实的索引失效说起那个深夜的问题最终定位到一条自定义报表。开发同事写了段很“聪明”的代码SELECT * FROM BSEG WHERE BUKRS lv_bukrs AND (BELNR LIKE F% OR BELNR LIKE S%)。看起来没问题对吧但SAP的BSEG表在BELNR字段上压根没建单字段索引只有复合索引。更糟的是那个通配符开头的LIKE直接让优化器放弃了索引查找。 错误示范别这样写百分号在前索引直接失效 SELECT * FROM bseg WHERE belnr LIKE %INV% AND gjahr lv_year. 应该这样玩把确定条件放前面实在要模糊查询考虑全文检索 SELECT * FROM bseg WHERE gjahr lv_year AND belnr IN (SELECT belnr FROM bkpf WHERE blart RE).SAP FICO的索引不是你想的那样很多人以为数据库索引都差不多在SAP里可不是这回事。FICO核心表的设计有它的历史包袱比如BSEG那个著名的“万能表”——光标准索引就二十多个但你还是可能用不上。第一坑复合索引的顺序是命门BSEG的索引0是MANDT BUKRS BELNR GJAHR BUZEI如果你只按GJAHR查这索引就废了。这就好比你知道书的页码但非得从第一章开始翻。第二坑SAP有时比你更懂需要什么索引SE11里能看到那些带S的索引如BSEG~S是SAP预留的系统索引。但真正要关注的是事务代码DB02里的索引使用统计。我见过有个客户在FAGLFLEXA上自建了三个索引结果DB02显示命中率全是零白占了几十个G的存储。自定义索引的实战建议先用ST05跟踪看执行计划到底用了哪个索引复合索引字段顺序按筛选粒度从大到小排公司代码→会计年度→凭证号字段数别超过5个太多反而拖慢插入速度定期跑DB02的索引分析那些从不使用的索引该删就删表分区大表拆解的智慧FICO数据有个特点时间维度特别明显。去年凭证今年大概率只查询不更新这就为表分区创造了条件。我们有个客户的FAGLFLEXA表到了800G月结时F.5D跑一次两小时。后来按RYEAR做了范围分区最近两年的数据放高速存储历史数据放普通存储。效果立竿见影——月结时间砍掉三分之一。-- 这是概念示例实际用DBCOCKPIT操作ALTERTABLEFAGLFLEXAPARTITIONBYRANGE(RYEAR)(PARTITIONp_2020VALUESLESS THAN(2021),PARTITIONp_2021VALUESLESS THAN(2022),PARTITIONp_currentVALUESLESS THAN(MAXVALUE));分区要注意的细节分区键必须是主键的一部分SAP大部分表符合业务查询条件必须带上分区键否则跨分区扫描更慢定期维护分区比如每年初新建一个分区数据归档不是删除是优雅地告别很多人怕归档觉得数据“没了”心里不踏实。其实归档是把数据从生产表搬到归档表该查的时候还能通过FB03之类的事务码查出来只是稍微慢点。我们做过最成功的案例是把一家制造业10年以上的BSEG数据归档了。生产库从3T缩到800G备份时间从6小时降到1.5小时。关键步骤就几步用SARA定义归档对象FI_DOCUMENT写程序测试归档后业务报表还能不能跑特别那些自定义的先归档最老的数据观察两周没问题再继续归档后记得重组表空间不然空间不会释放有个坑得提醒归档别太激进。财务审计可能要查七年前的数据你全归档到磁带库审计来了调数据等两天财务总监能跟你急。性能优化的节奏感优化不是一次性工程得有节奏。我的习惯是每月看DB02的TOP SQL抓那些全表扫描的。用ST05跟踪半小时生产操作分析执行计划。每季检查表增长趋势预测哪些表半年后会出问题。和业务部门聊聊哪些报表他们觉得慢。每年结合年结做一次大优化。该归档的归档该分区的分区该加索引的加索引。最后说句实在话FICO性能问题八成出在自定义开发上。那些“灵活”的报表那些“方便”的增强往往就是拖慢系统的元凶。优化时带着业务思维——这个查询真的需要实时吗这数据必须全量查吗有时候改业务逻辑比加索引效果好十倍。记住最好的优化是不用优化。设计阶段多想想后面就能少熬几个夜。