MySQL InnoDB.. Ervaringen?

[Verwijderd]

Heya..

Ik ben met 2 anderen bezig met een vrij stevig eCommerce
site en nu willen we in principe gebruik maken van InnoDB..

Mijn vraag is, wat zijn jullie ervaringen daarmee tot nu toe?
Iemand die de foreignkey constraints gebruikt? Gedraagt
het geheel zich een beetje ?

[Verwijderd]

Right.

Geen ervaringen!?

[Verwijderd]

Ik weet wel dat InnoDB zich iets anders gedraagd dan MySQL, omdat GoTpas ook is omgezet, en sommige dingen deden het niet meer...

Maar hij loopt uiteidelijk wel beter...

[Verwijderd]

Wat voor dingen deden het zoal al niet meer?

[Verwijderd]

Op vrijdag 02 november 2001 21:55 schreef opensrc het volgende:
Wat voor dingen deden het zoal al niet meer?

Je komt ool niet veel op GoT he Eerste post zag ik... Ik denk dat je het beste even Kees of Femme kan vragen wat de problemen allemaal waren. Volgens mij waren het er nogal wat...

[Verwijderd]

Op vrijdag 02 november 2001 21:59 schreef mgfun het volgende:

[..]

Je komt ool niet veel op GoT he Eerste post zag ik... Ik denk dat je het beste even Kees of Femme kan vragen wat de problemen allemaal waren. Volgens mij waren het er nogal wat...

Femme slaapt

[brammetje]

ik ben ook wel benieuwd..

lemme know!

[bartvb]

Same here.. Dadelijk maar eens zoeken of er niet iets in een .plan of op LA staat.

BTW volgensmij kan je ook geen fulltext index op InnoDB draaien (geen indices op BLOB en TEXT volgens de documentatie). Dat is wel de belangrijkste reden dat ik mijn spul nog niet omgegooid heb..

[stylee]

http://www.tweakers.net/plan/130

miscchien wel interessant om door te lezen (inclusief comments dus )

[bartvb]

Mwoh, staan erg veel reacties maar weinig info. Enige dat ik zo heb kunnen ontdekken is dat INSERT DELAYED niet werkt maar dat staat ook in de InnoDB docs

[Kees]

- INSERT DELAYED werkt idd niet meer
- count( levert geen snel resultaat (~2 sec. op een tabel met 3M records) omdat innodb itt myisam het aantal records niet ergens opslaat
- select id from messages where userid=59 werkt heel snel, gooi je er echter een order op: order by time bijv. dan duurt het enige seconden langer.

- backuppen dmv tablefiles kopieren niet meer mogelijk (allee de complete innodb is op die manier te backuppen)
- neemt meer ruimte in dan myisam

Verder is het grote voordeel row-level-locking. hiermee kun je redelijk wat queries naast elkaar doen (in het verleden zag ik regelmatig zooien queries op elkaar wachten, tegenwoordig haast niet meer).

[bartvb]

hey, cool!
Thanks for the insight

Ik snap alleen deze niet helemaal:
- select id from messages where userid=59 order by time

Lijkt me een erg simpele query.. Vreemd dat die helemaal anders reageert dan b.v. MyISAM.

BTW hoe is het nu opgelost met het fulltext verhaal? Ik dacht dat Topix gebruik maakte van een MySQL fulltext index op de topic titels?

[tomato]

Op zaterdag 03 november 2001 17:27 schreef bartvb het volgende:
BTW hoe is het nu opgelost met het fulltext verhaal? Ik dacht dat Topix gebruik maakte van een MySQL fulltext index op de topic titels?

Topix heeft al enige tijd haar eigen zoeksysteem (geen MySQL fulltext indexen).

[Apache]

Ik heb em thuis ook draaien, k'heb er een phpbb op draaien en een db waar ik 5000inserts op moest doen, load kwam bij die inserts niet over de 0.3 en dat voor een oude celly 266 dus dat vind ik niet slecht

k'heb die foreign keys nog niet gebruikt maar k'denk wel dat ze zo goed zullen werken als de overall performance van InnoDB.

[DvE]

Op zaterdag 03 november 2001 23:31 schreef Apache het volgende:
... k'heb er een phpbb op draaien en een db waar ik 5000inserts op moest doen, load kwam bij die inserts niet over de 0.3 en dat voor een oude celly 266 dus dat vind ik niet slecht
...

Misschien omdat je inserts meer van je harddisk vraagt dan van je CPU? Jeeez.

[Apache]

inserts kwamen van een via samba gemounte raid 0 op een athlon 1.4 dus niet vanop de linux server zelf, k'denk dat de enkele regeltjes die hij in de InnoDB data file moest schrijven het probleem niet echt zullen zijn

[Verwijderd]

Ik heb volgende script voor mySQL geschreven, maar inplaats van HH:MM voor tijd, krijg ik HH:MM:SS,
hoe kan ik hem oplossen
CREATE TABLE agenda(
agid int(11) NOT NULL AUTO_INCREMENT,
datum DATE NOT NULL,
bTijd TIME NOT NULL,
eTijd TIME NOT NULL,
afspraak VARCHAR(30) NOT NULL,
primary key(agid)
);
IK heb ook DATE_FORMAT in mySQL bekeken, maar niks gevonden

[tomato]

DATE_FORMAT() opzoeken in MySQL manual.

[Apache]

ff een updateje over mijn ervaring: het EET geheugen, ik weet niet hoe het komt, misschien een conf file die nog niet geoptimized is ofzo, maar het geheugen verbruik is gestegeven van 25MB (voor de hele server) naar 79MB

Dus hou je server goed in het oog als je gaat experimenteren

[smaij]

En ik wou het thuis nog wel gaan installeren op mijn 486 server toch maar niet dan. er zit maar 32 mb geheugen in dat ding

[chem]

Op dinsdag 27 november 2001 15:10 schreef smaij het volgende:
En ik wou het thuis nog wel gaan installeren op mijn 486 server toch maar niet dan. er zit maar 32 mb geheugen in dat ding

bedankt voor je bijdrage

[Rense Klinkenberg]

Ok, ik weet dat het een oud topic is, maar toch.

Het is in de configuratie perfect in te stellen hoeveel geheugen innodb mag gebruiken. Wanneer je iets verder kijkt in de manual, staat het er best wel in.