DAX query plan w praktyce: jak czytać Server Timings i wyłapać najdroższe miary

Najczęstsze pułapki interpretacji (żeby nie wyciągać złych wniosków)

• Cache: kolejne uruchomienia mogą mieć niższy SE Time, bo dane są już w pamięci. Porównuj wyniki w porównywalnych warunkach.
• Równoległość: CPU nie jest „błędem” samym w sobie; liczy się wpływ na Duration oraz to, czy zasoby są współdzielone z innymi zapytaniami.
• Rows nie zawsze = „za dużo danych w modelu”: czasem to efekt chwilowej tabeli pośredniej lub grupowania, a nie samej wielkości tabeli faktów.
• SE Queries nie zawsze oznacza problem: kilka zapytań bywa normalne; alarmujący jest wzorzec: bardzo dużo zapytań przy rosnącym Duration/FE.

4. Server Timings krok po kroku: identyfikacja najdroższych miar i rozróżnienie kosztu Storage Engine vs Formula Engine

Server Timings w DAX Studio to najszybsza droga, żeby odpowiedzieć na dwa praktyczne pytania: „co dokładnie kosztuje czas?” oraz „czy problem jest w Storage Engine (SE) czy w Formula Engine (FE)?”. W tej sekcji przechodzimy przez typowy workflow analizy jednego zapytania/visuala, bez wchodzenia w szczegółowe reguły optymalizacji. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — dlatego warto mieć prostą procedurę, która porządkuje analizę.

Krok 1: Włącz Server Timings i uruchom pojedyncze zapytanie

• Po podłączeniu do modelu w DAX Studio włącz Server Timings (panel/zakładka).
• Uruchamiaj analizę na pojedynczym zapytaniu (jednym visualu albo jednym DAX Query), aby nie mieszać kosztów wielu requestów.
• W miarę możliwości wyłącz cache (jeśli chcesz zobaczyć „cold” performance) albo testuj konsekwentnie w tej samej konfiguracji, żeby porównania miały sens.

Krok 2: Najpierw patrz na podział FE vs SE (zanim zejdziesz niżej)

Wynik Server Timings w pierwszej kolejności czytaj jako budżet czasu rozbity na dwa silniki:

• Storage Engine (SE) – wykonuje skany, agregacje, joiny i filtracje na skompresowanych kolumnach (VertiPaq) lub deleguje do źródła w DirectQuery.
• Formula Engine (FE) – interpretuje logikę DAX, buduje kontekst, wykonuje iteracje, generuje i koordynuje zapytania do SE, „skleja” wyniki.

Krok 3: Przejdź do listy „SE Queries” i zidentyfikuj kosztowne odpyty

W Server Timings znajdziesz część pokazującą zapytania do Storage Engine (często jako lista z czasami i liczbą wierszy). To Twoja „mapa” tego, ile razy FE musiał poprosić SE o dane oraz jak ciężkie były te prośby.

• Policz liczbę SE Queries: duża liczba krótkich zapytań często oznacza, że FE iteruje i dla każdej iteracji odpytuje SE (narzut koordynacji i powtarzalności).
• Wyszukaj najdłuższe pojedyncze SE query: pojedynczy „długi” strzał do SE często wskazuje na szeroki skan lub kosztowną filtrację/join.
• Zwróć uwagę na Rows: duża liczba zwróconych wierszy w połączeniu z wysokim FE Time bywa sygnałem, że FE musi dalej przetwarzać obszerny wynik zamiast dostać gotową agregację.

Krok 4: Powiąż koszt z miarą/visualem – podejście „izoluj i porównaj”

Server Timings nie zawsze „podaje nazwę miary na tacy”, bo finalne zapytanie visuala może zawierać kilka miar, filtry i logikę generowaną przez klienta. Najprostsza metoda identyfikacji najdroższej miary to porównania A/B:

• Uruchom zapytanie z jedną miarą (np. usuń pozostałe miary z visuala albo wykonaj osobne zapytanie).
• Dodawaj miary pojedynczo i obserwuj przyrosty w: SE Time, FE Time, liczbie SE Queries oraz Rows.
• Jeśli jedna miara powoduje skok FE Time bez dużego wzrostu SE Time, podejrzewaj koszt w logice DAX (iteracje/kontekst).
• Jeśli jedna miara powoduje skok SE Time lub pojawienie się jednego dominującego SE query, podejrzewaj koszt w skanie/agregacji/filtrach.

Krok 5: Rozpoznaj podstawowe „wzorce” problemów po samych Timingach

Nie wchodząc jeszcze w szczegóły planu zapytania, już same Timingi pozwalają rozróżnić kilka typowych sytuacji:

• Wiele SE Queries + wysokie FE Time – często wskazuje na iteracyjne wyrażenia, w których FE „kręci pętlę” i wielokrotnie odpytuje SE.
• Mało SE Queries, ale jedno bardzo długie – typowo ciężki skan albo filtracja po kolumnie o wysokiej kardynalności; SE jest wąskim gardłem.
• SE Time mały, FE Time duży – SE szybko zwraca dane, ale FE spędza czas na budowie tabel pośrednich, logice warunkowej, łączeniu wyników i obliczeniach poza SE.
• Duże Rows z SE – sygnał, że do FE trafia zbyt „surowy” zestaw danych (zamiast bardziej zredukowanej agregacji).

Krok 6: Minimalny przykład testu miary (tylko jako narzędzie diagnostyczne)

Jeżeli chcesz szybko przetestować samą miarę w kontrolowanym kontekście, często wystarcza proste zapytanie zwracające jedną wartość (to nie jest jeszcze optymalizacja – tylko izolacja kosztu):

EVALUATE
ROW(
    "Test", [TwojaMiara]
)

Potem porównujesz Server Timings między różnymi miarami lub wariantami tej samej miary, patrząc głównie na to, czy koszt „siedzi” w FE czy w SE.

Krok 7: Co zapisać jako wnioski z Server Timings

Po jednym przebiegu analizy warto spisać 3–5 faktów, które poprowadzą dalsze kroki:

• Dominujący silnik: FE czy SE?
• Liczba SE Queries: czy jest ich podejrzanie dużo?
• Najdroższe SE query: jedno czy kilka?
• Rows: czy wynik z SE wygląda na zbyt obszerny w stosunku do celu miary?
• Miary „winne” przyrostu: które miary po dodaniu do visuala powodują największy skok czasu?

Taki zestaw obserwacji zwykle wystarcza, żeby zdecydować, czy dalszą analizę prowadzić „od strony SE” (co i jak jest skanowane) czy „od strony FE” (jaka logika DAX generuje iteracje i dodatkową pracę).

5. Query Plan krok po kroku: jak analizować plan, wykrywać iteratory/spool i łączyć wnioski z miarami

Server Timings mówi ile kosztowało zapytanie (FE/SE, liczba zapytań do SE, czas). Query Plan pokazuje natomiast dlaczego — jak silnik rozbił miarę i jakie operatory wykonał po drodze. W praktyce plan jest najszybszą drogą do znalezienia „wąskich gardeł” w logice DAX: iteratorów, przejść kontekstów, materializacji pośrednich wyników (spool) oraz miejsc, w których Formula Engine (FE) musi wykonać dużą pracę w pamięci.

5.1. Co właściwie oglądasz w Query Plan?

W DAX Studio plan zapytania prezentuje drzewo operatorów. Najważniejsze jest, by czytać je od góry do dołu jako przepływ: operator nadrzędny „karmi się” wynikami operatorów podrzędnych. Nie musisz znać wszystkich nazw — na start wystarczy rozróżnić kilka klas elementów:

• Operatory skanu/agregacji w SE — ślady pracy Storage Engine, zwykle „tanie” jeśli trafiają w dobrze skompresowane kolumny i proste grupowania.
• Operatory iteracyjne w FE — sygnalizują pętle po wierszach/tabelach, często źródło kosztu CPU oraz długiego FE Time.
• Materializacja/buforowanie (spool/cache) — pośrednie wyniki są zapisywane i ponownie używane; bywa pomocne, ale często ujawnia, że silnik musi „przekalkulować” coś w pamięci.
• Przepływ filtrów i kontekstów — elementy planu, które wskazują na aplikowanie filtrów, przejścia kontekstu i łączenie zestawów.

5.2. Minimalny workflow analizy planu (checklista)

• Krok 1: Zlokalizuj gałąź odpowiadającą miarze — w planie szukaj fragmentów opisujących obliczenia agregacji dla Twojego wyniku (często będzie to najwyższy operator agregujący lub node, pod którym „zbiegają się” filtry i obliczenia).
• Krok 2: Wypatrz iteratory — pierwsze podejrzenie przy wolnych miarach to operatory sugerujące iterację po wielu wierszach (np. wzorce odpowiadające SUMX/AVERAGEX/iteratorom po tabelach). Jeśli w planie widzisz wiele zagnieżdżonych poziomów iteracji, spodziewaj się wzrostu kosztu wykładniczego przy większej kardynalności.
• Krok 3: Sprawdź, czy pojawia się spool/materializacja — plan z „spool” oznacza, że silnik tworzy tymczasową strukturę (np. aby ponownie użyć wyniku lub aby obsłużyć złożone filtrowanie/łączenie). Jeden spool nie jest z automatu zły, ale to czerwone światło, że FE wykonuje „pracę organizacyjną”.
• Krok 4: Oceń, gdzie odbywa się ciężar — jeśli gałąź planu wygląda na „FE-heavy” (dużo iteratorów, spool, złożone operatory), zestaw to z obserwacją z Server Timings: czy faktycznie FE dominuje czas? Gdy SE dominuje, plan częściej pokaże proste skany/agregacje, ale na dużych zbiorach.
• Krok 5: Zwiąż plan z konkretnym fragmentem DAX — dopiero teraz wróć do miary i zidentyfikuj konstrukcję, która najpewniej mapuje się na podejrzany operator (iterator, zagnieżdżony FILTER, złożony warunek, dynamiczna tabela, itp.).

5.3. Iteratory: jak je rozpoznać i co z nich wynika

W planie iteratory objawiają się gałęziami, w których wynik jest liczony „per wiersz” lub „per grupę”, a następnie agregowany. Z punktu widzenia praktycznej diagnostyki interesują Cię dwa sygnały:

• Głębokość zagnieżdżenia — iterator w iteratorze to typowy generator kosztu CPU, zwłaszcza gdy wewnętrzna pętla skanuje duże tabele.
• Wielkość przestrzeni iteracji — jeżeli iterator przechodzi po tabeli o wysokiej kardynalności (np. wiele unikalnych wartości), FE wykona dużo pracy, nawet jeśli pojedyncza operacja jest prosta.

Nie chodzi o to, by unikać iteratorów zawsze — tylko by wiedzieć, kiedy są głównym kosztem i czy da się „zepchnąć” obliczenie do bardziej zestawowych operacji.

5.4. Spool/materializacja: co sygnalizuje i kiedy boli

Operator typu spool (lub analogiczny element buforowania) sugeruje, że silnik tworzy pośredni wynik, aby:

• ponownie go wykorzystać w kolejnych krokach (cache),
• obsłużyć złożone połączenia/filtry,
• zmaterializować tabelę, której nie da się wygodnie przepuścić strumieniowo.

W praktyce spool jest istotny, gdy dotyczy dużych zbiorów lub powstaje wiele razy w tej samej ścieżce obliczeń. Wtedy plan często pokazuje, że FE nie może „przekazać dalej” prostych agregacji z SE, tylko musi budować struktury pośrednie w pamięci.

5.5. Łączenie wniosków z Query Plan z miarami (mapowanie przyczyn)

Największa wartość Query Plan pojawia się, gdy umiesz przetłumaczyć podejrzany operator na potencjalny problem w DAX. Poniższa tabela to szybka legenda diagnostyczna (bez wchodzenia w techniki optymalizacji):

5.6. Krótki przykład: jak plan naprowadza na fragment do poprawy

Poniżej celowo uproszczony przykład. Jeśli miara opiera się na iteracji po tabeli faktów:

Wynik :=
SUMX(
  'Fakt',
  'Fakt'[Kwota] * 'Fakt'[Wspolczynnik]
)

a w Query Plan widzisz podejrzanie „gęstą” gałąź z iteracją i ewentualnym buforowaniem, to sygnał diagnostyczny brzmi: koszt wynika z pracy per wiersz (a nie z samej agregacji). Kolejnym krokiem jest sprawdzenie, czy ta iteracja jest konieczna oraz jak duża jest przestrzeń iteracji w aktualnym kontekście zapytania.

5.7. Praktyczne zasady czytania planu (żeby się nie zgubić)

• Najpierw identyfikuj „kształt” planu: czy dominuje praca FE (iteracje/spool), czy plan jest głównie skanami/agregacjami.
• Nie poluj na pojedyncze słowo — jeden operator rzadko wyjaśnia wszystko; ważny jest kontekst gałęzi i to, co dzieje się „pod spodem”.
• Łącz plan z kontekstem zapytania — ta sama miara może mieć inny plan w zależności od wizualizacji/filtrów; plan czytaj zawsze dla konkretnego scenariusza.
• Używaj planu jako mapy do miary — celem nie jest „zrozumieć każdy node”, tylko znaleźć fragment logiki odpowiadający najcięższej ścieżce wykonania.

6. Typowe przyczyny wolnych miar

Wolna miara rzadko jest „z natury” wolna — zwykle staje się kosztowna w konkretnym kontekście zapytania: przy danym ziarnie wizualizacji, liczbie filtrów, relacjach w modelu i kształcie danych. Poniżej są najczęstsze źródła problemów, które warto rozpoznawać, zanim przejdziesz do szczegółowej analizy w Server Timings i Query Plan.

6.1. Kontekst filtra: drobne różnice, duże koszty

Ten sam DAX potrafi działać szybko na poziomie miesiąca, a dramatycznie wolno na poziomie pojedynczego produktu lub klienta. Wynika to z tego, że miara jest wykonywana wiele razy (dla wielu punktów siatki), a dodatkowo filtr może:

• rozszerzać zakres danych (np. nieoczekiwanie usuwać filtr daty),
• powodować kosztowne przejścia relacji (szczególnie przy filtrach z wielu tabel),
• wymuszać pracę po stronie Formula Engine, gdy logika nie daje się łatwo „złożyć” do Storage Engine.

Typowy sygnał: miara ma akceptowalny czas całkowity na prostym wykresie, ale skaluje się źle na tabeli/macierzy z wieloma wymiarami.

6.2. Iteratory (funkcje z „X”): SUMX, AVERAGEX, FILTERX jako mnożnik pracy

Iteratory są potrzebne, gdy liczysz „po wierszach” (lub po grupach), ale ich koszt rośnie wraz z liczbą iterowanych elementów. Problemem nie jest sam SUMX, tylko sytuacja, gdy wewnątrz iteracji wykonujesz ciężkie wyrażenia (np. dodatkowe CALCULATE, skomplikowane warunki, odwołania do wielu tabel).

• Wysokie cardinality w tabeli iterowanej = dużo kroków pętli.
• Iteracja po tabeli faktów bywa znacznie droższa niż po małej tabeli wymiaru lub agregacji.
• Zagnieżdżone iteratory potrafią eksplodować złożoność (pętla w pętli).

W praktyce warto traktować iteratory jako narzędzie precyzyjne: używać, gdy trzeba, ale świadomie ograniczać rozmiar tabeli wejściowej (np. przez agregację, filtr, wybór właściwej kolumny).

6.3. Złożone CALCULATE: przełączanie kontekstu i rozbudowane filtry

CALCULATE jest jednym z najpotężniejszych elementów DAX, ale potrafi generować koszt, gdy:

• ma wiele argumentów filtrujących (szczególnie opartych o wyrażenia, a nie proste warunki kolumn),
• używa konstrukcji typu FILTER(…) na dużych tabelach,
• miesza w jednym miejscu modyfikacje relacji (np. aktywacja relacji, zmiana kierunku filtrowania) i warunki biznesowe.

Wysoki koszt często wynika nie z liczby linii kodu, tylko z tego, że filtr nie jest „prostym” filtrem kolumny, przez co silnik musi wykonać dodatkową pracę, zanim policzy agregację.

6.4. Relacje i propagacja filtrów: nieintuicyjne przejścia między tabelami

Relacje decydują, jak filtry przepływają przez model. Wolne miary często mają źródło w tym, że zapytanie musi przejść przez:

• łańcuch relacji (kilka skoków między tabelami),
• relacje oparte o kolumny o wysokiej kardynalności,
• dwukierunkowe filtrowanie (używane bez potrzeby),
• relacje nieaktywne aktywowane doraźnie w miarach.

Efekt uboczny: miara działa szybko przy filtrach z jednej tabeli, ale zwalnia po dodaniu filtra z innej części modelu (szczególnie przy wielu wymiarach naraz).

6.5. Cardinality i „kształt” danych: gdy wolumen nie jest jedynym problemem

Wydajność zależy nie tylko od liczby wierszy, ale też od liczby unikalnych wartości w kolumnach używanych do grupowania, filtrowania i relacji. Typowe pułapki:

• klucze/identyfikatory i znaczniki czasu o bardzo wysokiej kardynalności wchodzą w relacje lub w oś wizualizacji,
• kolumny tekstowe używane jako filtry zamiast zastąpienia ich kluczami/liczbami,
• brak tabel agregujących (wszystko liczone z poziomu najdrobniejszego faktu).

Wysoka kardynalność często objawia się tym, że miara jest „ok” dla kilku wartości, ale gwałtownie degraduje się, gdy użytkownik wybiera bardziej szczegółowy poziom.

6.6. Nieoptymalne wzorce DAX: częste „antywzorce”

Poniższa tabela zbiera typowe sytuacje, które podnoszą koszt obliczeń i utrudniają silnikowi optymalizację:

6.7. Krótki przykład „co boli” (tylko sygnał ostrzegawczy)

Poniższy fragment nie jest po to, aby pokazać kompletną optymalizację, tylko aby unaocznić typowy mechanizm: koszt rośnie, gdy filtrujemy dużą tabelę faktów w locie i robimy to w kontekście wielu punktów wizualizacji.

-- Potencjalnie kosztowne: FILTER na tabeli faktów wewnątrz miary
Wynik =
CALCULATE(
    SUM(Fact[Amount]),
    FILTER(Fact, Fact[Status] = "OK")
)

Jeśli taka miara jest użyta w macierzy z wieloma wymiarami, łatwo „wzmocnić” koszt przez liczbę wywołań. Dlatego w diagnostyce zawsze patrz na miarę razem z tym, w jakim kontekście jest wykonywana.

6.8. Lista kontrolna: co sprawdzić, gdy miara jest wolna

• Czy miara nie skaluje się źle wraz ze wzrostem liczby komórek wizualizacji (kontekst zapytania)?
• Czy używasz iteratorów nad dużą tabelą lub zagnieżdżonych iteratorów?
• Czy CALCULATE nie zawiera kosztownych filtrów tabelarycznych (np. FILTER na fakcie)?
• Czy relacje i kierunki filtrowania nie powodują niepotrzebnych przejść lub „rozlania” filtrów?
• Czy kolumny w relacjach/grupowaniach nie mają bardzo wysokiej kardynalności?
• Czy nie stosujesz wzorców, które utrudniają optymalizację (rozbudowane warunki w iteracji, resetowanie filtrów na szerokim zakresie)?

7. Przykłady krótkich fragmentów DAX: „wolny vs szybszy” oraz techniki ograniczania iteracji i redukcji pracy FE

Poniższe pary pokazują typowe sytuacje, w których miara staje się droga, bo Formula Engine musi wykonywać iteracje po wielu wierszach, budować duże tabele pośrednie albo wielokrotnie wywoływać ten sam fragment logiki w zmiennym kontekście. Celem nie jest „magiczne” przyspieszenie każdej miary, tylko zmniejszenie pracy FE i oddanie jak największej części obliczeń do Storage Engine lub do prostszych agregacji.

• Iteratory (SUMX/AVERAGEX) vs agregacje kolumnowe: wolniej bywa wtedy, gdy iterujesz po dużej tabeli faktów tylko po to, by policzyć prostą sumę/średnią. Szybsze podejście to użycie funkcji agregujących, jeśli wynik da się uzyskać bez logiki „wiersz po wierszu”.
• Filtruj przed iteracją: wolny wariant często iteruje po całej tabeli i dopiero wewnątrz sprawdza warunek. Szybszy wariant ogranicza zbiór na wejściu (mniejsza liczba wierszy do przejścia), np. przez zawężenie kontekstu filtra przed obliczeniem.
• Unikaj liczenia tego samego wiele razy: miary „wolne” często powtarzają identyczne wyrażenie w kilku gałęziach logiki lub w wielu miejscach (np. w warunkach). Szybsze podejście to zapisanie wyniku w zmiennej i użycie go wielokrotnie, dzięki czemu FE nie musi powtarzać kosztownej części.
• IF w iteracji vs warunek poza iteracją: gdy warunek jest stały dla bieżącego kontekstu (a nie dla każdego wiersza), jego sprawdzanie w środku iteratora jest zbędne. Lepszy wzorzec to ocenić warunek raz i dopiero potem wykonać jedną z dwóch prostszych ścieżek.
• FILTER na dużych tabelach vs prostsze predykaty: koszt rośnie, gdy budujesz duże tabele pośrednie wyrażeniami filtrującymi, których nie da się łatwo „zepchnąć” do SE. Szybsza wersja zwykle opiera się o prostsze ograniczenia kontekstu (np. przez bezpośrednie filtry na kolumnach lub wykorzystanie istniejących relacji), zamiast składać rozbudowany FILTER.
• Top N i sortowanie: wolno robi się, gdy miara wymusza sortowanie i rankingowanie dużego zbioru w każdej komórce wizualizacji. Szybciej jest ograniczyć zakres do niezbędnego minimum (mniej kandydatów do rankingu) i unikać niepotrzebnych operacji porządkujących w kontekście, gdzie nie są używane.
• Miary zależne (measure-on-measure) i „łańcuszki”: wielowarstwowe zależności mogą powodować, że jedna komórka raportu uruchamia wiele zapytań cząstkowych. Szybszy wariant zwykle upraszcza logikę do krótszego łańcucha, łączy kroki lub eliminuje pośrednie miary tam, gdzie prowadzą do nadmiarowych obliczeń.
• Praca na faktach vs praca na wymiarach: wolny wzorzec iteruje po tabeli faktów, mimo że logika dotyczy de facto unikalnych wartości wymiaru. Szybsze podejście przenosi iterację na mniejszy zbiór (np. listę kategorii/klientów), a dopiero potem agreguje fakty w kontekście tej listy.
• ALL/REMOVEFILTERS używane „na ślepo”: zdejmowanie filtrów zbyt szeroko potrafi rozsadzić przestrzeń obliczeń i zwiększyć liczbę skanowanych wierszy. Szybszy wzorzec usuwa filtry tylko tam, gdzie to konieczne (konkretna kolumna/tabela), by nie powiększać kontekstu bardziej niż potrzeba.
• Precyzyjne granice kontekstu w CALCULATE: wolno bywa, gdy w CALCULATE mieszają się niejasne filtry i złożone warunki, które generują ciężkie tabele pośrednie. Szybszy wariant trzyma filtry proste, możliwie selektywne i unika tworzenia dużych zbiorów „pomocniczych” w samym wyrażeniu.

Jeśli masz wrażenie, że miara „robi niewiele”, a mimo to jest droga, najczęściej oznacza to, że FE musi wykonać zbyt dużo pracy per komórka: za dużo iteracji, za duże tabele pośrednie albo za wiele powtórzeń tego samego wyrażenia w różnych kontekstach. Dobrym nawykiem jest zadawanie sobie trzech pytań: czy da się zredukować liczbę wierszy na wejściu, czy da się uniknąć iteratora, oraz czy da się policzyć część rzeczy raz (zmienne) zamiast wielokrotnie.

8. Lista szybkich optymalizacji do przetestowania: checklist + walidacja efektów w DAX Studio

Gdy miara „działa”, ale raport zaczyna się dławić, najszybciej zyskasz czas, wykonując serię krótkich, bezpiecznych testów. Poniższa lista to checklist rzeczy, które zwykle dają zauważalny efekt bez przebudowy całego modelu. Kluczem jest, aby każdą zmianę zweryfikować pomiarem w DAX Studio, zamiast polegać na wrażeniach z interfejsu raportu.

Checklist: szybkie optymalizacje, które warto sprawdzić

• Ogranicz liczbę wywołań miar w jednej definicji: mniej zagnieżdżeń i mniej powtórzeń tego samego wyrażenia często zmniejsza koszt obliczeń.
• Użyj zmiennych do przechowywania wyników pośrednich: szczególnie gdy to samo obliczenie jest wykorzystywane wielokrotnie w różnych gałęziach logiki.
• Minimalizuj pracę w wierszu: jeśli miara „przechodzi” po wielu rekordach, spróbuj przesunąć logikę w stronę agregacji, a nie iteracji po elementach.
• Zmniejsz liczbę filtrów i warunków wprowadzanych dynamicznie: każda dodatkowa manipulacja kontekstem może zwiększać koszt, zwłaszcza gdy filtr dotyka dużych tabel.
• Uprość warunki logiczne: zbyt rozbudowane rozgałęzienia potrafią wielokrotnie wymuszać obliczenia pomocnicze; uproszczenie logiki bywa szybką wygraną.
• Sprawdź, czy filtrujesz „w dobrą stronę”: kierunek filtracji (z tabel wymiarów do faktów) zwykle jest tańszy niż filtrowanie faktów i „ciągnięcie” kontekstu w górę.
• Ogranicz zakres kontekstu: jeżeli wizual pokazuje zbyt drobne poziomy szczegółowości, rozważ zawężenie (mniej kategorii, krótszy zakres dat), bo miara jest liczona dla każdej komórki siatki.
• Eliminuj zbędne przejścia między tabelami: zbyt długie ścieżki relacji i niejednoznaczne połączenia często windują koszt filtrowania i propagacji kontekstu.
• Zredukuj kardynalność w modelu tam, gdzie to możliwe: kolumny o wysokiej unikalności w filtrach i grupowaniach potrafią istotnie pogorszyć wydajność.
• Unikaj pracy na szerokich, „ciężkich” kolumnach w filtrach: wybieraj klucze/liczby zamiast tekstów, gdy to możliwe, bo to zwykle przekłada się na tańsze filtrowanie.
• Zweryfikuj, czy problem nie leży w wizualu: czasem miara jest w porządku, a koszt generuje liczba punktów danych, tooltipy, sortowania lub wiele warstw interakcji.
• Sprawdź, czy da się przenieść część logiki do modelu: prosta kolumna kalkulowana lub przygotowanie danych w Power Query potrafi odjąć pracy w czasie zapytania (kosztem odświeżania).
• Rozważ uproszczenie modelu: mniej kolumn, mniej nieużywanych tabel, mniej relacji — to często „małe sprzątanie”, które poprawia wszystko naraz.

Walidacja w DAX Studio: jak mierzyć efekt, żeby nie oszukały Cię przypadki

• Testuj porównawczo: zmierz „przed” i „po” dla tego samego scenariusza (te same filtry, ten sam kontekst, ten sam zakres danych).
• Powtarzaj pomiar: wykonaj kilka uruchomień i porównuj trend, nie pojedynczy wynik. Pojedynczy strzał może być zaburzony przez cache, inne procesy i losowe wahania.
• Oddziel wpływ cache od realnej poprawy: patrz, czy zmiana poprawia zarówno pierwsze wykonanie (zimniej), jak i kolejne (cieplej). Jeżeli zysk widać tylko „po rozgrzaniu”, optymalizacja może być pozorna.
• Porównuj metryki, nie tylko czas: obserwuj równolegle czas całkowity, CPU oraz liczbę/ciężar zapytań do Storage Engine. Zmiana może skrócić Duration, ale podnieść CPU albo odwrotnie.
• Zwracaj uwagę na rozkład kosztu: jeśli po zmianie spada koszt po stronie Storage Engine, a rośnie po stronie Formula Engine (lub odwrotnie), to sygnał, że optymalizacja przesunęła pracę zamiast ją ograniczyć.
• Kontroluj kontekst zapytania: porównuj wyniki dla tego samego wizualu/układu, bo inny poziom szczegółu może całkowicie zmienić profil kosztów.
• Notuj wnioski: zapisuj, co zmieniłeś i jaki był efekt w metrykach; po kilku próbach łatwo wrócić do najlepszej wersji i uniknąć „optymalizacji w ciemno”.

Najważniejsza zasada tej checklisty: optymalizuj iteracyjnie i mierz. Nawet drobna korekta potrafi dać wyraźny zysk, ale tylko DAX Studio pozwoli Ci jednoznacznie potwierdzić, czy faktycznie odciążyłeś silnik, a nie tylko zmieniłeś warunki testu.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

SPSS w marketingu: jak segmentacja klientów potrafi wprowadzić w błąd i co zrobić, żeby działała 19 maja 2026

5 błędów w SPSS, przez które wyniki testów t, ANOVA i chi-kwadrat wychodzą „dziwnie” 17 maja 2026