Czyli jakbysmy mieli zapytanie Select PEEnsja from Tabela where nazwisko = "Pawelec" to silnik bazodanowy leci od poczatku tabeli i dopiero gdy natrafi na te nazwisko zwaraca wynik ( i przechodzi tez po calej tabeli nawet jak ten rekord jest gdzies na poczatku),a przy uzyciu indeksu, indeks od razu sie odwoluje do tego rowid? Dobrze rozumiem? :)
Silnik czyta całą tabelę nawet jak pierwszy rekord spełnia warunek nazwisko = "Pawelec", ponieważ nie ma pewności, że takich rekordów jest kilka, np. ostatni rekord. I tu jest przewaga indeksu, bo jest posortowany - i wiadomo, że ja kolejna wartość się różni to więcej taka wartość jak Pawelec nie wystąpi. Gdy indeks dodatkowo jest unikalny to gdy natrafiasz na pierwszą pozycję to kończysz czytanie, bo wiesz, że jest tylko jeden taki rekord. Gdy indeks jest nieunikalny to czytasz dopóki warunek jest prawdziwy. Czytanie indeksu skutkuje tak naprawdę tworzeniem zbioru ROWID-ó do odczytu potem z tabeli. Nie jest tylko powiedziane, że baza ma ROWID to idzie do tabeli(BY ROWID). Równie dobrze najpierw może zebrać wszystkich ROWID-y a potem na raz odczytać z tabeli te rekordy(BY ROWID BATCHED): www.ktexperts.com/difference-between-rowid-and-rowid-batched-in-oracle/
Bez indeksu zawsze jest czytana cała tabela(wyjątkiem jest tabela partycjonowana, kiedy mamy opcję czytać partycję tabeli). W sytuacji warunku id>50 baza danych może wykorzystać ścieżkę index range scan - pod warunkiem, że będzie istniał indeks. Oczywiście kluczowa będzie selektywność warunku, tzn. informacja o tym jak duży % rekordów wybieramy z tabeli. Jeśli książka ma 500 stron a Ty napiszesz: wybierz strony > 50 to baza raczej przeczyta całą książkę(tabelę). Jeśli warunek to strony większe niż 498 to baza raczej wykorzysta indeks, bo wybierasz 2/500 rekordów :)
Niedawno zacząłem się uczyć o bazach danych i nie rozumiem po co są te indexy w taki sposób jak ty tłumaczysz. Jeśli w tabeli tworzymy klucz główny to jednocześnie tabela w pamięci staje się posortowana i klucz działa jak wewnętrzny index tabeli(tzw Clustered index). W takim wypadku w tym przykładzie co podałeś na początku jeśli jest klucz główny baza danych z tego co rozumiem nie musi przeszukiwać całej tabeli aby znaleźć tego pracownika.
Ja mówiłem w moim nagraniu o standardowym i typowym dla wszystkich DBMS przykładzie czytania tabeli(nieposortowana struktura, tzw. heap organized table) za pomocą indeksu(nonclustered index), czyli dodatkowej posortowanej struktury, zupełnie oddzielnego obiektu. Ty w swoim komentarzu założyłeś błędnie, że mówiłem o clustered index(indeks jest de facto posortowaną tabelą). Wtedy rzeczywiście dodatkowy indeks niemiałby sensu, bo po co sortować coś posortowanego :) Problemem być może jest kwestia nazewnictwa indeksów, która moim zdaniem w Sql Server(bo zapewne tego RDBMS się uczysz) jest mega słaba: clustered index to nic innego jak tabela, która działa jak indeks. Czyli masz 1 obiekt: tabelę z posortowanymi rekordami po PK. W Oracle jest to nazwane dużo lepiej(index organized table). Nazwa sugeruje, że chodzi o tabelę, która przechowuje dane jak indeks. Z mojego doświadczenia wynika, że w 99% przypadków do optymalizacji używa się zwykłych indeksów(nonclustered), ponieważ w przypadku operacji DML na tabeli przebudować trzeba mały nonclustered index(czyli ten dodatkowy posortowany obiekt, który wskazuje na rekordy tabeli). Tabela ma dużo większy rozmiar(więcej kolumn), ale ponieważ nie jest posortowana to nie trzeba nic robić. Rebuild clustered index/index organized tabel trwa duuużo dłużej.
@@nieinformatyk dzięki za odpowiedź tylko założyłem tak bo z 1 normalizacji wynika że każda tabela musi posiadać klucz podstawowy i właśnie tego nie rozumiem bo w takim wypadku zawsze tabela ma ten clustered index i jest posortowana. Jak to wygląda w przypadku Oracle?
@@aaaa-rj6uh "1 normalizacji wynika że każda tabela musi posiadać klucz podstawowy" - to prawda, ale nie wynika z tego, że tworząc PK(klucz główny) zostanie stworzony równocześnie clustered indeks. W Oracle przy tworzeniu PK automatycznie tworzony jest indeks (nonclustered - choć w nomenklaturze oraclowej nie ma czegoś takiego jak nonclustered index. Indeks to po prostu indeks). W Sql Server z tego co widzę jest na odwrót, bo domyślnie przy PK baza tworzy clustered index: learn.microsoft.com/en-us/sql/relational-databases/tables/create-primary-keys?view=sql-server-ver16 Ma to swoje zalety: pisząc selecta na tabeli nie trzeba sięgać do indeksu, a potem tabeli(table access by ROWID), ale jak mówiłem sprawia to problemy z DML. th-cam.com/video/Pz9vFdnSsKk/w-d-xo.html Co baza to rozwiązanie :)
Jedyna uwaga szkoda że nie pokazałeś na końcu na jakimś dużym zbiorze danych gdzie wyszukiwanie trwałoby np 2 sekundy lub parę ma z indeksem lub jakieś zapytanie z join które pokazałoby optymalizację
To już można samemu zrobić w ramach pracy domowej :) Zasilić dane milionem rekordów, np. używając CONNECT_BY a potem wykonać 2 SELECT-y(z indeksem i bez).
![[Live] : ONE 169 วันนี้!! "อนาโตลี vs อูมาร์"](http://i.ytimg.com/vi/IK3YZVWuFJg/mqdefault.jpg)
Świetnie tłumaczysz dzięki :) Chętnie zobaczyłabym odcinek o rodzajach indeksów.
Ok - dzięki za propozycję nagrania :) Dodałem do listy tematów.
Właśnie nagrałem materiał o który prosiłaś. Daj znać czy Ci się podoba🙂 th-cam.com/video/MEl3uBPTjJk/w-d-xo.html
Mało jest materiałów, które muszę zostawić bo zap&*^pi..pi w pracy i wracam do nich wieczorem bo są za dobre by zapomnieć je obejrzeć. Szacun.
Dzięki -> i piątek staje się jeszcze piękniejszy
Staty, odcinek na pewno profeska jak zawsze u ciebie
dzięki :)
Super jak zawsze:)
dzięki :)
Czyli jakbysmy mieli zapytanie Select PEEnsja from Tabela where nazwisko = "Pawelec" to silnik bazodanowy leci od poczatku tabeli i dopiero gdy natrafi na te nazwisko zwaraca wynik ( i przechodzi tez po calej tabeli nawet jak ten rekord jest gdzies na poczatku),a przy uzyciu indeksu, indeks od razu sie odwoluje do tego rowid? Dobrze rozumiem? :)
Silnik czyta całą tabelę nawet jak pierwszy rekord spełnia warunek nazwisko = "Pawelec", ponieważ nie ma pewności, że takich rekordów jest kilka, np. ostatni rekord. I tu jest przewaga indeksu, bo jest posortowany - i wiadomo, że ja kolejna wartość się różni to więcej taka wartość jak Pawelec nie wystąpi. Gdy indeks dodatkowo jest unikalny to gdy natrafiasz na pierwszą pozycję to kończysz czytanie, bo wiesz, że jest tylko jeden taki rekord. Gdy indeks jest nieunikalny to czytasz dopóki warunek jest prawdziwy.
Czytanie indeksu skutkuje tak naprawdę tworzeniem zbioru ROWID-ó do odczytu potem z tabeli. Nie jest tylko powiedziane, że baza ma ROWID to idzie do tabeli(BY ROWID). Równie dobrze najpierw może zebrać wszystkich ROWID-y a potem na raz odczytać z tabeli te rekordy(BY ROWID BATCHED): www.ktexperts.com/difference-between-rowid-and-rowid-batched-in-oracle/
@@nieinformatyk czyki jeśli jest np. dwóch Pawelcow to w indeksie są to dwa rekordy z dwoma rowid?
@@maciejsobolewski7675 tak, ale to są różne ROWID, tzn, Pawelec ROWID1, Pawelec ROWID2
A co w przypadku gdy zrobimy np warunek id > 50 czy wtedy znaczenie ma pk? Czy bez rowid przeszukiwana będzie cała tabela?
Bez indeksu zawsze jest czytana cała tabela(wyjątkiem jest tabela partycjonowana, kiedy mamy opcję czytać partycję tabeli). W sytuacji warunku id>50 baza danych może wykorzystać ścieżkę index range scan - pod warunkiem, że będzie istniał indeks. Oczywiście kluczowa będzie selektywność warunku, tzn. informacja o tym jak duży % rekordów wybieramy z tabeli. Jeśli książka ma 500 stron a Ty napiszesz: wybierz strony > 50 to baza raczej przeczyta całą książkę(tabelę). Jeśli warunek to strony większe niż 498 to baza raczej wykorzysta indeks, bo wybierasz 2/500 rekordów :)
Niedawno zacząłem się uczyć o bazach danych i nie rozumiem po co są te indexy w taki sposób jak ty tłumaczysz. Jeśli w tabeli tworzymy klucz główny to jednocześnie tabela w pamięci staje się posortowana i klucz działa jak wewnętrzny index tabeli(tzw Clustered index). W takim wypadku w tym przykładzie co podałeś na początku jeśli jest klucz główny baza danych z tego co rozumiem nie musi przeszukiwać całej tabeli aby znaleźć tego pracownika.
Ja mówiłem w moim nagraniu o standardowym i typowym dla wszystkich DBMS przykładzie czytania tabeli(nieposortowana struktura, tzw. heap organized table) za pomocą indeksu(nonclustered index), czyli dodatkowej posortowanej struktury, zupełnie oddzielnego obiektu. Ty w swoim komentarzu założyłeś błędnie, że mówiłem o clustered index(indeks jest de facto posortowaną tabelą). Wtedy rzeczywiście dodatkowy indeks niemiałby sensu, bo po co sortować coś posortowanego :)
Problemem być może jest kwestia nazewnictwa indeksów, która moim zdaniem w Sql Server(bo zapewne tego RDBMS się uczysz) jest mega słaba: clustered index to nic innego jak tabela, która działa jak indeks. Czyli masz 1 obiekt: tabelę z posortowanymi rekordami po PK. W Oracle jest to nazwane dużo lepiej(index organized table). Nazwa sugeruje, że chodzi o tabelę, która przechowuje dane jak indeks.
Z mojego doświadczenia wynika, że w 99% przypadków do optymalizacji używa się zwykłych indeksów(nonclustered), ponieważ w przypadku operacji DML na tabeli przebudować trzeba mały nonclustered index(czyli ten dodatkowy posortowany obiekt, który wskazuje na rekordy tabeli). Tabela ma dużo większy rozmiar(więcej kolumn), ale ponieważ nie jest posortowana to nie trzeba nic robić. Rebuild clustered index/index organized tabel trwa duuużo dłużej.
@@nieinformatyk dzięki za odpowiedź tylko założyłem tak bo z 1 normalizacji wynika że każda tabela musi posiadać klucz podstawowy i właśnie tego nie rozumiem bo w takim wypadku zawsze tabela ma ten clustered index i jest posortowana. Jak to wygląda w przypadku Oracle?
@@aaaa-rj6uh "1 normalizacji wynika że każda tabela musi posiadać klucz podstawowy" - to prawda, ale nie wynika z tego, że tworząc PK(klucz główny) zostanie stworzony równocześnie clustered indeks. W Oracle przy tworzeniu PK automatycznie tworzony jest indeks (nonclustered - choć w nomenklaturze oraclowej nie ma czegoś takiego jak nonclustered index. Indeks to po prostu indeks). W Sql Server z tego co widzę jest na odwrót, bo domyślnie przy PK baza tworzy clustered index: learn.microsoft.com/en-us/sql/relational-databases/tables/create-primary-keys?view=sql-server-ver16
Ma to swoje zalety: pisząc selecta na tabeli nie trzeba sięgać do indeksu, a potem tabeli(table access by ROWID), ale jak mówiłem sprawia to problemy z DML. th-cam.com/video/Pz9vFdnSsKk/w-d-xo.html
Co baza to rozwiązanie :)
Jedyna uwaga szkoda że nie pokazałeś na końcu na jakimś dużym zbiorze danych gdzie wyszukiwanie trwałoby np 2 sekundy lub parę ma z indeksem lub jakieś zapytanie z join które pokazałoby optymalizację
To już można samemu zrobić w ramach pracy domowej :) Zasilić dane milionem rekordów, np. używając CONNECT_BY a potem wykonać 2 SELECT-y(z indeksem i bez).
No dzisiaj nie miałem się do czego przyczepić;)
uff.. może w kolejnym odcinku uda Ci się coś znaleźć
Ale trafiłeś akurat o tym czytam i dla mnie troche nudniejsza tematyka niż inne rozdziały w nauce SQLa ;)
A mnie jara najbardziej optymalizacja :)
znowu jestem pierwszy 😁
Z tego co widzę to trzeci :)
@@nieinformatyk 🤔może dzisiaj i trzeci ale jutro... ale jutro 😏 jutro będę number Łan. pozdrowienia od Franka O.
@@coTyNiePowiesz haha, cały czas na haju :)