Taille des transactions MySQL - quelle taille est trop grande?
J'ai un processus d'importation qui s'exécute de temps en temps et je veux que ce soit une sorte d'accord tout ou rien, alias: une transaction.
Il y a de nombreux aspects, et les importations peuvent produire entre 100k-1mil + enregistrements. Cela équivaut à une charge utile allant de plusieurs Mo à quelques centaines de Mo de données.
Je sais que les tables temporaires sont une autre option - mais cette méthode semble si pratique.
Y a-t-il des mises en garde à prendre en compte concernant ce type de pratique avec une grande quantité de manipulation de données entre les validations? (En dehors de la rafale de charge d'écriture/d'indexation typique une fois validée)
Un goulot d'étranglement à connaître est le tampon de journal InnoDB. La taille est définie par innodb_log_buffer_size . Voici ce que la documentation MySQL en dit:
La taille en octets du tampon qu'InnoDB utilise pour écrire dans les fichiers journaux sur le disque. La valeur par défaut est 8 Mo. Un tampon de journal volumineux permet d'exécuter de grandes transactions sans qu'il soit nécessaire d'écrire le journal sur le disque avant la validation des transactions. Ainsi, si vous avez de grosses transactions, l'agrandissement du tampon de journal permet d'économiser les E/S disque.
Le tampon de journal InnoDB ne doit pas être confondu avec le pool de tampons InnoDB. La principale différence entre eux est leur objectif. Le tampon de journal InnoDB enregistre essentiellement les modifications à court terme qui sont écrites dans les journaux de rétablissement (ib_logfile0, ib_logfile1). Le pool de tampons InnoDB (dimensionné par innodb_buffer_pool_size ) met en cache les données et les pages d'index qui doivent être validées (si les pages sont sales) et éventuellement écrites) sur le disque. Une fois validées, les pages de modifications restent dans RAM jusqu'à ce qu'elles soient supprimées via les règles LRU.
Les transactions importantes doivent passer par le tampon de journal. Comme mentionné, un tampon de journal plus grand réduira les E/S disque. Seul un gros commit présenterait un goulot d'étranglement.
Vous voudrez peut-être examiner d'autres options InnoDB à configurer.
- innodb_flush_method : Cela dicte la façon dont le vidage est géré et s'il faut ou non autoriser le système d'exploitation à mettre en cache les écritures dans InnoDB ( Vous devez expérimenter entre O_DSYNC et O_DIRECT )
- innodb_read_io_threads (Utilisez le Max: 64)
- innodb_write_io_threads (Utilisez le Max: 64)
- innodb_io_capacity (utilisez des valeurs plus élevées comme 5000 ou 10000, mais le matériel le complétera pour vous, en d'autres termes, laissez le matériel décider de la capacité IO une fois que vous attribuez un nombre énorme)
- innodb_thread_concurrency : La valeur par défaut est 0. J'ai appris de première main de Ronald Bradford à Percona NYC 2011 pour laisser ce nombre à 0. Cela permet à InnoDB de décider le meilleur ( nombre de tickets d'accès simultané qu'il pourrait gérer)
J'ai d'autres articles sur l'optimisation d'InnoDB pour de plus amples recherches