Ponieważ nie kontrolujesz wybranego algorytmu, nie ma możliwości bezpośredniego poznania. Jednak bez indeksów SELECT powinien mieć wartość O(n) (skanowanie tabeli musi sprawdzać każdy rekord, co oznacza, że skaluje się z rozmiarem tabeli).
W przypadku indeksu SELECT jest prawdopodobnie O(log(n)) (chociaż zależy to od algorytmu użytego do indeksowania i właściwości samych danych, jeśli jest to prawdą dla dowolnej rzeczywistej tabeli). Aby określić wyniki dla dowolnej tabeli lub zapytania, dla pewności musisz skorzystać z profilowania danych ze świata rzeczywistego.
INSERT bez indeksów powinien być bardzo szybki (blisko O(1)), podczas gdy UPDATE musi najpierw znaleźć rekordy, a więc będzie wolniejszy (nieco) niż SELECT, który cię tam zaprowadzi.
INSERT z indeksami prawdopodobnie ponownie znajdzie się w polu O(log(n^2)), gdy drzewo indeksów wymaga ponownego zrównoważenia, bliżej O(log(n)) w przeciwnym razie. To samo spowolnienie wystąpi z UPDATE, jeśli wpłynie na indeksowane wiersze, oprócz kosztów SELECT.
Wszystkie zakłady są anulowane, gdy mówisz o JOIN w miksie:będziesz musiał sprofilować i użyć narzędzi do szacowania zapytań bazy danych, aby zapoznać się z tym tematem. Pamiętaj również, że jeśli to zapytanie ma kluczowe znaczenie dla wydajności, powinieneś ponownie profil od czasu do czasu, ponieważ algorytmy używane przez optymalizator zapytań będą się zmieniać wraz ze zmianą obciążenia danych.
Kolejna rzecz, o której należy pamiętać… big-O nie mówi o kosztach stałych dla każdej transakcji. W przypadku mniejszych stołów są one prawdopodobnie wyższe niż rzeczywiste koszty pracy. Na przykład:koszty konfiguracji, likwidacji i komunikacji zapytania międzysieciowego dla pojedynczego wiersza z pewnością będą większe niż koszty wyszukiwania zindeksowanego rekordu w małej tabeli.
Z tego powodu stwierdziłem, że możliwość połączenia grupy powiązanych zapytań w jedną partię może mieć znacznie większy wpływ na wydajność niż jakakolwiek optymalizacja, którą przeprowadziłem w właściwej bazie danych.
