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)

— mince
source

Personnellement, j'aime avoir un équilibre. Je fais des importations dans des transactions de 1k ou 10k, car je sais juste que cela atteindrait environ 900k lignes et se bloquerait à cause de la taille du tampon ou de quelque chose de ridicule. Assez facile à comprendre, et pas autant d'E / S.

— Captain Hypertext

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 grand tampon de journal permet d'exécuter de grandes transactions sans avoir besoin 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 la RAM jusqu'à leur suppression 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 telles que 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é d'E / S une fois que vous avez attribué un grand nombre)
innodb_thread_concurrency : la valeur par défaut est 0. J'ai appris de première main de Ronald Bradford à Percona NYC 2011 de laisser ce nombre à 0. Cela permet à InnoDB de décider du 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 nouvelles recherches

— RolandoMySQLDBA
source

d'une certaine manière, je savais que vous seriez sur ce point. Merci pour les réponses complètes que vous semblez toujours donner. Question secondaire: Avez-vous des ressources concernant l'utilisation de innodb_io_capacity? Lorsque la documentation suggère qu'un SATA grand public à 5400/7200 tr / min a une valeur de 100, est-ce que vous proposez simplement de «supprimer la limite» en définissant cette valeur si haut?

— thinice

Je règle généralement innodb_io_capacity plus haut et laisse le matériel le compléter. Je vais ajouter ceci à ma réponse tout de suite.

— RolandoMySQLDBA