|
Optimizacija baze - neki savet
Radim neku aplikaciju i zelim sto bolje da je testiram...
Zato sam ubacio 220 miliona unosa. Upit se izvrsava samo nad jednom tabelom. Pre toga stavio sam indeks na polje po kome se vrsi pretraga ono koje je u WHERE. To polje je VARCHAR. E sad.. Prvi put kada trazim nesto rezultat mi vrati za nekih 3 min. A svaki sledeci upit izvrsava za 0.04 sec i slicno... Mislio sam da ovaj index da ce ubrza i prvi put vracanje podataka... Jel ima neko savet, ili link na netu kako da optimizujem bazu, tj tabelu da mi uvek vrati za sto krace vreme.. Pored dodeljivanja Index-a koloni, uradio sam i optimizaciju na sledeci nacin OPTIMIZE TABLE `tabela` Zanima me sta jos mogu da ucinim? |
to sto je drugi upit brzi je zbog cache-iranja, nema veze sa indexima...
Dodaj EXPLAIN ispred tvog sql upita da bi dobio vise podataka o tome kako se izvrsava upit i da li zaista koristi index ili ne. Nesto vise od toga tesko da mogu da ti pomognem posto nisi napisao koji je upit u pitanju |
Ukoliko planiras da ti korisnici rade pretragu na 22m redova, zaboravi na bazu.
Ja koristim Search Lucene i odlican je http://lucene.apache.org/core/ Postoji klasa skoro za sve jezike. |
Citat:
|
^ @jablane: ovo o cemu on prica (prvi upit spor, drugi brz) je mysql query cache, naprosto se kesira rezultat upita i kad postavis isti taj upit ponovo, on ti ga vrati iz memorije.. (koliko ja znam) nema veze sa tim jel indexirana pretraga ili ne..
a posto mu pretaga traje 3 min. u lokalu verovatno upit ni ne koristi indexe ili je index prevelik da stane u cache |
http://dev.mysql.com/doc/refman/5.1/...-defaults.html my-huge.cnf
Probaj sa http://dev.mysql.com/doc/refman/5.1/...in-select.html znači... Kôd:
SELECT SQL_NO_CACHE id, ime FROM tabela;Postavi query koji koristiš, i postavi output od EXPLAIN EXTENDED... |
Čak i da je isključen query keš, kada se isti upit ponovi dva puta zaredom, drugi upit će u većini slučajeva biti brži nego prvi. Fora je što i sam sql povuče neke ključeve i tabele u memoriju, i file system nešto pomalo kešira itd. itd. i rezultat obično uvek bude brži nego prvog puta.
|
^ Da, na ovo sam ja mislio (keširanje indexa), zaboravio sam na keširanje rezultata. :)
|
Da, MySQL kesira bar je test pokazao...
Mislio sam da ima neke metode pored onih koji sam primenio za ubrzanje upita... Ali koliko vidim nema, bar od tih jednostavnih. Tako da je sve u redu. Hvala :1090: |
Dodao bih u ovoj temi jedno pitanje
Imam sledeci datum u bazi, na primer create_date ============== 2012-12-22 15:22:12 Treba da ga ispisem na stranici u euro formatu ali samo datum, tipa 22.12.2012 I) Pokupim ovaj datum iz baze, i preko php, npr( new DateTime(), ), formatiram datum kako mi odgovara II) Direktno u SQL obradim datum (preko mysql funkcija) Kôd:
DATE_FORMAT(create_date, GET_FORMAT(DATE,'EUR'))Jer na ovaj drugi nacin opterecujemo konekciju ka bazi, a zamislimo da je neki portal. Ispada da bi trebalo da izbegavamo ove funkcije i da uvek radimo obradu u php. Ili gresim?! Jer ja ih izbegavam i ne znam da li sam u pravu sto sve radim kroz php. |
| Vreme je GMT +2. Trenutno vreme je 23:30. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.