Les insertions dans le tableau suivant prennent jusqu'à 70 secondes pour terminer:

CREATE TABLE IF NOT EXISTS `productsCategories` (
  `categoriesId` int(11) NOT NULL,
  `productsId` int(11) NOT NULL,
  PRIMARY KEY (`categoriesId`,`productsId`),
  KEY `categoriesId` (`categoriesId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Il y a environ 100 000 lignes dans le tableau, et cela prend 7 Mo sur le disque.

Y a-t-il des paramètres dans MySQL qui peuvent améliorer les performances d'écriture?

Mon my.cnfdossier est le suivant:

log-slow-queries="/var/log/mysql/slow-query.log"
long_query_time=1 
log-queries-not-using-indexes

innodb_buffer_pool_size=4G
innodb_log_buffer_size=4M
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=8
innodb_flush_method=O_DIRECT

query_cache_size = 6G
key_buffer_size = 284M
query_cache_limit = 1024M
thread_cache_size = 128
table_cache = 12800

sort_buffer_size=2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M

read_buffer_size=128K

open_files_limit               = 1000
table_definition_cache         = 1024
table_open_cache               = 6000

max_heap_table_size=512M
tmp_table_size=4096M

max_connections=1000

thread_concurrency = 24

Voici la configuration matérielle:

• Dell R710
• RAID10
• RAM 48G

Compte tenu de ce matériel, je ne m'attendrais pas à ce que le problème soit un goulot d'étranglement matériel.

OBSERVATION # 1

La toute première chose qui attire mon attention est la structure de la table

CREATE TABLE IF NOT EXISTS `productsCategories` (
  `categoriesId` int(11) NOT NULL,
  `productsId` int(11) NOT NULL,
  PRIMARY KEY (`categoriesId`,`productsId`),
  KEY `categoriesId` (`categoriesId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Veuillez noter que l' categoriesIdindex et la CLÉ PRIMAIRE commencent par la même colonne. Il s'agit d'un index redondant. Étant donné que cette table est InnoDB, l' categoriesIdindex est redondant pour une autre raison: tous les index secondaires contiennent des clés dans gen_clust_index (alias Clustered Index; voir à quoi sert gen_clust_index dans mysql? )

Si vous supprimez l' categoriesIdindex avec

ALTER TABLE productsCategories DROP INDEX categoriesId;

cela améliorera considérablement les INSERT, car vous n'aurez pas à effectuer de maintenance d'index secondaire et en cluster supplémentaire.

OBSERVATION # 2

Si vous effectuez des opérations d'insertion en bloc, vous avez besoin d'un grand tampon d'insertion en bloc .

Veuillez consulter mes précédents articles à ce sujet:

• https://dba.stackexchange.com/a/16979/877
• https://dba.stackexchange.com/a/9893/877
• https://dba.stackexchange.com/a/2948/877

OBSERVATION # 3

La taille de votre fichier journal est bien trop petite !!! Il doit représenter 25% du pool de tampons InnoDB, qui dans votre cas doit être 1G. Voir mon article sur la façon de redimensionner les fichiers journaux InnoDB .

OBSERVATION # 4

Veuillez ne pas définir innodb_thread_concurrency !!! J'ai appris de première main à Percona Live NYC pour laisser ce paramètre tranquille . Il est désactivé par défaut dans MySQL 5.5, MySQL 5.1 InnoDB Plugin et Percona Server 5.1+.

OBSERVATION # 5

Vous devez utiliser innodb_file_per_table. Si cette option est désactivée, je fais de la maintenance des fichiers sur ibdata1 un cauchemar. Veuillez lire mon article sur la façon de nettoyer InnoDB pour l'implémenter .

OBSERVATION # 6

Si vous utilisez MySQL 5.5 ou Percona Server, vous devez définir certaines options pour que InnoDB utilise plusieurs processeurs / plusieurs cœurs. Veuillez consulter mon article sur ces paramètres .

OBSERVATION # 7

Vous avez innodb_log_buffer_size=4M. La valeur par défaut est 8M. Cela provoquera deux fois plus de vidage dans les journaux de rétablissement. Cela neutralisera également votre innodb_flush_log_at_trx_commit=2réglage. Veuillez le régler sur 32M. Consultez également la documentation MySQL sur innodb_log_buffer_size .

À la lumière de ces observations, veuillez ajouter ou remplacer les paramètres suivants:

[mysqld]
innodb_thread_concurrency = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 5000
innodb_file_per_table
innodb_log_file_size=1G
innodb_log_buffer_size=1G
bulk_insert_buffer_size = 256M

Vous devez vérifier innodb_log_file_size, le paramètre par défaut est 5M, ce qui est assez faible pour les configurations à écriture intensive. Pensez à le régler sur 100M. Vous devrez supprimer les anciens ib_logfile*fichiers afin de démarrer la base de données avec de nouveaux paramètres. Veuillez ne pas supprimer les fichiers journaux pendant que le serveur DB est en cours d'exécution, vous devrez d'abord l'arrêter. Vous devriez probablement sauvegarder les anciens fichiers journaux en premier, et pas seulement les supprimer.