upit
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 668936,36
je pogresan (da ne upotrebim neku drugu rec) i MORA da traje.
Duzina trajanja tog upita iskljucivo zavisi od brzine diska. Mozes da racunas na disk cache i innodb_buffer_pool ako je tabela mozda innodb ali opet ne mozes da ocekujes da ce se cela tabela uvek nalaziti u keshu a tebi ovde treba cela tabela
1. nemas nikakav uslov za upit, znaci SELECT mora da procita SVIH 700000 slogova
2. onda svih tih 700000 mora da sortira da bi ti dao 36 komada posle 668936tog
dakle, ne mozes da ubrzas taj upit, mozes da redizajniras bazu tako da ti takav upit nikad ne treba. Ako je record_num slucajno unique index po njemu bi ubrzao sortiranje mada 175sec za citanje 700k slogova prilicno brzo tako da pretpostavljam da je record_num vec indexiran.
sad ti mozes da mi kazes, ali to je tabela sa pesmama i covek lista pesme i ima 36 po strani i kada dodje na 18581tu stranu onda imamo ovaj upit. Ako ti korisniku treba da dozvolis da ide next next stranu po stranu do 18581. strane onda ga pusti da saceka 3 minuta da mu se strana izgenerise, al bas bi voleo da vidim toga ko je otisao na 18581 stranu rucno !!! doticnu moze da nabode samo neki crawler i to je to ... dakle app terba da ima "max" broj strana koje ce da prikaze (20 je vise nego dovoljno, 100 je izivljavanje), ako neko zeli rezultat sa 21 strane, neka suzi kriterijum pretrage.
To sto se upiti izvrsavaju brzo par sekundi posto je upit izvrsen je zato sto
1. query cache iskesira ceo rezultat upita (taj rezultat izleti prvi put kada se nesto u tabeli promeni)
2. disk cache / ibd buffer pool iskesiraju taj deo diska (to opet izleti odatle kada mu nesto drugo zauzme mesto)
ako hoces da proveris sta ti ubrzava taj upit izvrsi ga dva tri puta sa:
SELECT SQL_NO_CACHE record_num,title FROM content ORDER BY record_num DESC LIMIT 668936,36;
to ce ga izvrsiti bez query cache-a ali ce disk i ibd cache biti upotrebljeni pa vidi koliko ce drugi i treci put raditi brze
E sada, sa ovolikom tabelom i slicnim upitima treba da obratis paznju na
partitioning ali
1. zelis da predjes na 5.5 zato sto to tamo radi bolje
2. svejedno moras da radis redizajn db modela i aplikacije posto ovaj prosto ne valja
Kreni od proste cinjenice, koliko ti vremena treba da iskopiras fajl od 1G sa diska u /dev/null ..