☰

» »

MySQL types

MySQL types

FuI2cY ::

Pozdravljeni,

zanima me nekaj (bom dal večjo primerjavo), ali vpliva kaj na hitrost ali karkoli, če za primarni ključ namest tinyint (ker bi imel manj kot 256 podatkov) izberem bigint? To je samo primer, ker me zanima, če kaj to vpliva če se ne izbere primerni tip?

Hvala.

korenje3 ::

predlagam da daš guid za primary key in uporabljaš VARCHAR(50) primary key, za vsako vrstico v tabeli. v programu pa MySqlDbType.Guid, ker primary key je unikaten za vsako vrstico in se ne more podvajat.
i9-12900k; 32GB DDR5-6000 CL36; Nvidia RTX 3080 ti;
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W

Zgodovina sprememb…

  • spremenil: korenje3 ()

FuI2cY ::

mislim, da bom kar pustil nek integer za primary key pa lepo ai. sam bolj me zanima kk to v odzadju deluje če daš neki bigint

korenje3 ::

Po moje sam več prostora porabi. 

Data Type	Storage Required
TINYINT	1 byte
SMALLINT	2 bytes
MEDIUMINT	3 bytes
INT, INTEGER	4 bytes
BIGINT	8 bytes
FLOAT(p)	4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
FLOAT	4 bytes
DOUBLE [PRECISION], REAL	8 bytes
DECIMAL(M,D), NUMERIC(M,D)	Varies; see following discussion
BIT(M)	approximately (M+7)/8 bytes
i9-12900k; 32GB DDR5-6000 CL36; Nvidia RTX 3080 ti;
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W

technolog ::

Korenje nabija.

Obstajajo sicer legitimni primeri, ko je niz primeren primarni ključ, ampak je to dokaj redko. Ampak v splošnem je to slaba ideja.

Uporabi kar število, velikost izberi pa tako, da ti ne bo treba nikoli povečevati. Recimo za število poslovalnic nekega podjetja bo TINYINT čez glavo, medtem ko ti v kakih drugih primerih uspe celo INT zmanjkati.

Apple ::

FuI2cY je izjavil:

Pozdravljeni,

zanima me nekaj (bom dal večjo primerjavo), ali vpliva kaj na hitrost ali karkoli, če za primarni ključ namest tinyint (ker bi imel manj kot 256 podatkov) izberem bigint? To je samo primer, ker me zanima, če kaj to vpliva če se ne izbere primerni tip?

Hvala.


Za hitrost postavi prava polja v indeks...
LP, Apple

FuI2cY ::

Super, glede hitrosti že imam nastavljene indexe...

nekaj me še zanima: če iščem npr 5 atributov (vrednosti iz 5 različnih stolpcev) je boljše, da imaš na vsak stolpec posebej index ali da jih grupiraš teh pet skupaj pod en index ?

korenje3 ::

si indexe zamešal z nečem?
i9-12900k; 32GB DDR5-6000 CL36; Nvidia RTX 3080 ti;
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W

Apple ::

Bolje je, da imaš polja, na katere se sklicuješ v WHERE stavku, v enem indexu.

In tam, kjer imaš enačaje v WHERE stavku daj le-te pred predikati z morebitnimi "večje" ali "manjše".

V index daš tista polja, kjer imaš boljši filter faktor...

Lahko pa probaš dati vsa polja v index...
LP, Apple

drola ::

Apple je izjavil:

In tam, kjer imaš enačaje v WHERE stavku daj le-te pred predikati z morebitnimi "večje" ali "manjše".

A ne naredi tovrstnih optimizacij že sama SQL implementacija?

nekaj me še zanima: če iščem npr 5 atributov (vrednosti iz 5 različnih stolpcev) je boljše, da imaš na vsak stolpec posebej index ali da jih grupiraš teh pet skupaj pod en index ?

Kot že omenjeno, indexi so pomembni za sortiranje (ORDER BY) in filtriranje (WHERE/JOIN...ON) vrstic.

Koliko polj dati v index? Glede tega ni enoznačnega odgovora. Indeks, ki zaobjema pet različnih stolpcev, se ti splača samo v primeru, da zelo pogosto poganjaš poizvedbo, ki ima v WHERE ali JOIN stavku teh pet stolpcev omenjenih. Sicer se ti bolj splača imeti poindeksirane posamezne stolpce, po katerih se pogosto filtrira. Namreč če imaš index (a,b,c,d,e) in poženeš poizvedbo oblike SELECT ... FROM ... WHERE a=1 and b=2 and c=3 and d = 4, se tak indeks za izvedbo te poizvedbe sploh ne uporabi, ker morajo nastopati pogoji za vse stolpce iz indeksa (to je podatek za Firebird, morda je pri drugih implementacijah drugače). Poleg tega tak indeks pride tudi s svojo ceno pri INSERT in UPDATE stavkih, ker se mora indeks osvežiti, če spremeniš kateregakoli izmed petih stolpcev. Torej splošen nasvet bi bil, da naj ne bo v posameznem indeksu več kot en stolpec, razen v primerih, ko pogosto uporabljaš pogoj s kombinacijo stolpcev. Tak primer bi bila tabela s stolpci id_firme | ime_zaposlenega | telefonska, v aplikaciji pa lahko uporabniki iščejo je telefonske od svojih sodelavcev, kar pomeni da se tipično poganja poizvedba z WHERE id_firme=123 AND ime_zaposlenega="Miki".
https://drola.si

FuI2cY ::

drola je izjavil:

Apple je izjavil:

In tam, kjer imaš enačaje v WHERE stavku daj le-te pred predikati z morebitnimi "večje" ali "manjše".

A ne naredi tovrstnih optimizacij že sama SQL implementacija?

nekaj me še zanima: če iščem npr 5 atributov (vrednosti iz 5 različnih stolpcev) je boljše, da imaš na vsak stolpec posebej index ali da jih grupiraš teh pet skupaj pod en index ?

Kot že omenjeno, indexi so pomembni za sortiranje (ORDER BY) in filtriranje (WHERE/JOIN...ON) vrstic.

Koliko polj dati v index? Glede tega ni enoznačnega odgovora. Indeks, ki zaobjema pet različnih stolpcev, se ti splača samo v primeru, da zelo pogosto poganjaš poizvedbo, ki ima v WHERE ali JOIN stavku teh pet stolpcev omenjenih. Sicer se ti bolj splača imeti poindeksirane posamezne stolpce, po katerih se pogosto filtrira. Namreč če imaš index (a,b,c,d,e) in poženeš poizvedbo oblike SELECT ... FROM ... WHERE a=1 and b=2 and c=3 and d = 4, se tak indeks za izvedbo te poizvedbe sploh ne uporabi, ker morajo nastopati pogoji za vse stolpce iz indeksa (to je podatek za Firebird, morda je pri drugih implementacijah drugače). Poleg tega tak indeks pride tudi s svojo ceno pri INSERT in UPDATE stavkih, ker se mora indeks osvežiti, če spremeniš kateregakoli izmed petih stolpcev. Torej splošen nasvet bi bil, da naj ne bo v posameznem indeksu več kot en stolpec, razen v primerih, ko pogosto uporabljaš pogoj s kombinacijo stolpcev. Tak primer bi bila tabela s stolpci id_firme | ime_zaposlenega | telefonska, v aplikaciji pa lahko uporabniki iščejo je telefonske od svojih sodelavcev, kar pomeni da se tipično poganja poizvedba z WHERE id_firme=123 AND ime_zaposlenega="Miki".


Super razlozeno. Hvala ti! Za moje primere bom jaz kar raje dal več polj v index, ker se bo izvajalo več 100.000 poizvedb na dan. Ker v dosti primerih se bo uporabljajo kot si napisal "ker morajo nastopati pogoji za vse stolpce iz indeksa". V primerih kjer so lahko poizvedve različne pa bom uporabil posamezno indeksiranje.

Hvala ti!

usoban ::

korenje3 je izjavil:

in uporabljaš VARCHAR(50) primary key


to je totalno narobe. cifre se da primerjati z enim ukazom, medtem ko za niz rabis n (=dolzina niza) primerjav

korenje3 ::

usoban je izjavil:

korenje3 je izjavil:

in uporabljaš VARCHAR(50) primary key


to je totalno narobe. cifre se da primerjati z enim ukazom, medtem ko za niz rabis n (=dolzina niza) primerjav


predvidevam da imaš prav. verjetno mora za vsak znak od guida preverit če je match medtem ko za številko ne.
i9-12900k; 32GB DDR5-6000 CL36; Nvidia RTX 3080 ti;
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W

korenje3 ::

http://kccoder.com/mysql/uuid-vs-int-in...

če nimaš več kot 1 milijon zapisov je izgleda čisto vseeno.
i9-12900k; 32GB DDR5-6000 CL36; Nvidia RTX 3080 ti;
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W

Zgodovina sprememb…

  • spremenil: korenje3 ()

FuI2cY ::

zapisov je drugače več 10miljonov. Hvala vsem za pomoč. Sem prišel do želenega odgovora.

technolog ::

korenje3 je izjavil:

http://kccoder.com/mysql/uuid-vs-int-in...

če nimaš več kot 1 milijon zapisov je izgleda čisto vseeno.


Pojma nimaš, o čem sploh govorimo.

Zgodovina sprememb…

korenje3 ::

technolog je izjavil:

korenje3 je izjavil:

http://kccoder.com/mysql/uuid-vs-int-in...

če nimaš več kot 1 milijon zapisov je izgleda čisto vseeno.


Pojma nimaš, o čem sploh govorimo.


vem o čem govorimo, samo jaz nisem odgovarjal tebi tako da ne vem kaj se oglašaš.
i9-12900k; 32GB DDR5-6000 CL36; Nvidia RTX 3080 ti;
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

SQL pomoč

Oddelek: Programiranje		132371 (1785) miko22
»

Program za uvoz velike količine podatkov

Oddelek: Programska oprema		61126 (931) brodul
»

MySql Vprasanje - problem dupliciranih kljucev

Oddelek: Izdelava spletišč		131424 (1246) KernelPanic
»

mysql vnos

Oddelek: Izdelava spletišč		51542 (1507) asgard2.0
»

portal ostal, baza sla

Oddelek: Izdelava spletišč		61824 (1709) bombacina

Več podobnih tem