Trage Mysql database

[letscode]

Ik heb een Mysql MyISAM database gevuld met 150k records.
Als ik daar een query op uitvooer, bijvoorbeeld Select ljn, uitspraak_anoniem FROM uitspraak WHERE ljn = 'AA3456' dan duurt het langer dan een minuut, voordat hij het resultaat heeft.

Dit is mijn database schema:

code:

CREATE TABLE `uitspraak` (
  `ljn` char(6) NOT NULL,
  `status` int(11) NOT NULL,
  `instantie_naam` int(11) NOT NULL,
  `datum_uitspraak` date NOT NULL,
  `datum_gepubliceerd` date default NULL,
  `zaaknummers` varchar(255) NOT NULL,
  `uitspraak_anoniem` longtext NOT NULL,
  `conclusie_anoniem` longtext,
  `zittingsplaats` int(11) default NULL,
  `rechtsgebied_rechtspraak` int(11) default NULL,
  `sector_toon` int(11) default NULL,
  `procedure_soort` int(11) default NULL,
  `indicatie` longtext,
  `kop` text,
  PRIMARY KEY  (`ljn`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

De database draait op mijn eigen MAMP installatie op een macbook C2D 2,4 Ghz.
Ik ben benieuwd of ik dingen verkeerd heb gedaan in mijn tabelstructuur, of dat mijn computer gewoon te sloom is.

[AtleX]

Voeg en index toe toe op de kolom 'ljn'. Daar staat er al 1 op vermoed, aangezien dat de primary key is. EXPLAIN kan je trouwens een hoop vertellen over hoe MySQL een query uitvoert en optimaliseren wordt daarmee een stuk eenvoudiger. Kijk vooral naar welke indexes hij gebruikt.

[ Voor 19% gewijzigd door AtleX op 05-09-2009 10:14 ]

[Fish]

150k records is echt niks, 2,4 ghz is ook zat,
ik zou een kijken of er iets anders mis is met die machine, ik ben helaas geen mac kennner,

[Down]

Probeer eens een AUTO_INCREMENT primary key veld toe te voegen aan de tabel (bv uitspraak_id) van type int en zet een unique constraint op ljn. Een pkey van char(6) zal in veel gevallen meer ruimte innemen dan een pkey van type int (= 4 bytes), een grotere key kan gevolgen hebbenvoor je index. Wat voor index gaat het trouwens om?

[Voutloos]

Of, indien de PK nu enkel uit hexadecimale karakters bestaat, kan je het ook als unsigned medium int opslaan en heb je geen extra kolom nodig.

Maar goed, er is nog iets anders aan de hand, want zelfs totaal zonder index zou je niet eens aan een tijd een minuut kunnen komen met een dergelijk idioot simpele query.

Een explain is wellicht alsnog handig. Of geef de echte query, want deze kan nooit zo duur zijn.

[swtimmer]

Niet stiekem op de achtergrond gekke dingen aant doen met je harddisk?

[Afvalzak]

Het kan ook aan de MAMP installatie liggen. Ik merk dat MySQL op een *AMP installatie toch altijd trager is. Een minuut lijkt me echter overdreven in dat geval..

[Voutloos]

*AMP installatie? Met het sterretje van alle OS'en zijn traag?

[Verwijderd]

genoeg geheugen? (anders kan het best zijn dat je systeem zich dood staat te swappen)
doe eens een iostat
en mytop is ook wel eens handig.

heb je toevallig je my.cnf getuned?

[remco_k]

AtleX schreef op zaterdag 05 september 2009 @ 10:12:
Voeg en index toe toe op de kolom 'ljn'. Daar staat er al 1 op vermoed, aangezien dat de primary key is.

Als je het mij vraagt:
Primary key != index

Dus misschien toch maar even een index aanmaken op die kolom.

[Confusion]

fish schreef op zaterdag 05 september 2009 @ 10:15:
[..] ik zou een kijken of er iets anders mis is met die machine, [..]

Dat lijkt me een beetje voorbarig.

Down schreef op zondag 06 september 2009 @ 00:28:
Probeer eens een AUTO_INCREMENT primary key veld toe te voegen aan de tabel (bv uitspraak_id) van type int

Waarom zou dat kunnen helpen?

en zet een unique constraint op ljn.

Waarom zou dat kunnen helpen?

Een pkey van char(6) zal in veel gevallen meer ruimte innemen dan een pkey van type int (= 4 bytes),

Waarom denk je dat dat hier relevant zou kunnen zijn?

Wat voor index gaat het trouwens om?

Er is maar 1 soort index die MySql voor een primary key op een char(6) veld gebruikt

afvalzak schreef op zondag 06 september 2009 @ 13:17:
Ik merk dat MySQL op een *AMP installatie toch altijd trager is.

1) Trager dan...?
2) Al eens geprobeerd de configuraties gelijk te trekken?
3) Heb je echt genoeg ervaring om hier een uitspraak over te doen, of baseer je dit op 1 echte vergelijking en verder 'gevoel'?

Heeft er iemand anders nog snake oil in de aanbieding?

[Creepy]

remco_k schreef op maandag 07 september 2009 @ 17:14:
[...]

Als je het mij vraagt:
Primary key != index

Nope.. Primary key == index

http://dev.mysql.com/doc/refman/5.1/en/create-table.html
A PRIMARY KEY is a unique index where all key columns must be defined as NOT NULL. If they are not explicitly declared as NOT NULL, MySQL declares them so implicitly (and silently). A table can have only one PRIMARY KEY. If you do not have a PRIMARY KEY and an application asks for the PRIMARY KEY in your tables, MySQL returns the first UNIQUE index that has no NULL columns as the PRIMARY KEY.

Wil iedereen die denkt wat nuttigs te posten aub eerst even de feiten checken? Confusion geeft ook al een subtiele hint

Ik weet niet wat je machine allemaal aan het doen is maar 1 minuut voor een volledige table scan in een redelijke tabel met 150.000 records, zelfs met aardige TEXT of LONG TEXT columns is enorm traag. Dus zelfs zonder index zou het resultaat sneller beschikbaar moeten zijn. Controleer wat de server aan het doen is en vraag zoals al aangeven de EXPLAIN op zodat je weet hoe MySQL met je query omgaat.

[ Voor 20% gewijzigd door Creepy op 07-09-2009 22:37 ]