database optimalisatie
In de koppeltabel heeft iedere regel een order_id die ik heb ingesteld als primary key. Als ik nu in de koppeltabel de producten van een order zoek dan gebruik ik een SELECT query waarbij ik zeg "WHERE order_id = <hier het nummer van de order_id>". Ik zoek altijd op order_id. Kan ik nog iets doen om de SELECT query te versnellen, of is een primary key op order_id voldoende?
(Weet iemand toevallig een goede Nederlandse tutorial voor database optimalisatie?)
Als dat zo is, dan ga je kijken met EXPLAIN waar het traag is.
Heb je trouwens ook ergens nog een index op geplaatst?
Ga zeker niet proberen te optimaliseren als er geen probleem is, dat gaat niet werken. ;)
Maar er zit dus een primary key op order_id, volgens mij is een primary key een index?
Ozzie PHP op 27/12/2010 11:23:33:
Nee, ik heb geen probleem met mijn query maar van anderen op het forum hoor ik juist dat je meteen moet gaan optimaliseren en niet pas naderhand.
Iedere professional, iedere leraar, ieder verstandig mens zal dat tegenspreken.
Quote:
Maar er zit dus een primary key op order_id, volgens mij is een primary key een index?
Jep.
Aad B op 23/12/2010 20:35:06:
Ozzie PHP op 23/12/2010 16:26:07:
Optimalisatie moet je meteen toepassen, indexen op alle keys en foreign keys en overige columns waarop gezocht en/of gejoined wordt. Tuning technisch gezien: je moet zorgen dat je geen full table scans op je tabellen hebt. Dus altijd index-unique-scans of index-range scans. Performance problemen achteraf oplossen kost veel energie en zoekwerk en er is dan al irritatie bij gebruikers. Bovenstaande regels staan geheel los van het feit of de database "groot" of "klein" is. Zoals eerder gesteld: dat groot of klein is een relatief begrip. Niet over nadenken dus.Wanneer kun je een databasetabel eigenlijk echt "groot" noemen, dusdanig dat je database optimalisatie (indexen) moet gaan toepassen?
Jelmer rrrr op 27/12/2010 11:25:49:
Iedere professional, iedere leraar, ieder verstandig mens zal dat tegenspreken.
@Jelmerrrr
Moet je nou wel of niet meteen optimaliseren ?
Ozzie PHP op 27/12/2010 11:23:33:
Nee, ik heb geen probleem met mijn query maar van anderen op het forum hoor ik juist dat je meteen moet gaan optimaliseren en niet pas naderhand.
Iedere professional, iedere leraar, ieder verstandig mens zal dat tegenspreken.
@Jelmerrrr
Moet je nou wel of niet meteen optimaliseren ?
Optimaliseren begint al met een goed datamodel.
Als dat aanwezig is, en je hebt een trage query, ga je kijken waarom hij traag is.
Dat doe je met EXPLAIN. Kijk eens in de handleiding daarvoor.
Ik bedoel, als je auto rijd en hij haalt de maximale snelheid, ga je dan ook proberen met een mesje het tapijt bewerken zodat de gaspendaal dieper ingedrukt kan worden omdat hij dan misschien evt. nog sneller kan? ;)
Optimaliseren doe je meteen en optimaliseren heeft niets met een goed datamodel te maken. Datamodelleren doe je eerst en meestal ga je naar de 3e normaalvorm. Optimaliseren doe je tijdens je toegangspad analyse: Hoe worden de tabellen bevraagd (query's). Primary keys zijn meteen index, foreign keys indexeer je ook meteen. Tenslotte komen de indexen aan de beurt op attributen die vaak in WHERE clausules voor zouden kunnen komen. Dit alles doe je in je ontwerpfase, je bent nog helemaal geen query's aan het krassen. Je moet voorkomen dat je bij performance problemen aan de slag moet met EXPLAIN. Het spreekwoordelijke kalf is dan al aan het verzuipen.
Quote:
Ik zoek altijd op order_id. Kan ik nog iets doen om de SELECT query te versnellen, of is een primary key op order_id voldoende?
Dus wat hij wil is iets gaan optimaliseren wat al goed is.
Vandaar dat ik vroeg, is de query dan traag?
En dat geeft de TS aan dat dat niet het geval is.
Wat is er dan nog te optimaliseren.
Ben zelf echt geen Rock 'n SQL-er maar mij lijkt als iets al goed is dan ga je geen werk op je nek halen wat alleen maar tijd weggooien is.
Gewijzigd op 27/12/2010 14:46:48 door F Loogman
(er is dus geen primary key)
Gewijzigd op 27/12/2010 14:57:23 door Ozzie PHP
Toevoeging op 27/12/2010 15:15:56:
Ozzie PHP op 27/12/2010 14:56:59:
Ik zoek op order_id en die heb ik nu ingesteld als INDEX (niet als primary key omdat aan een order meerdere producten gekoppeld kunnen zijn en de order_id dus meerdere keren kan voorkomen). order_id heb ik ingesteld als een INT van 8 cijfers.
(er is dus geen primary key)
(er is dus geen primary key)
@Ozzie: is een prima oplossing en of je het nu primary key of index noemt, het verschilt niet zo heel veel. Een gewone index kan inderdaad meerdere keren hetzelfde veld bevatten, zoals jouw order_id en dat is goed.