TL;DR:Ако вашият форум е бавен, НИВОТО НА ИЗОЛАЦИЯ НА ТРАНЗАКЦИИ най-вероятно не е причината за това и настройването му на нещо друго освен по подразбиране едва ли ще помогне. Задаването на innodb_flush_log_on_trx_commit =2 ще помогне, но има последици за трайността при сривове.
Дългата версия:
Какво НИВО НА ИЗОЛАЦИЯ НА ТРАНЗАКЦИИ съм написал в http:/ /mysqldump.azundris.com/archives/77-Transactions-An-InnoDB-Tutorial.html . Вижте всички 3 статии с общ преглед на InnoDB в http://mysqldump.azundris.com/categories/32 -InnoDB .
Резултатът е, че във всеки случай системата трябва да може да се връща назад, така че дори ЧЕТЕНЕ БЕЗ КОМИСИРАНЕ не променя нищо, което трябва да се направи при запис.
За транзакции за четене четенето е по-бавно, когато веригата от записи в регистъра за отмяна, водеща до изгледа за транзакцията за четене, е по-дълга, така че READ UNCOMMITTED или READ COMMITTED може да бъде много малко по-бързо от ПОВТОРЯЩОТО ЧЕТЕНЕ по подразбиране. Но трябва да имате предвид, че тук говорим за достъп до паметта и достъпът до диска ви забавя.
По въпроса за AUTOCOMMIT:Това ще синхронизира всеки отделен оператор за запис на диск. Ако сте използвали MyISAM преди и това е било достатъчно добре, може да искате да конфигурирате
[mysqld]
innodb_flush_log_on_trx_commit = 2
във вашия my.cnf файл и рестартирайте сървъра.
Това ще накара комит да запише от mysqld в буферния кеш на файловата система, но ще забави промиването на кеша на буфера на файловата система на диск, така че да се случва само веднъж в секунда. Няма да загубите никакви данни при срив на mysqld, но може да загубите записи на стойност до 1s при хардуерен срив. InnoDB ще се възстанови автоматично, дори след хардуерен срив, и поведението все още е по-добро, отколкото беше с MyISAM преди, дори и да не е пълен ACID. Ще бъде много по-бързо от AUTOCOMMIT без тази настройка.
