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?

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

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?)

limit na pewno nie zaszkodzi ani nie spowolni więc poprostu dodaj jeśli wiesz, ze chcesz pobrać max 1 rekord.

Mój plik będzie zajmował o 7 znaków w bajtach więcej z każdym takim zapytaniem ;P plik .php będzie musiał być dłużej czytany ;P

A tak na poważnie uruchomienie czegoś co jest niepotrzebne, nie zmienia faktu, że zostało to jednak uruchomione, czyli trzeba było wywołać kod jakiejś funkcji, nawet jeśli był tam warunek sprawdzający czy klucze nie są już unique etc., to trzeba było to sprawdzić i wywołać funkcję. Oczywiście to jest prawie nic, no ale przy milionach zapytań to jest coś

Czyli nikt nie wie?

Proszę Cię..... miej litość. A jeśli nie masz litości, to leć szybciutko kasuj wszystkie spacje, tabulatory, komentarze, skracaj nazwy wszystkich funkcji do max 3 znaków.

Zmierz czas z i bez i będziesz wiedział. Stwórz tylko wpierw dostatecznie dużą tablicę.

To pierwsze to było ironia, jednak rozkaz wywołania czegoś niepotrzebnie na pewno zabiera jakieś zasoby. Pozostaje mi przetestować.

Jakiś czas temu zastanawiałem się jak działa LIMIT. Wydaje mi się, że wycina ze zbioru wynikowego pewną porcję danych. Najpierw wykonuje się zapytanie z warunkami i sortowaniem, a potem odpalany jest LIMIT. Jeśli tak jest to jakiś narzut (pewnie śmiesznie mały, ale jednak) będzie by zamiast od razu zwrócić dane to jeszcze wyciąć z nich żądaną porcję. Jeśli ktoś ma w tej dziedzinie wiedzę to proszę o info - chciałbym wiedzieć jak to działa, tak z czystej ciekawości.

Akurat mam do testów dość sporą bazę i jednak wykonywanie zapytania z limit a bez jest znacznie szybsze. Na pewno najpierw muszą przejść warunki i sortowanie, bo bez tego limit nie miałby sensu, nie mniej jednak limit daje kopa więc jakoś to muszą wewnętrznie optymalizować.
Podkreślam jednak, iż stwierdzam tak na podstawie obserwacji a nie teoretycznej wiedzy.

Caly czas mowimy o wyszukiwaniu w tabeli wiersza na podstawie kolumny ktora ma PK ?

Akurat ja testowałem na różnych polach i z PK i z indeksem i bez

No to w takim przypadku limit na pewno pomaga

" ż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.