[ Chorlya @ 14.10.2003. 19:44 ] @
Daklem koja je od ove dve varijante brza?
Imam sledecu tebelu(ovde su prikazan samo polja po kojima cu pretrazivati i sortirati a u tabeli ima jos nekoliko varchar polja ali mislim da to nije vazno u ovom slucaju)
Code:

CREATE TABLE car_listings(
  pkListingID bigint(22) unsigned NOT NULL auto_increment,
  country tinyint(3) unsigned NOT NULL default '0',
  make int(11) unsigned NOT NULL default '0',
  model int(11) unsigned NOT NULL default '0',
  price int(11) unsigned NOT NULL default '0',
  enterd int(11) unsigned default NULL,
  PRIMARY KEY  (pkListingID),
  KEY ListingKey_2 (country,make,model,price)
) ENGINE=MyISAM;


i izvrsavacu sledece upite:

Code:

SELECT * FROM car_listings WHERE country=13 AND make=125 AND
model=562AND price>= 50000 AND price<=100000 ORDER BY enterd DESC;

SELECT * FROM car_listings WHERE make=125 AND model=562 AND
price>= 50000 AND price<=100000 ORDER BY enterd DESC;

SELECT * FROM car_listings WHERE make=125 AND price>= 50000 AND
price<=100000 ORDER BY enterd DESC;


Da li neko ima iskustva sa razlikom u brzini izmendju gore kreirane tabele u poredjenju sa tabelom kod koje bi svaki index iz ListingKey_2 bio zaseban, znaci

Code:

CREATE TABLE car_listings(
  pkListingID bigint(22) unsigned NOT NULL auto_increment,
  country tinyint(3) unsigned NOT NULL default '0',
  make int(11) unsigned NOT NULL default '0',
  model int(11) unsigned NOT NULL default '0',
  price int(11) unsigned NOT NULL default '0',
  enterd int(11) unsigned default NULL,
  PRIMARY KEY  (pkListingID),
  KEY country_key (country),
  KEY make_key (make),
  KEY model_key (model),
  KEY price_key(price)
) ENGINE=MyISAM;


Bilo kakav savet je dobro dosao. Tabela bi trebala da ima negde oko par stotina hiljada zapisa, verovatno ne vise od 500.000.
[ Deep|Blue @ 14.10.2003. 22:10 ] @
Pazi pretrazivanje indeksirane kolone je uvek v=brze od pretrazivenje neindeksirane. dakle mozes slobodno da stavis indekse na svaku kolonu preko koje cesto vrsis pretrage.
za ovaj pkListingID postavis ga da je klasterovan

za mysql par stotina hiljada slogova je pristojna cifra i treba mupomoci sa indeksima
[ broker @ 15.10.2003. 10:18 ] @
MySQL ume sam da "sabira" indekse i preporuka je da postavis indekse na ona polja koja se koriste za filtriranje upita i uređivanje redosleda prikazanih slogova ali za svako polje posebno. Tako omogućavaš MySQL-u da sam kombinuje indekse.

Indeks po više polja odjednom mislim da ima smisla samo ako je to UNIQUE indeks.
[ Last Man Standing @ 15.10.2003. 12:27 ] @
Odgovor nije bas tako jednostavan. Recimo da ces da izvrsavas SAMO ove upite sto si pomenuo (sa razlicitim parametrima, naravno). U tom slucaju mozes da uradis i samo jedan index sa sledecim rasporedom:

KEY ListingKey_1 (price, make,model, country)

Indexi su zasebne (i uredjene) strukture podataka koje pokazuju na odgovarajuci slog u tabeli. Daleko najbrze je ako sve kolone koje imas u WHERE imas i u indexu. Tada DBMS za klasifikaciju ne mora da ide do tabele (u kojoj su ti slogovi rastrkani na sve strane, osim ako index nije clustered) sto stedi dosta vremena. Ako imas index na kolonama (A, B) upiti gde imas WHERE A = nesto (ili narocito WHERE A = ... AND B = ...) bice brzi. Medjutim, upit WHERE B = nesto nece biti brz. U stvari, verovatno se index nece ni koristiti, jer je index uredjen po kolonama i u redosledu koji si dao pri kreiranju indexa. U tvom primeru, posto uvek imas 'price', to ide na prvo mesto, zatim make, pa model i na kraju country.

Probacu danas da vidim da li indexi mogu da se kombinuju (mozda naucim nesto novo), ali sumnjam, pogotovu za tabelu te velicine. Za sortiranje po koloni ti svakako nije potreban index. Imaj na umu da ako imas mnogo istih vrednosti u koloni koja je indexirana, moguce je da se index i ne koristi, jer je brze da se direktno ide do tabele. Na primer, ako imas samo 2-3 zemlje, nemoj da kreiras index po zemlji.

Pojedinacni indexi bi ti dali malo vise slobode. Gornji index ne bi pomogao ako bi imao recimo upit WHERE country = 15 ili WHERE make = 20. Dakle pokusaj da predvidis svoje upite i na osnovu toga donesi odluku. U svakom slucaju, indexe uvek mozes da kreiras/brises/menjas.
[ Deep|Blue @ 15.10.2003. 23:56 ] @
Izvinjavam se, moja greska nisam obratio paznju da pitas za kljuceve.

u ovoj tabeli vec imas poolje koje moze da posluzi kao jedinstveni identifikator (pkListingID) i nemas razloga da stavljas jos neki kljuc posto se definitivno nece pojaviti dva sloga sa istom vrednoscu za ovo polje.