szybkość generawana strony

[furjat]

Witam,

Wiem, że najwęcej czasu przy generowaniu strony zajmują zapytania sql.

Czy ktoś sie orientuje czy takie zabiegi jak podanie kloumn z tablei

"select nazwa_kolumny from..." zamiast "select * from"

albo dodanie na koncu limit 1 (bo wiem ze bedzie tylko max 1 odpowiedz)

wpływa na szybkość tych zapytań??

czy optymalizacja kolumn tabeli tez cos zmieni - np. zamiast varchar(50) zrobie varchar(30)

i...

czy pomoze tu stworzenie nowej bazy danych - w obecnaj mam jakies 450 tabel na tym samym serwerze

Pozdrawiam

[Mion]

"select nazwa_kolumny from..." zamiast "select * from"

albo dodanie na koncu limit 1 (bo wiem ze bedzie tylko max 1 odpowiedz)

wpływa na szybkość tych zapytań??

Oczywiscie

czy optymalizacja kolumn tabeli tez cos zmieni - np. zamiast varchar(50) zrobie varchar(30)

Nie sądze

Znaczący wpływ na szybkość zapytań mają odpowiednie klucze i indexy w tabelach.

Pyzatym najlepiej empirycznie sprawdzać optymalizację zapytań implementując odpowiedni licznik czasu wykonywania kodu strony.

w obecnaj mam jakies 450 tabel na tym samym serwerze

W jednej bazie 450 tabel ?

[furjat]

sorki pomyliłem się mam 454 tabel w jednej bazie - założenie kolejnej bazy koszyuje

czy jak przerzuce tabele od tego projektu do nowej bazy to uzyskam jakis wzrost szybkości...

jak na moje to powinno cos dac bo nie trzeba bedzie się przekopywać przez te 450 tabel...

czy ktoś może potwierdzić moje przypuszczenia

[MMP]

Ja wariuje jak mam 15 tabel

Znaczący wpływ na szybkość zapytań mają odpowiednie klucze i indexy w tabelach.

Nie pamiętam czy to jest w char czy varchar. Ale jeśli nie wypełni się wszystkich całego ciągu dodawane są puste bajty?

Dobrze mówie?

[nrm]

dobrze. chodzi ci o char np. char(10) i wpis MMP da w rezultacie 'MMP0000000' (* te zera to oczywiscie tak w przenosni)

a co do glownego pytania: tak, roznica miedzy SELECT * FROM a SELECT raz,dwa,trzy,cztery FROM jest i w kazdej ksiazce o sql zalecaja nie korzystac z *

[Erbit]

dobrze. chodzi ci o char

Ale pytanie bylo odnosnie varchar() a w varchar tej reguly (uzupelniania) nie ma.

[Mion]

Baza wykorzystująca pola typu char w stosunku do varchar zyskują na szybkości oraz będą trochę "większe" z uwagi na dopełnianie "pustymi bajtami" do określonej wielkości pola.

Ale nie sadzę żeby różnica była między wydajnością bazy z polami varchar 30 a varchar 50 przy takiej samej długości danych.

Z pewnością różnica będzie przy dużych baza danych jeśli mam pola varchar 30 zapełnione a varchar 50. Będzie to wynikać z tego, iż 2 baza będzie większa a ze wzrostem wielkości bazy wydłuża się czas dostepu do przechowywanych w niej danych

[jurdziol]

Jesli pobieram dane wyszukajac poprzez pole TINYTEXT to jak z niego zrobic index ? Dostaje komunikat "#1170 - BLOB/TEXT column 'miasto' used in key specification without a key length ".

Czy lepiej inaczej to rozwiazac niz szukajac przez TINYTEXT?

[Mion]

Jesli pobieram dane wyszukajac poprzez pole TINYTEXT to jak z niego zrobic index ?

Pola textowe tego typu nie mogą stanowić indexów tabeli !

Pole mogąca stanowić index musi być określonej długości, najlepiej jak najkrotsze.

Indeks należy zakładać dla pól, według których najczęściej jest wykonywane wyszukiwanie.

Czy lepiej inaczej to rozwiazac niz szukajac przez TINYTEXT?

Pole TINYTEXT może przechowywać dane o rozmiarze nie przekraczającym 255 bajtów. Wiec zamień na typu:

char ->pole znakowe o stałej długości z zakresu od 1 do 255 bajtów. Po wstawieniu wartości puste miejsca pola CHAR są uzupełniane z prawej strony spacjami.

lub

varchar ->Pole znakowe o zmiennej długości z zakresu od 1 do 255 bajtów. Zajmowany jest jedynie taki obszar pamięci, jakiego wymaga wartość wstawiona w to pole.

i wtedy możesz utworzyć indexy