Iata o problema de mysql de care m-am lovit recent. Si cu aceasta ocazie am si făcut nişte teste de viteza. Iar rezultatele au fost spectaculoase.
Sa presupunem ca avem o tabela simpla :
an – integer;
luna – integer;
zi – integer ;
ora – integer ;
minut – integer;
operatie – string;
Si in timp sa presupunem ca tabela se populează cu 150.000 recorduri. Ulterior sa presupunem este necesara modificarea câmpului operaţie pentru anumite intervale orare . Prin urmare vor fi nişte query-uri de genul : UPDATE tabela SET Operatie=”teste” WHERE zi = 1 AND luna = 1 AND ora = 0 AND minut = 3 ; . Sa presupunem ca vine un lot de 78.000 de query-uri de update.
Daca nu se foloseşte index pe tabela rezultatul este acesta:
root@tfm64: 2# time mysql N < test.sql
real 55m2.482s
user 0m2.296s
sys 0m1.248s
Crearea unui index se face : ALTER TABLE tabela ADD INDEX gigi (luna,zi,ora,minut) ; si durează câteva secunde. După crearea indexului rulând aceeaşi comanda vine surpriza :
root@tfm64: 2# time mysql N < test.sql
real 0m12.516s
user 0m1.140s
sys 0m0.608s
Are cineva nevoie de 55 de minute ?
intrebare stupida: nu era mai simplu daca foloseai un singur camp de tip datetime sau timpestamp in loc de cele 5 campuri: “an”, “luna”, “zi”, “ora”, minut”?
Pentru acest caz particular da. ar fi fost mai simplu. Insă daca in loc de an, luna, zi, ora, minut ai avea oras, locatie, etaj, camera, device ce faci ? Il codezi într-o structura gen timestamp sau foloseşti index-uri ? Puteam sa pun in exemplu field1 , field2, field3 dar mi s-a părut mai intuitiv sa folosesc pentru exemplu ora,minut,zi,an,luna
oh, am inteles, poate nu a fost cel mai bun exemplu atunci 🙂
mi-a sarit in “ochi” ca ai toate campurile alea de tip int in loc de unul singur cu un tip mai apropiat pentru a reprezenta o data.
si, de ce sa pui oras (varchar) / etaj (int) … sub forma de timestamp?
Comments are closed.