|
PHP MySql Query i opterecenje servera ?
Treba da napravim 4 sql tabele,
prve dvije ima 10 polja od kojih su skoro svi int ili varchar (30) druge dvije imaju 100 polja od kojih su sva polja int (1) i imaju vrijednosti 1 ili 0 Interesuje me koliko bi opterecavalo mysql i http server kada bih cesto pozivao ove dvije tabele sa po 100 polja. (cesto je odprilike 30ak puta u minuti a mozda manje a mozda vise ali nakon prve 3-4 minute onda bi pozivi bazi bili jako rjedji...) :1041: |
Nisi dao dovoljno informacija...
1. Koliko su velike tabele 2. Koliko redova odjednom citas 3. Na kakvoj se masini nalazi mysql server U principu pozivi na svake 2sec nisu nista, cak je to veoma malo. |
Najbitnije mi je za ove dvije tabele sto imaju 100 polja.
Svako polje u tim tabelama ima duzinu 1 i vrijednost je 0 ili 1 A morao bih da citam sve redove iz te tabele odjednom... |
Čoveče, nisi odgovorio ni na jedno pitanje...
Citat:
BTW, 100 polja tipa BIT može biti indikator da ti normalizacija nije urađena kako treba. |
Da pojasnim
Koliko su velike table = Koliko redova imas Da se nadovezem Posto toliko cesto moras da citas, pretpostavljam da moras da insertujes/updejtujes jos cesce... da sam na tvom mestu mene bi to vise zabrinjavalo. |
Nabrzaka jedan savjet - umjesto int(1) koristi tinyint(1).
|
Citat:
blagi off: procitah negde, valjda u high performance mysql da je dobra fora za tabele sa mnogo polja (tipa user_details na socijalnim mrezama) da tu tabeleu podelis na dve, jednu u kojoj cuvas podatke kojima bas cesto pristupas (user, pass, email...) i drugu u kojoj su podaci koji se vide samo na pojedinim stranicama, ili koje samo korisnik i vlasnici vide (adresa, telefon, education info....) |
jako je bitno (rekao bih najbitnije) kakve upite pravis ? Sta je u WHERE, da li radis ORDER BY, GROUP BY, itd.. Od toga ti zavisi koje indexe mozes da koristis, i kako...
Umesto da imas 100 polja koji su 0 ili 1 (za sta bi mogao da koristis BOOLEAN) mozes da koristis 4 (~100/32) integer polja gde su vrednosti mapirane u bite, a da upite nad tim poljima pravis pomocu bit maski. Ustedeo bi jako puno prostora, i dobio na brzini (znatno manji index, jos ako je myisam tabela pa ima fixnu velicinu rekorda bila bi jako brza) |
Off Topic: @ivanhoe boolean u mysql je tinyint(1) ;) |
Da li vrednosti pojedinih polja čitaš nezavisno jedno od drugog ili čitaš svih sto polja od svakog sloga svaki put?
Pitam, jer sam nekoliko puta koristio foru da umesto n int (boolean) polja koristim samo jedno polje od char(n) slogova; i upisivao vrednosti kao: "1001010101 ...... " Dohvatanje jednog stringa od n karaktera i programsko deljenje u niz je solidno brzo. |
^ Da, to sam i ja radio... vrlo zgodno i jednostavno... samo napravis konstante kao neke maske ... i pichis :)
Cak i search u mysql po bilo kom bitu ne predstavlja problem kao sto izgleda na prvi pogled |
Citat:
|
Citat:
PS. Mislim da je tema za drugi forum... |
Kako to stedi prostor vise od CHAR(1) ? ili TINYINT?
|
CHAR(1) i TINYINT zauzimaju jedan bajt, a CHAR(0) NULL jedan bit, 8 puta manje ;)
|
Iskreno nisam ni znao da je to moguce, a mislio sam da najmanje 1 bajt moze da se adresira. Kako se to opste upise u tabelu (tabele su fajlovi na disku, kako upisu taj 1 bit a da ne "propadnu" ostali kao neiskorisceni)?
|
nisam znao ovo, koristan info... mada verovatno je sporije od rada sa celim bajtovima ?
|
Vidiš, nisam toliko razmišljao o tome od silnog oduševljenja kada sam slučajno naleteo na tu foru posle dužeg neuspešnog traženja i to u manual-u. :) Evo ovde primera korišćenja sa razlozima za i protiv: http://www.mysqlperformanceblog.com/...innodb-tables/
Zaključak: Should you go and change all flags to use this approach (CHAR(0))? I do not think so - for most applications using TINYINT, BIT(1) or ENUM for flags benefit would unlikely be worth the trouble. Due to complication I also would not recommend as a base approach for new applications. However in special cases if you have very many rows and very many flag values to deal with which you can't pack to the bitmask this approach can be quite helpful. |
| Vreme je GMT +2. Trenutno vreme je 22:54. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.