[MySQL] Meerdere indexen op 1 kolom traag?

[urk_forever]

Hallo allemaal,

Ik ben een applicatie aan het onderhouden die iemand anders geschreven heeft. Nu kwam ik op een tabel deze constructie tegen:

SQL:

DROP TABLE IF EXISTS `eentabel`;
CREATE TABLE `eentabel` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `remark` varchar(255) default NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `id` (`id`),
  KEY `id_2` (`id`)
) TYPE=MyISAM;

Maar al die keys die gedefineerd zijn komen volgens mij op hetzelfde neer! Volgens de documentatie van mysql is een Primary Key een unieke index die niet null kan zijn.
Dus volgens mij als je het veld id als primary key defineert dan is het ook uniek en een index. Dan hoef je hem toch niet nog een keer als unique te definieren en nog een keer als index? Klopt deze denkwijze?

Ik kom dit op meerdere tabellen tegen en het vertraagd heel veel bij sommige delete statements. Kan dat ook van meerdere (dezelfde) indexen op 1 kolom komen?

[ Voor 5% gewijzigd door urk_forever op 28-08-2007 11:15 ]

[ACM]

urk_forever schreef op dinsdag 28 augustus 2007 @ 11:14:
Dus volgens mij als je het veld id als primary key defineert dan is het ook uniek en een index. Dan hoef je hem toch niet nog een keer als unique te definieren en nog een keer als index? Klopt deze denkwijze?

Dat klopt.

In MySQL (en alle anderen die ik ken) wordt een primary key geimplementeerd door een unique index op dat veld, of de combinatie van velden, te leggen en aan te vullen met de clausule dat een waarde niet null mag zijn. Een primary key is daardoor in de praktijk iets strenger dan een unique key en een unique key is weer strenger dan een normale index/key. Dus als je een primary key hebt is het zinloos om precies dezelfde unique aan te leggen en bij een unique is het zinloos precies dezelfde gewone index aan te leggen, ze zullen dezelfde gegevens bevatten.

Ik kom dit op meerdere tabellen tegen en het vertraagd heel veel bij sommige delete statements. Kan dat ook van meerdere (dezelfde) indexen op 1 kolom komen?

Bij een delete of insert moet elke index die op de tabel zit bijgewerkt worden, dus als je twee overbodige indexen hebt zal dat best voor wat vertraging zorgen. Maar ik zou me er niet te zeer in vastbijten dat dat dan ook de reden is dat jouw delete statements zo vertraagd worden.

Als je bijvoorbeeld meerdere gebruikers tegelijk op die tabellen hebt is de kans groter dat je tegen de locking issues met MyISAM aanloopt.

[urk_forever]

Ok, bedankt voor de verduidelijking. Het verwijderen van de overbodige indexen en het leggen van een index op een foreign key verkortte de tijd voor een delete statement op een tabel van 10 sec naar <1sec