VNC stopt er mee :(
Index naam
$query= "CREATE INDEX index_naam ON tabel (veld)";
Nu vraag ik mij alleen af wat de index_naam precies inhoudt. Ik kan er nergens wat over vinden, maar kan ik gewoon dezelfde naam als het veld gebruiken? Of moet het over de gehele database een unieke naam zijn? Wat is het nut er precies van?
Bedankt!
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/create-index.html
En ik neem aan dat je niet de zelfde kolom naam kunt gebruiken als index naam; Want dan zal die waarschijnlijk niet weten of je de index of de kolom bedoeld. Maarja, kom je achter door te proberen neem ik aan? ;)
1keydata.com 08/08/2011:
There is no strict rule on how to name an index. The generally accepted method is to place a prefix, such as "IDX_", before an index name to avoid confusion with other database objects. It is also a good idea to provide information on which table and column(s) the index is used on.
Toevoeging op 08/08/2011 16:41:49:
Maar wat wordt er eigenlijk precies mee gedaan? Is het gewoon zinloos of moet je er goed over nadenken en later gebruiken ofzo?
Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
- Indexen is niet bedoeld om queries te optimaliseren, het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;
Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);
Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)
Hier een tut. erover:
Klik hiero
Gewijzigd op 08/08/2011 17:14:23 door Benny Lava
Benny Lava op 08/08/2011 17:02:46:
Ik heb zelf nooit echt indexing nodig gehad, maar even de voor/nadelen. Te beginnen met de nadelen omdat die iets makkelijker zijn op te noemen.
Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
- Indexen is niet bedoeld om queries te optimaliseren, het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;
Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);
Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)
Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
- Indexen is niet bedoeld om queries te optimaliseren, het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;
Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);
Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)
WTF?! Volgens mij heb jij niet met grotere en genormaliseerde databases gewerkt. Bij tabellen van meer dan 1000 records beginnen indices enorme performance winsten te geven. Ook je nadelen vind ik niet helemaal kloppen:
Extra inhoudt; Dit had je beter kunnen omschrijven als: "Meer (schijf)ruimte die gebruikt wordt voor het bijhouden van de index. Echter is dat meestal niet het ergste maar vooral hoe meer indexen je hebt des te trager je inserts en updates worden omdat stukken van je index dan aangepast moeten worden.
Een index is JUIST bedoeld om queries te optimaliseren. Een index afhankelijk van het type kan enorme performance winsten opleveren bij het gebruik op WHERE condities maar ook als je tabellen joint gaat het matchen van velden sneller.
Het is nuttig bij queries waar elke vorm van vergelijking optreedt. Echter dient men af te wegen om wat voor performance winst het gaat en wat een eventuele extra index aan performance kost voor mutaties.
Benny Lava op 08/08/2011 14:56:31:
Hier zijn links waar je meer info uit kunt halen:
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/create-index.html
En ik neem aan dat je niet de zelfde kolom naam kunt gebruiken als index naam; Want dan zal die waarschijnlijk niet weten of je de index of de kolom bedoeld. Maarja, kom je achter door te proberen neem ik aan? ;)
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/create-index.html
En ik neem aan dat je niet de zelfde kolom naam kunt gebruiken als index naam; Want dan zal die waarschijnlijk niet weten of je de index of de kolom bedoeld. Maarja, kom je achter door te proberen neem ik aan? ;)
Kan gewoon hoor?
Jordy nvt op 08/08/2011 19:40:01:
Ok, en als laatste. Wat kun je beter doen. Telkens een nieuwe index creëren op een kolom en deze een leuke naam geven of één naam geven per tabel en daaronder meerdere tabellen stoppen. Wat is precies het verschil of maakt dat ook niet uit?
Je zinsloop klopt niet helemaal maar ik veronderstel dat je vraag is of een index wilt met een kolom of een index met meerdere kolommen. Dit hangt ervan af:
Stel je hebt de volgende query:
Code (php)
1
SELECT * FROM users WHERE username LIKE "ke%" AND insertdate > NOW() - INTERVAL 2 MONTH
In bovenstaand geval doe je een vergelijking op 2 velden. Specifiek voor deze query loont het zich om een index te maken op 2 velden als volgt dus:
Code (php)
1
ADD INDEX somename ON users (username, insertdate)
Echter in het volgende geval:
Code (php)
1
SELECT * FROM users WHERE username LIKE "ke%"
Loont het zich meer de moeite om:
Code (php)
1
ADD INDEX somename ON users (username)
Te doen.
Om te bepalen wat je het beste kunt doen is te kijken naar wat voor queries je afvuurt op de betreffende tabel. Bij deze queries analyseer je welke velden het meest gebruikt worden bij het maken van matches en wat de kardinaliteit is, hoe hoger deze is des te meer ruimte de index in beslag zijn nemen en de insert en updates trager zullen worden. Tevens hangt het er ook vanaf hoe belangrijk de performance van je insert's en updates is.
Er is dus niet echt zo te zeggen wat je het beste kunt doen. Dit kun je dus het beste bepalen door goed te kijken wat voor queries er gebruikt worden en wat de grote is van tabellen. Bij foreign keys moeten er altijd indexen gelegd worden. Daarom zijn MySQL databases met hogere integriteit altijd wat zwaarder.
In dit artikel ga ik ook nog wat verder in op performance en het gebruik van indexes.
Gewijzigd op 08/08/2011 19:51:43 door kees Schepers
In sommige gevallen is het noodzakelijk of 'best approach' om je een klein stukje van je database te denormaliseren voor performance winst. Ik heb weleens zo'n situatie gehad waarbij een order een many-to-many relatie had, dus je had de tabellen order, order_to_statustype en statustype. Om de laatste status op te vragen moest ik dus elke keer een subquery doen met een MAX op de insertdate.
Dit ging goed tot een paar honderd duizend records maar door de indexen groeide de tabel erg hard en werd het steeds langzamer. De beste oplossing was op een gegeven moment op de tabel order_to_statustype een trigger (after) toe te voegen op insert en delete die na het toevoegen van een status de laatste statusid koppelde aan de order tabel in een veld order.orderlaststatusid. Hierdoor kon ik rechtstreeks een join schrijven zonder subqueries.
Ik hoop dat je het een beetje snapt en dat het voor je wat toevoegt in het kader van performance overwegingen.
Benny Lava op 08/08/2011 17:02:46:
Ik heb zelf nooit echt indexing nodig gehad, maar even de voor/nadelen. Te beginnen met de nadelen omdat die iets makkelijker zijn op te noemen.
Nog nooit? Heb je nog nooit een primary key of een unique constraint in een database gebruikt? Dan heb je eigenlijk nog nooit iets met een database gedaan en hebben jouw opmerkingen vrij weinig waarde.
Het feit dat je niet weet dat een primary key en unique constraint in MySQL een index aanmaken, zegt eigenlijk ook al dat je er niets vanaf weet.
Quote:
Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
Over welk onderhoud heb je het dan? Die ene microseconde om een index bij te werken? Lijkt mij niet zo spannend.
Quote:
- Indexen is niet bedoeld om queries te optimaliseren,
Hoe zeg je? Een index zal een query inderdaad niet optimaliseren, het uitvoeren van een query kan dankzij een index wel enorm worden geoptimaliseerd. Een query die geen index kan gebruiken, zal altijd een sequential scan uitvoeren en dus altijd de hele tabel moeten uitlezen. Met grote tabel kost dat dus een eeuwigheid. Een indexscan kan met kleine hoeveelheden data uit een hele grote tabel nog steeds binnen enkele microseconden plaatsvinden.
Quote:
het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;
Je hebt hier echt geen idee waar je het over hebt, je kraamt hier onzin uit. Een query wordt nooit onoverzichtelijker omdat er toevallig indexen in een database aanwezig zijn. En wat documentatie er mee te maken heeft, geen idee.
Quote:
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;
En wat dacht je van sorteren? Of een JOIN? Of een GROUP BY? Een query waarbij je alle gegevens in een tabel opvraagt, komt vrijwel nooit voor en dus heb je er vrijwel nooit baat bij om geen indexen te gebruiken. Waar haal je deze onzin toch vandaan?
Quote:
Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
Nog mee onzin... Waarom zou de database naar een kolom moeten zoeken? Die geef jij al op in jouw query, heeft niets met een index te maken. Een index gebruik je om snel records te vinden.
Quote:
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);
Sorry, maar ook hier begrijp ik helemaal niets van. Waarom zou een index handig zijn voor een DBA? Een index is er voor de database, voor de betere performance.
Quote:
Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)
Je hebt geen enkel idee wat een DBMS is en wat een DBMS zou moeten doen en hoe deze intern werkt. Je hebt echt geen flauw benul. Niemand is perfect, maar accepteer ook van jezelf dat je niet alles weet en ook niet over alles mee hoeft te praten.
Tip: Verwijder bovenstaande onzin, dan sta je iets minder voor gek.
Ps. Sorry als het wat bot is, het is niet persoonlijk bedoelt en ik hoop dat je er nog iets van leert.