TL; DR :Si votre forum est lent, le NIVEAU D'ISOLATION DES TRANSACTIONS n'en est probablement pas la cause et le définir sur autre chose que la valeur par défaut n'aidera guère. Définir innodb_flush_log_on_trx_commit =2 aidera, mais a des conséquences sur la durabilité en cas de plantage.
La version longue :
Quel NIVEAU D'ISOLEMENT DE TRANSACTION ai-je écrit dans http:/ /mysqldump.azundris.com/archives/77-Transactions-An-InnoDB-Tutorial.html . Consultez les 3 articles de présentation d'InnoDB dans http://mysqldump.azundris.com/categories/32 -InnoDB .
Le résultat est que dans tous les cas, le système doit être capable de ROLLBACK, donc même READ UNCOMMITTED ne change rien à ce qui doit être fait lors d'une écriture.
Pour les transactions de lecture, la lecture est plus lente lorsque la chaîne d'enregistrements du journal d'annulation menant à la vue de la transaction de lecture est plus longue, donc READ UNCOMMITTED ou READ COMMITTED peut être très légèrement plus rapide que la valeur REPEATABLE READ par défaut. Mais vous devez garder à l'esprit que nous parlons ici d'accès à la mémoire et que ce sont les accès au disque qui vous ralentissent.
À propos d'AUTOCOMMIT :cela synchronisera chaque instruction d'écriture sur le disque. Si vous avez déjà utilisé MyISAM et que c'était assez bon, vous voudrez peut-être configurer
[mysqld]
innodb_flush_log_on_trx_commit = 2
dans votre fichier my.cnf et redémarrez le serveur.
Cela fera écrire le commit depuis mysqld vers le cache du tampon du système de fichiers, mais retardera le vidage du cache du tampon du système de fichiers sur le disque afin que cela ne se produise qu'une fois par seconde. Vous ne perdrez aucune donnée lors d'un crash mysqld, mais vous risquez de perdre jusqu'à 1 seconde d'écritures lors d'un crash matériel. L'InnoDB récupérera automatiquement, même après un crash matériel, et le comportement est toujours meilleur qu'il ne l'était avec MyISAM auparavant, même s'il n'est pas entièrement ACID. Ce sera beaucoup plus rapide qu'AUTOCOMMIT sans ce paramètre.
