Które linki wydajniejsze?

[skrypta]

@ja uzywalbym varchar, roznica pomiedzy kluczem INT a kluczem varchar w czasie dzialania jest niewielka

#Jeszcze lepiej klucze główne tabeli na polach varchar

Proponuje jednak zachowaj swoje doświadczenia dla siebie.

wordpress = post_name varchar(200)

oczywiscie primary key na int(100) dla relacji i informacji dodatkowych, natomiast wyciagniecie posta po url.. varchar

zapelnij tabele 10tys rekordow i wyciagnij 1 po kluczu (indexie) int 100 i varchar 200 - sprawdz jaka roznica w czasie i pamieci

wykonaj to samo dla 50tys rekordow, zobaczysz o czym mowie..

[Mion]

(indexie) int 100

Pole integer 100 znakowe czy ja dobrze widzę

Kolejny user który "wie lepiej" wszystkie opracowania o wydajności bazy danych.

[milkus]

Ja zawsze używam id na zasadzie domena.com/dzial-nazwa_art-id.html i jakoś to się mi sprawdza . Wyszukiwanie i wyświetlanie wyników po id jest dużo łatwiejsze, a na dodatek zawiera zazwyczaj krótsze zapytanie SQL. Im mniej kodu i im krótsze zapytania, tym lepiej.

[skrypta]

(indexie) int 100

Pole integer 100 znakowe czy ja dobrze widzę

Kolejny user który "wie lepiej" wszystkie opracowania o wydajności bazy danych.

int(100) jest stosowany np w wordpressie i stad ten przyklad, rozumie zatem ze to zarzut pod ich adresem?

zrobiles testy z roznymi dlugosciami klucza i typow? nie? goraco polecam..

[Mion]

Pole kolumna typu int (SIGNED INT) może przechowywać liczbę do 2147483647, lub UNSIGNED INT 4294967295. Wiec nie wiem skąd odczytałeś pole int(100). Poza tym stawianie WP jako wzoru wydajności jest delikatnie pisząc śmieszne.

Nie muszę robić testów dla zagadnień które są oczywiste, a twoje dywagacja na ten temat można porównać do udowodnia, że ziemia jest płaska. To wszystko z mojej strony na ten temat.

[Hubert]

(indexie) int 100

Pole integer 100 znakowe czy ja dobrze widzę

Kolejny user który "wie lepiej" wszystkie opracowania o wydajności bazy danych.

int(100) jest stosowany np w wordpressie i stad ten przyklad, rozumie zatem ze to zarzut pod ich adresem?

zrobiles testy z roznymi dlugosciami klucza i typow? nie? goraco polecam..

to ja mam chyba nie tego wordpressa bo u mnie największe pole liczbowe to bigint(20),

co do testów proszę zaskocz nas swoimi ;] z niecierpliwością czekam

[skrypta]

to ja mam chyba nie tego wordpressa bo u mnie największe pole liczbowe to bigint(20)

Racja, moja pomylka, wszedzie jest bigint(20) a nie int 100, przedszkolna pomylka.

Wordpressa podalem nie jako przyklad najlepiej zoptymalizowanego skryptu ale jako stabilny przyklad oparty na przyjaznych url z kluczem varchar(200). Nie rozmawiamy tu przeciez o dedykowanych rozwiazaniach tylko o przecietnych serwisach i moim zdaniem nie ma znaczacej roznicy, ponizej moje wyniki. W moim przypadku, serwis 150tys uniq/mies, baza 60tys artykulow i 140tys kont, roznica w czasie wykonywania zapytan jest do pominiecia dlatego nie mam powodu do przesylania INT id w url. Moja opinia.

Wyniki dla ponizszej tabeli myisam, powyzej 37000 rekordow

pole id bigint(20) PRIMARY KEY

pole url varchar(100) KEY

Space usage

Type Usage

Data 10,973.8 KiB

Index 6,732.0 KiB

Statements Value

Format dynamic

Options row_format=DYNAMIC

Collation utf8_polish_ci

Rows 67,923

Row length ø 134

Row size ø 235 B

Next Autoindex 71,620

zap 1) SELECT * FROM tab1 s, tab2 w WHERE s.id=w.id2 and s.url="przyjazny-url"

czas 1: 0,0009

czas 2: 0,0004

czas 3: 0,0003

czas 4: 0,0004

zap 2) SELECT * FROM tab1 s, tab2 w WHERE s.id=w.id2 and s.id=12999

czas 1: 0,0008

czas 2: 0,0003

czas 3: 0,0003

czas 4: 0,0003

wyniki dla wiekszej tabeli ponad 144000 rekordow

pole id bigint(20) PRIMARY KEY

pole account_name varchar(40) KEY

Space usage

Type Usage

Data 12,702.5 KiB

Index 15,869.0 KiB

Format dynamic

Collation utf8_polish_ci

Rows 144,354

Row length ø 90

Row size ø 203 B

Next Autoindex 352,480

zap 1) SELECT * FROM tab1 s, tab2 w WHERE s.id=w.id2 and s.account_name="przyjazny-account-name"

czas 1: 0,0008

czas 2: 0,0003

czas 3: 0,0003

czas 4: 0,0004

zap 2) SELECT * FROM tab1 s, tab2 w WHERE s.id=w.id2 and s.account_name=49711

czas 1: 0,0007

czas 2: 0,0003

czas 3: 0,0002

czas 4: 0,0003

[Hubert]

cytując i mając na uwadze całość dyskusji z Mionem

zrobiles testy z roznymi dlugosciami klucza i typow? nie? goraco polecam..

albo ja czegoś nie zrozumiałem albo przeczysz tym testem swojej tezie że wyszukiwanie po polu tekstowym (w tym wypadku varchar) jest może być szybsze od wyszukiwania po polu liczbowym.

wszystkie znaki na niebie i na ziemi mówią że pole liczbowe w testach jest nieznacznie szybsze, w praktyce pod dużym obciążeniem może to mieć trochę większe znaczenie. Odnośnie testowania, użyj SQL_NO_CACHE.

[skrypta]

albo ja czegoś nie zrozumiałem albo przeczysz tym testem swojej tezie że wyszukiwanie po polu tekstowym (w tym wypadku varchar) jest może być szybsze od wyszukiwania po polu liczbowym.

wszystkie znaki na niebie i na ziemi mówią że pole liczbowe w testach jest nieznacznie szybsze, w praktyce pod dużym obciążeniem może to mieć trochę większe znaczenie. Odnośnie testowania, użyj SQL_NO_CACHE.

nie zrozumielismy sie, zgodnie z rezultatami testu, wyciagniecie rekordu po bigint(20) jest nieznacznie szybsze anizeli varchar(100) i na zdrowy rozsadek tak wlasnie powinno byc, co pewnie ma zwiazek glownie z dlugoscia klucza o ile sie niemyle a nie wylacznie typem klucza

moim celem bylo pokazanie ze przy sredniej wielkosci serwisach strata czasowa pomiedzy odwolanie przez INT a VARCHAR, w moim przypadku rzedzu 0,0001s, jest tak niewielka ze mozna ja spokojnie pominac i nie zawracac sobie glowy umieszczaniem INT ID w adresie url. mysql spokojnie sobie poradzi z takim odwolaniem po varchar.

naturalnie ma znaczenie jaki hosting uzywasz, czy masz dedykowana baze dla siebie, ile pamieci, jakie ustawienia itp itd. nie mam doswiadczenia w serwisach z wieksza liczba uzytkownikow niz 140tys i wieksza iloscia artykulow niz 60tys ale tylko moge sie domyslac i absolutnie zgodzic z toba ze im wieksza ilosc rekordow tym wieksza roznica, ale czy w przypadku duzych serwisow nie wchodza w gre memcache, cache, tune up bazy i inne dedykowane rozwiazania?

"użyj SQL_NO_CACHE" - racja

zap 1) dla varchar

czas 1: 0,0009

czas 2: 0,0009

czas 3: 0,0008

czas 4: 0,0009

zap 2) dla int

czas 1: 0,0007

czas 2: 0,0008

czas 3: 0,0008

czas 4: 0,0009

[Hubert]

myślę, że w powyższym poście jest wszystko przyzwoicie opisane. wracając jednak do wordpressowego bigint, to jest on chyba ułańską fantazją twórców wordpress'a ;-) myślę że na 99% blogów styknal by int. Według mnie zastosowanie ID w linku jest dobrą praktyką tak jak używanie '' zamiast "" tam gdzie nie ma potrzeby użycia "" (mowa o PHP). Co do dużych serwisów, owszem, są memcache, są szybsze od mysql'a bazy, jest load balancing - ale według mnie podejście w stylu "możemy to olać narazie, najwyżej dokupimy serwer" jest do d**y. Dobre praktyki są po to żeby jest stosować na codzień a nie robić mikrooptymalizacje bo serwer się dławi.

[relons]

Panowie, co wy za bzdury piszecie. Czy wpiszecie 100 czy 10 przy polu int zawsze będzie ono 32-bitowe! Myślicie, że można kazać zapisać INTa na 3 cyfrach wpisując int(3)? To jesteście w błędzie. W przypadku pól liczbowych w MySQL liczba w nawiasie oznacza na ilu miejscach przy listingu będzie reprezentowana dana liczba. Przy wartości 10 i liczbie 123 wyświetlone będzie 7 spacji i dopiero liczba właściwa.

Przy polu varchar(100) rzeczywiście będzie można przechowywać do 100 znaków, ale w przypadku pól liczbowych to już tak nie działa