LIMIT - optymalizacja zapytań po indeksie Opcje

[armon]

Witam,

Czy

[PHP] pobierz, plaintext 
SELECT pole FROM tabela WHERE id = 1 LIMIT 1
[PHP] pobierz, plaintext 

jest szybsze od

[PHP] pobierz, plaintext 
SELECT pole FROM tabela WHERE id = 1
[PHP] pobierz, plaintext 

gdy id jest primary key lub też unique?

Wiem, że bez indeksu na pewno jest szybsze, ponieważ po znalezieniu jednego rekordu nie trzeba przeszukiwać następnych.

Lecz z indeksem unikalnym samo z siebie wynika, że to się już nie powtórzy? więc chyba nic nie przyspieszy?

Rozumiem, że z normalnym INDEX (bez unique), LIMIT 1 przyspiesza zapytanie?

Myślę nad ustawieniem w bazie danych login na klucz unique, oraz login i hasło na klucz złożony INDEX. Na samo hasło nie będę nakładał indeksu bo po co w końcu jakieś tam szansę powtórzenia ma.

Tak więc wybierają później

[PHP] pobierz, plaintext 
SELECT id FROM tabela WHERE login = 'loginek' AND haslo = 'cryptedwhirlpoolthing' LIMIT 1
[PHP] pobierz, plaintext 

Najlepiej dodać do końca LIMIT 1 tak?

Ten post edytował armon 20.09.2011, 08:51:42

[maly_swd]

jesli jest unique/primary to moim zdaniem nie ma znaczenia limit (bo i tak czyta to z klucza)

co do tego "SELECT id FROM tabela WHERE login = 'loginek' AND haslo = 'cryptedwhirlpoolthing' LIMIT 1"

to jesli masz na login unique/primary to nie ma opcji aby bylo 2 uzytkownikow z tym samym loginem a co za tym idzie nie moga byc 2 hasla. Wiec limit nie ma sensu

[armon]

to jesli masz na login unique/primary to nie ma opcji aby bylo 2 uzytkownikow z tym samym loginem a co za tym idzie nie moga byc 2 hasla. Wiec limit nie ma sensu

Ale jest opcja, że dwóch użytkowników będzie miało te same hasła, a różne loginy, a koniunkcja jest spełniona wtedy i tylko wtedy, gdy oba argumenty są prawdziwe.

Chcę uwzględnić tutaj optymalizację pod klucz złożony (nałożony na pole login I hasło), wybieramy nie tylko po loginie, ale również po haśle. Klucze złożone potrafią jeszcze bardziej przyspieszyć zapytanie.

Myślę, że baza po tym, że login jest unique, a hasło i login są kluczem złożonym nie może się domyślić faktu, że login i hasło W TYM SAMYM momencie są różne, więc dodanie LIMIT 1 chyba przyspieszy (co prawda nieznacznie, ale to zrobi?)

Ten post edytował armon 20.09.2011, 09:01:52

[maly_swd]

" że dwóch użytkowników będzie miało te same hasła, "

No pomysl, masz unique na uzytkowniku, wiec jesli login sie nie zgadza to mysql nie porownuje dalej hasla, co za tym idzie dostaniesz tylko to co spelnia 2 warunki czyli 1 uzytkownika

nospor-> ja sprawdzalem podobnie i jesli warunki dotyczna pola unique to limit nie dawal roznicy. Baza z 20mln wpisow.

Wiec pewnie tez zalezy od bazy (danych) i innych czynnikow, ale jesli limit nie szkodzi to czemu go nie dawac:)

[armon]

" że dwóch użytkowników będzie miało te same hasła, "

No pomysl, masz unique na uzytkowniku, wiec jesli login sie nie zgadza to mysql nie porownuje dalej hasla, co za tym idzie dostaniesz tylko to co spelnia 2 warunki czyli 1 uzytkownika

nospor-> ja sprawdzalem podobnie i jesli warunki dotyczna pola unique to limit nie dawal roznicy. Baza z 20mln wpisow.

Wiec pewnie tez zalezy od bazy (danych) i innych czynnikow, ale jesli limit nie szkodzi to czemu go nie dawac:)

Rzeczywiście pod warunkiem, że MySQL potrafi się domyślić po tym, że gdy na login jest nałożony indeks UNIQUE to pierwszy znaleziony rekord MUSI być jedynym, który mógłby spełnić koniunkcję. Nie uwzględniłem w moim rozumowaniu faktu, że MySQL ma to tak zoptymalizowane względem operatorów logicznych.