Ik ben bezig met het maken van een tabel en ik vroeg me af.
Als ik bijvoorbeeld auto’s met een merk opsla (bijv. BMW, Audi enz.), maakt het dan enig verschil voor de vraagsnelheid als ik het merk opsla als een int of varchar.
Zo is het
SELECT * FROM table WHERE make = 5 AND ...;
Sneller/langzamer dan
SELECT * FROM table WHERE make = 'audi' AND ...;
of zal de snelheid min of meer hetzelfde zijn?
Antwoord 1, autoriteit 100%
Int-vergelijkingen zijn sneller dan varchar-vergelijkingen, vanwege het simpele feit dat ints veel minder ruimte innemen dan varchars.
Dit geldt zowel voor niet-geïndexeerde als voor geïndexeerde toegang. De snelste manier om te gaan is een geïndexeerde int-kolom.
Zoals ik zie dat je de vraag postgreql hebt getagd, ben je misschien geïnteresseerd in het ruimtegebruik van verschillende datumtypes:
intvelden beslaan tussen 2 en 8 bytes, waarbij 4 meestal meer dan genoeg is ( -2147483648 tot +2147483647 )- tekentypen nemen 4 bytes plus de daadwerkelijke tekenreeksen in beslag.
Antwoord 2, autoriteit 42%
Enkele ruwe benchmarks:
4 miljoen records in Postgres 9.x
Table A = base table with some columns
Table B = Table A + extra column id of type bigint with random numbers
Table C = Table A + extra column id of type text with random 16-char ASCII strings
Resultaten op 8 GB RAM, i7, SSD-laptop:
Size on disk: A=261MB B=292MB C=322MB
Non-indexed by id: select count(*), select by id: 450ms same on all tables
Insert* one row per TX: B=9ms/record C=9ms/record
Bulk insert* in single TX: B=140usec/record C=180usec/record
Indexed by id, select by id: B=about 200us C=about 200us
* inserts to the table already containing 4M records
het lijkt er dus op dat voor deze opstelling, zolang je indexen in het RAM passen, bigint vs 16-char tekst geen verschil maakt in snelheid.
Antwoord 3, autoriteit 17%
Het zal een beetje sneller zijn om een int te gebruiken in plaats van een varchar. Belangrijker voor snelheid is om een index op het veld te hebben die de query kan gebruiken om de records te vinden.
Er is nog een reden om een int te gebruiken, en dat is om de database te normaliseren. In plaats van de tekst ‘Mercedes-Benz’ duizenden keren in de tabel op te slaan, moet u de id en de merknaam één keer in een aparte tabel opslaan.
Antwoord 4, autoriteit 7%
Uitsplitsing naar de daadwerkelijke prestatie van stringvergelijking versus niet-floats, in dit geval doet elke grootte zonder teken en ondertekend er niet toe. Grootte is eigenlijk het echte verschil in prestaties. Of het nu gaat om 1byte+(tot 126bytes) versus 1,2,4 of 8 byte vergelijking… uiteraard zijn non-float kleiner dan strings en floats, en dus CPU-vriendelijker bij het samenstellen.
Snaar-naar-tekenreeks vergelijking in alletalen is langzamer dan iets dat door de CPU in 1 instructie kan worden vergeleken. Zelfs het vergelijken van 8 byte (64bit) op een 32bit CPU is nog steeds sneller dan een VARCHAR(2) of groter. * Nogmaals, kijk naar de geproduceerde assembly (zelfs met de hand) er zijn meer instructies nodig om char voor char te vergelijken dan 1 tot 8 byte CPU-numeriek.
Hoeveel sneller? hangt ook af van de hoeveelheid gegevens. Als je gewoon 5 vergelijkt met ‘audi’ – en dat is alles wat je DB heeft, is het resulterende verschil zo minimaal dat je het nooit zou zien. Afhankelijk van de CPU, implementatie (client/server, web/script, enz.) zult u het waarschijnlijk pas zien als u een paar honderd vergelijkingen op de DB-server hebt gemaakt (misschien zelfs een paar duizend vergelijkingen voordat het merkbaar is).
- om het onjuiste geschil over hash-vergelijkingen ongeldig te maken. De meeste hashing-algoritmen zelf zijn traag, dus je profiteert niet van dingen zoals CRC64 en kleiner. Al meer dan 12 jaar ontwikkelde ik zoekalgoritmen voor multi-county zoekmachines en 7 jaar voor de kredietbureaus. Alles wat u kunt houden in numeriek de snellere … bijvoorbeeld telefoonnummers, postcodes, zelfs valuta * 1000 (opslag) valuta DIV 1000 (ophalen) is sneller dan decimaal voor vergelijkingen.
Ozz
5, Autoriteit 6%
Index of niet, int is een stuk sneller (hoe langer de varchar, het langzamer het wordt).
Nog een reden: index op VARCHAR-veld is veel groter dan op int. Voor grotere tabellen kan het honderden megabytes (en duizenden pagina’s) betekenen. Dat maakt de uitvoering veel slechter omdat het lezen van de index alleen vereist dat veel schijf wordt gelezen.
6, Autoriteit 5%
Over het algemeen zal de int sneller zijn. Hoe langer is de varchar het langzamer dat het krijgt
7
enigszins relatief.
Ja, Ints zal sneller zijn, maar de vraag is of het in uw situatie merkbaar is.
Zijn de varchars slechts enkele kleine woorden, of langere teksten? en hoeveel rijen zitten er in de tafel? Als er maar een paar rijen zijn, zal het hoogstwaarschijnlijk volledig gebufferd zijn in het geheugen (indien vaak gevraagd), in dat geval zal u niet veel verschil opmerken. Toen is er natuurlijk indexering, wat belangrijker wordt wanneer de tabel groeit. Het gebruik van SSD’s kan sneller zijn en HD’s met geoptimaliseerde query’s. Ook goede schijfcontrollers versnellen soms query’s en gt; 10x. Dit kan ruimte laten voor alleen gebruik van varchars die het lezen en schrijven van vragen gemakkelijker (niet nodig om complexe voegsel te schrijven) en de ontwikkeling versnellen.
Puristen zullen echter het niet eens zijn en normaliseren altijd alles.