- 颗粒度尽量大：尽量不要在Cube里放太明细的数据（即维度字段越小越好），这种需求首先考虑R3用ABAP解决，如果非要在BW，可以考虑在DSO出明细报表，在Cube出汇总报表，通过RRI接口调用明细报表。
- 拆分多个：当Cube的数据量很大时，可以拆分成多个Cube,再用MultiProvider拼起来，这样query会在N个Cube中并行，提高效率。这就是所谓的逻辑分区。常见的分区方式有按年月，按国家，按BU，按类型等。
- 压缩：给Cube做Compression。Compression 本质上是去掉Data Dimension，这样fact table就被压缩了，但是request id也消失了，将无法通过request id去管理数据（慎用，最好是半年甚至一年以上的数据）。
- 索引：数据库的索引可以加快查询速度
- 分区：对于很大的Cube，可以做partition,这是物理分区，只支持按时间分区。
- 聚集：使用Aggregation可以提高性能。但是Aggregation本身是cube的一个子集，提高性能的同时也加大了数据冗余，所以不要用太多。
- Staitics：定期刷新DB Statistics 可以提高reporting的效率。
- 使用MP：维度设计上，避免很多数据量很大char.放在一个维度上（多对多的不要放在一个维度里），因为这样会让维度表变得很大。通常，尽可能拆分成更多的维度（不过维度太多会导致 fact table巨大，所以要做好平衡），然后在multiprovider 层面，把相关（指业务意义上的相关）的char都放一个维度里，然后做好Mapping，这样即可以让用户更容易理解MultiProvider，下层CUBE维度的从技术角度拆分与组合（按1:1或1:N的放在一起的原则）提高了性能，两全其美。
- Line item Dimension：对于material等很大的主数据，使用Line item Dimension（即将M：N多对多的字段，让他们一个人一个维度，这样自然就成了行项目维度了，提高性能）.
- BIA:使用BIA是比Aggregation更有效的方法，就是要花不少钱
来源:https://www.cnblogs.com/jiangzhengjun/p/4297831.html