database optimalisatie
Stel, ik heb 2 tabellen, eentje waarin orders staan en eentje (een koppeltabel) waarin de producten staan die bij een order horen.
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?)
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?)
Stel eerst de vraag heb je een probleem met je query?
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. ;)
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. ;)
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. Vandaar dat ik nu dus al begin :)
Maar er zit dus een primary key op order_id, volgens mij is een primary key een index?
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.
Dan refereer ik even naar deze post http://www.phphulp.nl/php/forum/topic/databasetabel-omvang-wat-is-een-grote-databasetabel/75198/ waarin onder andere het volgende wordt gezegd. Klopt dat dan niet?
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 is een groot begrip.
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 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? ;)
@Bart V B
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.
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.
Hmmm... oke, deze meningen staan dus ljinrecht tegenover elkaar. Iemand anders die duidelijkheid kan verschaffen?
@Aad, ik ben het wel met je eens dat je al veel kunt voorkomen, maar zoals ik de vraag van de TS lees, is hij aan het zoeken naar iets wat niet nodig is.
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.
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.
Zoeken naar een uniek id die ook nog is geindexeerd is niet meer te versnellen. Heel misschien is de wijze van indexeren nog van belang, als je kunt kiezen tenminste. Als de key een string is, en geen integer, is het vooral zinvol even de manier van indexeren kritisch te bekijken. Geef evt. even aan welke database en wat voor veld je gebruikt.
Gewijzigd op 27/12/2010 14:46:48 door F Loogman
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)
Gewijzigd op 27/12/2010 14:57:23 door Ozzie PHP
@Bart: geheel mee eens en de opmerking hier van 27/12/2010 11:43:29 heeft Ozzie eigenlijk uit een andere topic meegenomen en die ging in bredere zin over optimaliseren.
Toevoeging op 27/12/2010 15:15:56:
@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.
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.
oke, thanks!




