[MySQL] Voordeel van Column Type

[Bender]

Wat ik me afvroeg..
Bij een Column Type,
heeft het echt voordelen om 'MEDIUMINT' ipv 'INT' te gebruiken?
Ik weet wat het kan en de beperkingen zijn..
Maar ik vroeg me af, zoekt het sneller, laad het sneller of is er een andere reden om bijv 'MEDIUMINT' boven 'INT' te kiezen?

(in de faq staat zoiets niet , en in de search vond niks hierover)

[Verwijderd]

geheugen

[Bender]

Verwijderd schreef op 02 januari 2003 @ 23:06:
geheugen

Ook alstie niet helemaal opgevuld is?
Of laat ie standaard het maximale in wat er in kan komen te staan (wat overigens best slecht zou zijn, dus lijkt me sterk)

Leg anders even uit

[Verwijderd]

code:

Type      Bytes
TINYINT   1
SMALLINT  2
MEDIUMINT 3
INT       4
BIGINT    8

BIGINT gebruikt meer geheugen, maar heeft dan ook een groter bereik. Zo simpel is het. BIGINT gebruikt dus ALTIJD 8 bytes, ook als je het getalletje '4' als een BIGINT opslaat. Idem ditto voor de andere types.

http://www.mysql.com/doc/en/Numeric_types.html

[ Voor 21% gewijzigd door Verwijderd op 02-01-2003 23:12 ]

[chem]

daarbij is een bigint 8*8=64 bytes, maw 2x zo groot als een normale 32 bits integer, wat dus een groter getal kan opleveren dan de CPU normaal verwerkt. (en nee, een 64 bits processor heeft geen winst bij een bigint tov een int)

[Verwijderd]

vergelijk ook de varchar en nvarchar datatypes.... met char en nchar.

[Verwijderd]

Verwijderd schreef op 02 januari 2003 @ 23:16:
vergelijk ook de varchar en nvarchar datatypes.... met char en nchar.

of als je over bereik spreekt: de unsigned tov. de signed numeric data types

[Verwijderd]

Geheugen- maar ook diskruimte. Zeker bij gratis of goedkope hosting is de diskruimte voor je MySQL database vaak erg beperkt. Het verschil in ruimte dat een integer datatype kan nemen is dus 8-voudig, dus met veel records kan de keuze voor een onnodig groot datatype tot een groot probleem leiden.

[Femme]

Op een grote tabel van een paar miljoen rows en vooral getallen kan behoorlijk veel bespaard worden door de column types te optimaliseren. Het scheelt niet alleen harddiskruimte maar maakt ook een efficiënter gebruik van de buffergeheugens mogelijk.

[drm]

Wederom een geval van "know your data", dus.

[ACM]

Het grappige is dat bij postgresql het gebruik van de gewone integer ipv de smallint (16 bits ipv 32 bits dus) de eerste een stuk sneller schijnt/scheen te zijn in gebruik.
Hoe dit bij mysql is weet ik niet, het is sowieso wel redelijk snel.

Maar het scheelt sowieso opslagruimte.

Ook alstie niet helemaal opgevuld is?
Of laat ie standaard het maximale in wat er in kan komen te staan (wat overigens best slecht zou zijn, dus lijkt me sterk)

Leg anders even uit

Een getal is altijd even groot kwa opslag, tenminste zolang we het over een getal van hetzelfde type hebben.
Een 16-bits integer neemt altijd 16 bits in, of ie nou 0 of 65535 is. Bij varchar is dat anders, daar wordt de grootte bepaald aan de hand van de hoeveelheid tekens in de string.

Let er trouwens ook op dat de getalletjes tussen haakjes achter de int's geen effect hebben een int(1) is gewoon hetzelfde als een int(10) en zal dus geen ruimte besparen of korter opgeslagen kunnen worden.

[marty]

en maak 'm unsigned als je er zeker van bent geen negatieve waardes te krijgen. dan wordt je bereik nog eens 2x zo groot (in die zin dat je positieve waarde 2x zo groot kan worden)

(toch?)

[drm]

Dat klopt, ja.