Étant donné que tant de transactions sont connectées au fichier, la taille du fichier journal est importante pour les opérations d'écriture. Lorsque les enregistrements sont modifiés, la modification n'est pas immédiatement réécrite dans l'espace de table. Au lieu de cela, la modification est enregistrée à la fin du fichier journal et la page est marquée comme sale. InnoDB utilise son journal pour convertir les E/S aléatoires en E/S séquentielles

Lorsque le journal est plein, la page sale est écrite dans l'espace table en séquence pour libérer de l'espace dans le fichier journal. Par exemple, supposons qu'un serveur se bloque au milieu d'une transaction et que les opérations d'écriture ne sont enregistrées que dans le fichier journal. Avant que le serveur puisse de nouveau être mis en service, il doit passer par une phase de récupération dans laquelle les modifications enregistrées dans le fichier journal sont relus. Plus le nombre d'entrées dans le fichier journal est important, plus la restauration du serveur prend de temps.

Dans cet exemple, la taille du fichier journal affecte à la fois le temps de restauration et les performances d'écriture. Lorsque vous choisissez le bon nombre pour la taille du fichier journal, équilibrez le délai de restauration par rapport aux performances d'écriture. En général, tout ce qui se trouve entre 128M et 512M est d'une bonne valeur.