Query优化实践-Aggregates的使用

最新推荐文章于 2023-06-10 10:59:57 发布

cnz98144

最新推荐文章于 2023-06-10 10:59:57 发布

阅读量221

点赞数

文章标签：数据库

1. Aggregate被成為“窮人”的BIA，所以作用可見一斑
2. 哪么什麽時候該用Aggregate呢，或者說什麽時候是使用Aggregate才能發揮作用呢？
3. 這裡有一個標準就是 Aggregate Ratio > 10 並且 Percentage DB Time > 30%
4. 上面我用A-E標注了5列，通過【D / E】兩列可以計算出Aggregate Ratio
通過【K/(I+J+K)】三列可以計算出DB Time
5. 通過以上的計算公式，我們看到第一行的兩個值都是大大符合可以使用Aggregate獲得性能提升的數值
6. 從第二行開始，C列顯示的是獲取的Aggregate 編號，所以我們看到數據庫查詢的行數（D列）大大減少了，而E列是顯示結果，所以行數一直。3-5行我是同一天取得數據，所以行數完全一樣。
7. 對比K列大家可以看到DB的時間消耗是幾個數量級的提高
8. 從第3行開始，我對Query做了微調，雖然系統速度有所提升，但是已經接近九牛一毛的地步了，所以可以收手了。

講到做Aggregate，那么我就順便分享一下，如果去做一個Aggregate。其實做Aggregate方法很多，比如如果熟悉Cube的結構，大可直接手工抓取Characteristic。如果不是很熟悉，那么可以通過Propose From Query（這次我就是這樣建立SD的Aggregate的），當然通過Propose From BW Statistic的方法是可以獲得更佳性能的Aggregate的，因為之前沒有啟用這個Cube的分析，所以無法用這個方式。

上圖我標注了幾列是我們要重點關注的。

A列需要說明的是分別放了哪些欄位，越普遍越好，層級越高越好。純粹為某個Query做的Aggregate是不被推崇的，真正的Aggregate应该是大众情人，就是很多Query都可以从中受益。

B列会对当前Aggregate进行评级，就是目前Aggregate的优劣程度，加号越多说明它越优秀，注意，它不是一个单纯某个值就可以影响的，因为它是综合分，包括基本要求，使用程度等。

C列是Aggregate的数据量，就是目前存在Aggregate中的数量。这个多少不能说明什么问题，需要相对而言。

D列正是这个相对数，它是Cube总数量/ Aggregate总数量得出的值，理论上讲，如果不是大于10，那么就要考虑Aggregate做的是否够犀利。

QE2.GIF