Jag har länge funderat på att byta från MyISAM-tabller till InnoDB-tabeller, till exempel för att lite referentiell integritet och triggers vore underbart. Men nu också för att row-låsning är lite skönare än tabell-låsning (se min replikeringstråd). Det som hindrat mig är att det är en oerhörd massa arbete som man måste lägga ner, t.ex. för att commit:a alla transaktioner. Jag vet inte heller hur väl InnoDB-tabellerna står sig under tryck.

Är det någon som har erfarenhet av innoDB-tabeller i produktionsmiljö och kan besvara mina betänkligheter?

/David

Har kört InnoDB för en rätt så krävande aplikation med rätt så många rader, vilkt fungerade fint. MyISAM för samma applikation gjorde att tabellen låstes på tok för länge för att det skulle vara gångbart under peaks.

Exempelvis slashdot kör även InnoDB på de flesta av sina tabeller, enligt egen utsago. Så står sig under rejält tryck gör det.

Förhållandevis mycket inserts/updates och många rader så är InnoDB ett självklart val enligt mig.

Du måste väl inte jobba med transaktioner. Jag har använt InnoDB-tabeller just integritetskontroll men aldrig just transaktioner.

By the way, stödjer MySQL triggers med InnoDB menar du?

/Zoran

Det låter ju som det inte ska vara något problem med InnoDB under tryck då.

Som jag har förstått det så är InnoDB-motorn transaktionsorienterad (dvs man gör commit) men jag antar att man kan ställa in autocommit eller nåt sånt så det borde väl vara ganska lätt att komma undan. Jag vet att InnoDB har stöd för referentiell integritet men jag kanske inte minns rätt angående triggrarna. Men det är den referentiella integriteten jag vill åt först.

Är inte (och har inte orkat kolla det) insatt i MySQL, men alla andra databaser jag jobbat med är det ju så att om du inte explicit skapar en transaktion så blir ju varje statement automatiskt en transaktion. verkar ologiskt att det skulle vara annorlunda här.

Vet inte hur det är egentligen. Om man laddar ner källkoden för /. så använder de MyISAM för alla tabeller.
Detta hjälper kanske inte dig David? ;)

Jag vet inte hur det fungerar här internt älirgt talat, det är bara så att jag vet att man inte behöver commita sina transaktioner explicit. Det är kanske beroende på inställningar. Default är det så att du inte behöver. Sybase däremot vet jag kräver commit.

/Zoran

http://dev.mysql.com/doc/mysql/en/InnoDB_a...AUTOCOMMIT.html

På de tabeller där jag har provat InnoDB verkar det som att autocommit på som default, jag är dock inte säker.

Jag hörde och läste många bra saker om InnoDB så jag konverterade min databas natten till igår, runt hundra tabeller. Jag passade också på att lägga till lite fler index för att hjälpa InnoDB att göra SELECT COUNT(*) vilket är ett jäkla härk har jag förstått (och nu erfarit).

Men det går långsamt, olidligt långsamt. Maskinen går varm
och sajten går segt som sirap med samma viskositet som den tidigare MyISAM-sirapen.

Jag är besviken, man hade ju hoppats på att det hade blivit bättre.

En fråga till er som använder InnoDB, är ni alltid noga med att separera ut BLOB:ar till egna tabeller (som man inte söker i helt enkelt) - är det hemligheten?

dev.mysql.com/doc/mysql/en/InnoDB_tuning.html innehåller en hel del saker som kan vara bra att tänka över ordentligt, ordningen på tipsen är även en väldigt bra väg att gå. Speciellt ändringar av innodb_buffer_pool_size brukar kunna ha avgörande betydelse.

Att separera BLOBs som det sällan skrivs till men ofta söks på till en separat tabell med MyISAM skulle absolut kunna vara något prestandaökande också, förutsatt att mängden data är tillräckligt liten för att hanteras bra av tabelltypen (vilket den förmodligen är?).

Tabelltypen i källkoden behöver inte stämma överens med vad som används. Mysql.com och innodb:s sida nämner ./ som exempel. Även på slashdot själv har det minst 1 gång skrivits av personalen om deras användande av innodb.