Forum » Programiranje » 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.
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
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
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.
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 ::
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 ?
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
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...
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 ::
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 ::
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 ::
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
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.
č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
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W
Zgodovina sprememb…
- spremenil: korenje3 ()
technolog ::
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…
- spremenil: technolog ()
korenje3 ::
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
Gigabyte Aorus z690 master; Be Quiet Dark Power 12 1000W
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | SQL pomočOddelek: Programiranje | 2370 (1784) | miko22 |
» | Program za uvoz velike količine podatkovOddelek: Programska oprema | 1125 (930) | brodul |
» | MySql Vprasanje - problem dupliciranih kljucevOddelek: Izdelava spletišč | 1423 (1245) | KernelPanic |
» | mysql vnosOddelek: Izdelava spletišč | 1541 (1506) | asgard2.0 |
» | portal ostal, baza slaOddelek: Izdelava spletišč | 1823 (1708) | bombacina |