{"id":8538,"date":"2021-02-24T23:06:21","date_gmt":"2021-02-24T22:06:21","guid":{"rendered":"https:\/\/blog.capdata.fr\/?p=8538"},"modified":"2021-02-25T08:42:48","modified_gmt":"2021-02-25T07:42:48","slug":"verrous-sur-insert-ignore-insert-on-duplicate-key-update","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/","title":{"rendered":"Verrous sur INSERT IGNORE en mode d’isolation par d\u00e9faut"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>\n\n
En pr\u00e9ambule<\/strong>: il peut \u00eatre int\u00e9ressant de lire les articles sur le verrouillage en 4 \u00e9pisodes de Kuba \u0141opusza\u0144ski:
\n– \u00e9pisode 1<\/a> : introduction
\n– \u00e9pisode 2<\/a> : locks
\n– \u00e9pisode 3<\/a> : locks deep dive
\n– \u00e9pisode 4<\/a> : deadlocks\n<\/td>\n<\/tr>\n<\/table>\n

\"\"
\nAujourd’hui, nous allons analyser un probl\u00e8me de verrouillage sur MySQL \/ MariaDB avec INSERT IGNORE<\/a><\/em>.<\/p>\n

Un petit exemple tout d’abord pour illustrer l’utilisation de cette instruction, avec une table example <\/strong>telle que:<\/p>\n

\r\nmysql> create table example (a int NOT NULL, \r\n  -> b datetime NULL, \r\n  -> PRIMARY KEY (a)) ENGINE=innodb ;\r\nQuery OK, 0 rows affected (0.01 sec)\r\n\r\nmysql> select * from example ;\r\n+---+---------------------+\r\n| a | b                   |\r\n+---+---------------------+\r\n| 1 | 2021-02-24 17:35:12 |\r\n| 2 | 2021-02-23 17:35:26 |\r\n+---+---------------------+\r\n2 rows in set (0.00 sec)\r\n<\/pre>\n
OK donc le but d’INSERT IGNORE<\/em><\/strong> est de tenter une insertion dans une table mais ne pas g\u00e9n\u00e9rer d’erreur en cas de violation de cl\u00e9 unique , simplement la ligne n’est pas ins\u00e9r\u00e9e et un warning est renvoy\u00e9 au client:<\/p>\n
\r\nmysql> insert ignore into example values \r\n  -> (2,date_add(now(), interval -1 week)) ;\r\nQuery OK, 0 rows affected, 1 warning (0.00 sec)\r\n\r\nmysql> show warnings ;\r\n+---------+------+-----------------------------------------------+\r\n| Level   | Code | Message                                       |\r\n+---------+------+-----------------------------------------------+\r\n| Warning | 1062 | Duplicate entry '2' for key 'example.PRIMARY' |\r\n+---------+------+-----------------------------------------------+\r\n1 row in set (0.00 sec)\r\n<\/pre>\n
On va s’int\u00e9resser maintenant aux types de verrous impliqu\u00e9s. <\/p>\n
Probl\u00e8me de verrouillage<\/h1>\n
Soit trois tables src<\/strong>, trg <\/strong>et ref <\/strong>telles que:
\n\"\"
\nsrc <\/strong>est la table source telle que:<\/p>\n
\r\nmysql> show create table src \\G\r\n*************************** 1. row ***************************\r\n       Table: src\r\nCreate Table: CREATE TABLE `src` (\r\n  `a` bigint NOT NULL,\r\n  `b` datetime DEFAULT NULL,\r\n  PRIMARY KEY (`a`)\r\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci\r\n1 row in set (0.00 sec)\r\n<\/pre>\n
On cr\u00e9\u00e9 un trigger AFTER UPDATE sur src <\/strong>pour venir ins\u00e9rer avec INSERT IGNORE<\/em> <\/strong>les nouvelles lignes modifi\u00e9es dans une seconde table trg<\/strong>:<\/p>\n
\r\nDELIMITER  \/\/\r\nCREATE TRIGGER update_src AFTER UPDATE ON src FOR EACH ROW\r\n BEGIN \r\n\tINSERT IGNORE INTO trg (c,d) \r\n\tVALUES (NEW.a,DATE_FORMAT(NEW.b,'%Y%m')); \r\n END \/\/\r\nDELIMITER ;\r\n<\/pre>\n
trg <\/strong>est la table qui re\u00e7oit les donn\u00e9es modifi\u00e9es du trigger:<\/p>\n
\r\nmysql> show create table trg \\G\r\n*************************** 1. row ***************************\r\n       Table: trg\r\nCreate Table: CREATE TABLE `trg` (\r\n  `c` bigint NOT NULL,\r\n  `d` int DEFAULT NULL,\r\n  UNIQUE KEY `c` (`c`,`d`),\r\n  CONSTRAINT `FK_c` FOREIGN KEY (`c`) REFERENCES `ref` (`c`)\r\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci\r\n1 row in set (0.00 sec)\r\n<\/pre>\n
Noter que la colonne d<\/strong> accepte les valeurs NULL, donc elle ne peut pas faire partie d’une cl\u00e9 primaire, on cr\u00e9\u00e9 une cl\u00e9 UNIQUE sur (c,d). InnoDB ne conna\u00eet pas les heaps<\/a>, donc il s’appuie sur cette cl\u00e9 unique pour g\u00e9n\u00e9rer un index clusteris\u00e9 qu’il appelera en interne ‘GEN_CLUST_INDEX’<\/em>.
\nEnfin, \u00e0 chaque insertion dans trg<\/strong>, on va aller lire si la valeur de (c) est bien list\u00e9e dans une table de r\u00e9f\u00e9rence ref <\/strong>telle que: <\/p>\n
\r\nmysql> show create table ref \\G\r\n*************************** 1. row ***************************\r\n       Table: ref\r\nCreate Table: CREATE TABLE `ref` (\r\n  `c` bigint NOT NULL,\r\n  PRIMARY KEY (`c`)\r\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci\r\n1 row in set (0.00 sec)\r\n\r\nmysql> select * from ref ;\r\n+-------+\r\n| c     |\r\n+-------+\r\n| 11111 |\r\n| 22222 |\r\n| 33333 |\r\n| 44444 |\r\n| 55555 |\r\n| 66666 |\r\n| 77777 |\r\n| 88888 |\r\n| 99999 |\r\n+-------+\r\n9 rows in set (0.00 sec)\r\n<\/pre>\n
Premier test :<\/h1>\n
Contenu de src <\/strong>et trg <\/strong>au d\u00e9but du test:<\/p>\n
\r\nmysql> select * from src; select * from trg ;\r\n+-------+---------------------+\r\n| a     | b                   |\r\n+-------+---------------------+\r\n| 11111 | 2021-02-24 15:41:11 |\r\n| 33333 | 2021-02-24 15:40:53 |\r\n| 55555 | 2021-02-24 16:58:49 |\r\n| 77777 | 2021-02-24 16:58:58 |\r\n+-------+---------------------+\r\n4 rows in set (0.00 sec)\r\n\r\n+-------+--------+\r\n| c     | d      |\r\n+-------+--------+\r\n| 11111 | 202102 |\r\n| 22222 | 202102 |\r\n| 33333 | 202102 |\r\n| 77777 | 202102 |\r\n| 88888 | 202102 |\r\n+-------+--------+\r\n5 rows in set (0.00 sec)\r\n<\/pre>\n
La premi\u00e8re transaction met \u00e0 jour une ligne de src <\/strong>:<\/p>\n
\r\nmysql> start transaction ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> update src set a=44444 where a=11111 ;\r\nQuery OK, 1 row affected (0.00 sec)\r\nRows matched: 1  Changed: 1  Warnings: 0\r\n<\/pre>\n
Pendant ce temps, une seconde transaction fait un UPDATE sur une autre ligne de src <\/strong>de la m\u00eame mani\u00e8re:<\/p>\n
\r\nmysql> start transaction ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> update src set a=66666 where a=33333 ;\r\nQuery OK, 1 row affected (0.00 sec)\r\nRows matched: 1  Changed: 1  Warnings: 0\r\n<\/pre>\n
Les valeurs ins\u00e9r\u00e9es dans la table trg <\/strong>par le trigger n’existent pas dans les deux cas donc les lignes sont bien ins\u00e9r\u00e9es, apr\u00e8s avoir \u00e9t\u00e9 v\u00e9rifier que les nouvelles valeurs (44444 et 66666) existent bien dans la table ref<\/strong><\/p>\n
Les deux transactions acc\u00e8dent en modification \u00e0 des enregistrements diff\u00e9rents de src<\/strong>, et ins\u00e8rent des lignes diff\u00e9rentes dans trg<\/strong>, donc elles ne se bloquent pas mutuellement. Comme nous sommes en version 8.0, on peut utiliser la nouvelle vue performance_schema.data_locks<\/a> pour inspecter les verrous pos\u00e9s par chaque transaction. Noter que nous n’avons pas valid\u00e9 ou annul\u00e9 chaque transaction pour pouvoir faire cette inspection: <\/p>\n
Pour la premi\u00e8re transaction <\/strong>:<\/p>\n
\r\nmysql> select OBJECT_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, \r\n  -> LOCK_DATA from data_locks where THREAD_ID = 49 ;\r\n+-------------+-----------+---------------+-------------+-----------+\r\n| OBJECT_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |\r\n+-------------+-----------+---------------+-------------+-----------+\r\n| src         | TABLE     | IX            | GRANTED     | NULL      |\r\n| src         | RECORD    | X,REC_NOT_GAP | GRANTED     | 11111     |\r\n| trg         | TABLE     | IX            | GRANTED     | NULL      |\r\n| ref         | TABLE     | IS            | GRANTED     | NULL      |\r\n| ref         | RECORD    | S,REC_NOT_GAP | GRANTED     | 44444     |\r\n+-------------+-----------+---------------+-------------+-----------+\r\n5 rows in set (0.00 sec)\r\n<\/pre>\n
Et pour la seconde<\/strong> :<\/p>\n
\r\nmysql> select OBJECT_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, \r\n  -> LOCK_DATA from data_locks where THREAD_ID = 50 ;\r\n+-------------+-----------+---------------+-------------+-----------+\r\n| OBJECT_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |\r\n+-------------+-----------+---------------+-------------+-----------+\r\n| src         | TABLE     | IX            | GRANTED     | NULL      |\r\n| src         | RECORD    | X,REC_NOT_GAP | GRANTED     | 33333     |\r\n| trg         | TABLE     | IX            | GRANTED     | NULL      |\r\n| ref         | TABLE     | IS            | GRANTED     | NULL      |\r\n| ref         | RECORD    | S,REC_NOT_GAP | GRANTED     | 66666     |\r\n+-------------+-----------+---------------+-------------+-----------+\r\n5 rows in set (0.00 sec)\r\n<\/pre>\n
On voit bien que chaque transaction utilise les m\u00eames verrous sur des enregistrements diff\u00e9rents, elles n’entrent donc pas en concurrence:
\n\"\"
\n– Sur src <\/strong>: un verrou d’intention IX sur la table, pour prot\u00e9ger la modification de la ligne, plus un verrou exclusif sur l’enregistrement  seul (X,REC_NOT_GAP). Les verrous d’intention sont compatibles entre eux, et les deux autres verrouillent des enregistrements diff\u00e9rents.
\n– Sur ref<\/strong>: un verrou d’intention partag\u00e9 IS sur la table, et un verrou en lecture sur l’enregistrement de la cl\u00e9 primaire (S,REC_NOT_GAP) pour satisfaire la contrainte d’int\u00e9grit\u00e9 r\u00e9f\u00e9rentielle.
\n– Enfin sur trg<\/strong>: on ne voit qu’un verrou d’intention sur la table. Mais o\u00f9 sont pass\u00e9s les autres verrous sur l’INSERT ?<\/p>\n
Alors l\u00e0 il y a une petite subtilit\u00e9. En REPEATABLE-READ, lorsqu’une ligne va \u00eatre ins\u00e9r\u00e9e, un premier verrou X,INSERT_INTENTION<\/a> est pos\u00e9 puis un verrou X,REC_NOT_GAP sur le futur enregistrement ‘formatt\u00e9<\/em>‘ pour recevoir la future ligne \u00e0 ins\u00e9rer. <\/p>\n
X,INSERT_INTENTION est un genre de gap lock <\/a>mais sp\u00e9cifique \u00e0 la fin de la page : il couvre un pseudo-enregistrement qui repr\u00e9sente l’espace entre la derni\u00e8re valeur ins\u00e9r\u00e9e et la fin de la page, que l’on appelle supremum<\/a><\/em>. Il permet de pr\u00e9parer le terrain \u00e0 une insertion dans l’intervalle avant la fin de page. <\/p>\n
D’ailleurs le sch\u00e9ma n’est pas tout \u00e0 fait juste dans le sens o\u00f9 il semble que les deux nouvelles lignes (44444|202102) et (66666|202102) dans trg<\/strong> soient ins\u00e9r\u00e9es au milieu, ce qui n’est pas le cas dans la pratique. Elles sont ins\u00e9r\u00e9es \u00e0 la fin et chacune embarque dans son ent\u00eate un pointeur vers le ‘prochain’ enregistrement dans la page, ce serait bien trop lourd de ‘d\u00e9placer’ des lignes dans la page, \u00e7a ressemble donc plut\u00f4t \u00e0 \u00e7a:
\n\"\"<\/p>\n
Mais si je ne simplifie pas un peu on ne va pas s’en sortir …<\/p>\n
Bref on ne voit pas ces verrous dans data_locks<\/em> car ils sont dits implicites <\/em> dans le sens o\u00f9 ils n’int\u00e9ressent que la transaction qui est en cours (souvenez-vous qu’avec InnoDB, le mode d’isolation par d\u00e9faut est REPEATABLE-READ). Chaque nouvelle ligne n’est visible que de la transaction qui l’a ins\u00e9r\u00e9e. <\/p>\n
En fait ces verrous peuvent \u00eatre convertis en verrous explicites par le moniteur de verrous InnoDB s’ils sont la cause d’un blocage, et \u00eatre rendus visibles aux interfaces notamment data_locks<\/em> , ce qui n’est pas le cas ici donc on ne les voit pas.  <\/p>\n
Deuxi\u00e8me test:<\/h1>\n
Cette fois on va forcer l’insertion par le trigger d’une ligne qui existe d\u00e9j\u00e0<\/strong>
\n dans trg<\/strong> pour voir ce qu’il se passe. Le trigger effectue un INSERT IGNORE<\/em>, donc la ligne devrait ne pas \u00eatre ins\u00e9r\u00e9e. Qu’en est-il des verrous ?<\/p>\n
A nouveau une premi\u00e8re session modifie une ligne de src<\/strong>, mais cette fois avec une valeur qui existe d\u00e9j\u00e0 dans trg<\/strong> (22222):<\/p>\n
\r\nmysql> start transaction ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> update src set a=22222 where a=44444 ;\r\nQuery OK, 1 row affected (0.00 sec)\r\nRows matched: 1  Changed: 1  Warnings: 0\r\n<\/pre>\n
Notez que le warning ne remonte pas car il a \u00e9t\u00e9 ‘dig\u00e9r\u00e9<\/em>‘ par le trigger. <\/p>\n
De la m\u00eame mani\u00e8re une autre transaction modifie une autre ligne de src<\/strong>, cette fois avec une valeur qui n’existe pas encore dans trg<\/strong>:<\/p>\n
\r\nmysql> start transaction ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> update src set a=99999 where a=77777 ;\r\nERROR 1205 (HY000): Lock wait timeout exceeded; \r\ntry restarting transaction\r\n<\/pre>\n
Elle tombe en erreur au bout de 50 secondes (valeur de innodb_lock_wait_timeout <\/a>par d\u00e9faut). Si on inspecte les verrous pos\u00e9s par ces 2 transactions (avant la fin des 50 secondes):<\/p>\n
Pour la premi\u00e8re transaction<\/strong>:<\/p>\n
\r\nmysql> select OBJECT_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA \r\n  -> from data_locks where THREAD_ID = 52 ;\r\n+-------------+-----------+---------------+-------------+-------------------------------+\r\n| OBJECT_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA                     |\r\n+-------------+-----------+---------------+-------------+-------------------------------+\r\n| src         | TABLE     | IX            | GRANTED     | NULL                          |\r\n| src         | RECORD    | X,REC_NOT_GAP | GRANTED     | 44444                         |\r\n| trg         | TABLE     | IX            | GRANTED     | NULL                          |\r\n| ref         | TABLE     | IS            | GRANTED     | NULL                          |\r\n| ref         | RECORD    | S,REC_NOT_GAP | GRANTED     | 22222                         |\r\n| trg         | RECORD    | S             | GRANTED     | 22222, 202102, 0x000000000200 |\r\n| trg         | RECORD    | X             | GRANTED     | supremum pseudo-record        |\r\n+-------------+-----------+---------------+-------------+-------------------------------+\r\n7 rows in set (0.00 sec)\r\n<\/pre>\n
Deux nouveaux verrous sont visibles :
\n– un verrou S (c’est \u00e0 dire S,REC_NOT_GAP + S,GAP) sur la ligne qui provoque la violation de cl\u00e9 unique dans trg<\/strong>, avec la valeur (22222|202102).
\n– un verrou X (c’est \u00e0 dire X,REC_NOT_GAP + X,GAP) sur le supremum<\/em>. <\/p>\n
Pour la seconde transaction<\/strong>: <\/p>\n
\r\nmysql> select OBJECT_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA \r\n  -> from data_locks where THREAD_ID = 53 ;\r\n+-------------+-----------+--------------------+-------------+------------------------+\r\n| OBJECT_NAME | LOCK_TYPE | LOCK_MODE          | LOCK_STATUS | LOCK_DATA              |\r\n+-------------+-----------+--------------------+-------------+------------------------+\r\n| src         | TABLE     | IX                 | GRANTED     | NULL                   |\r\n| src         | RECORD    | X,REC_NOT_GAP      | GRANTED     | 77777                  |\r\n| trg         | TABLE     | IX                 | GRANTED     | NULL                   |\r\n| trg         | RECORD    | X,INSERT_INTENTION | WAITING     | supremum pseudo-record |\r\n+-------------+-----------+--------------------+-------------+------------------------+\r\n4 rows in set (0.00 sec)\r\n<\/pre>\n
Elle tente de poser un verrou INSERT_INTENTION<\/em> sur le gap entre la derni\u00e8re valeur et la fin de la page, mais l’autre transaction poss\u00e8de d\u00e9j\u00e0 un verrou (X) sur le supremum <\/em>ET le gap. Le statut de cette demande reste en WAITING jusqu’\u00e0 expiration du timeout, pourtant la premi\u00e8re transaction n’a rien ins\u00e9r\u00e9 du tout. <\/p>\n
\"\"<\/p>\n
En parcourant la documentation officielle <\/a>on peut lire : <\/p>\n
“If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock”<\/em><\/p>\n
En modifiant le mode d’isolation \u00e0 READ-COMMITTED, les verrous de type gap lock <\/em>comme l’INSERT_INTENTION <\/em>ne sont pas utilis\u00e9s et la seconde transaction peut ins\u00e9rer sans \u00eatre bloqu\u00e9e:<\/p>\n
Premi\u00e8re transaction<\/strong>:<\/p>\n
\r\nmysql> set transaction_isolation='READ-COMMITTED' ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> start transaction ; \r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> update src set a=22222 where a=44444 ;\r\nQuery OK, 1 row affected (0.00 sec)\r\nRows matched: 1  Changed: 1  Warnings: 0\r\n<\/pre>\n
Seconde transaction<\/strong>:<\/p>\n
\r\nmysql> set transaction_isolation='READ-COMMITTED' ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> start transaction ;\r\nQuery OK, 0 rows affected (0.00 sec)\r\n\r\nmysql> update src set a=99999 where a=77777 ;\r\nQuery OK, 1 row affected (0.00 sec)\r\nRows matched: 1  Changed: 1  Warnings: 0\r\n<\/pre>\n
En apart\u00e9, vous noterez que la table ref<\/strong> n’entre pas dans le d\u00e9bat ici, cela dit la v\u00e9rification d’une contrainte d’int\u00e9grit\u00e9 d\u00e9clench\u00e9e par un trigger peut rallonger encore la dur\u00e9e de la transaction parente, et ainsi allonger la dur\u00e9e de maintien des verrous. Il faut donc faire attention \u00e0 ne pas trop cascader de d\u00e9pendances dans une m\u00eame transaction. <\/p>\n
N’h\u00e9sitez pas \u00e0 partager vos exp\u00e9riences similaires dans les commentaires !<\/p>\n
A bient\u00f4t ~David. <\/p>\n\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>","protected":false},"excerpt":{"rendered":"
En pr\u00e9ambule: il peut \u00eatre int\u00e9ressant de lire les articles sur le verrouillage en 4 \u00e9pisodes de Kuba \u0141opusza\u0144ski: – \u00e9pisode 1 : introduction – \u00e9pisode 2 : locks – \u00e9pisode 3 : locks deep dive – \u00e9pisode 4 :… Continuer la lecture →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":8542,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[375,104,376,374,377,64],"class_list":["post-8538","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mysql","tag-deadlock","tag-innodb","tag-insert-intention","tag-lock","tag-supremum","tag-trigger"],"yoast_head":"\nVerrous sur INSERT IGNORE en mode d'isolation par d\u00e9faut - Capdata TECH BLOG<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Verrous sur INSERT IGNORE en mode d'isolation par d\u00e9faut - Capdata TECH BLOG\" \/>\n<meta property=\"og:description\" content=\"En pr\u00e9ambule: il peut \u00eatre int\u00e9ressant de lire les articles sur le verrouillage en 4 \u00e9pisodes de Kuba \u0141opusza\u0144ski: – \u00e9pisode 1 : introduction – \u00e9pisode 2 : locks – \u00e9pisode 3 : locks deep dive – \u00e9pisode 4 :… Continuer la lecture →\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\" \/>\n<meta property=\"og:site_name\" content=\"Capdata TECH BLOG\" \/>\n<meta property=\"article:published_time\" content=\"2021-02-24T22:06:21+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2021-02-25T07:42:48+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2021\/02\/lockedin-d2670e799df5407dbce235c22ed38152.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"2071\" \/>\n\t<meta property=\"og:image:height\" content=\"1448\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"David Baffaleuf\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"David Baffaleuf\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\"},\"author\":{\"name\":\"David Baffaleuf\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf\"},\"headline\":\"Verrous sur INSERT IGNORE en mode d’isolation par d\u00e9faut\",\"datePublished\":\"2021-02-24T22:06:21+00:00\",\"dateModified\":\"2021-02-25T07:42:48+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\"},\"wordCount\":2135,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/blog.capdata.fr\/#organization\"},\"keywords\":[\"deadlock\",\"InnoDB\",\"insert intention\",\"lock\",\"supremum\",\"trigger\"],\"articleSection\":[\"MySQL\"],\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\",\"url\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\",\"name\":\"Verrous sur INSERT IGNORE en mode d'isolation par d\u00e9faut - Capdata TECH BLOG\",\"isPartOf\":{\"@id\":\"https:\/\/blog.capdata.fr\/#website\"},\"datePublished\":\"2021-02-24T22:06:21+00:00\",\"dateModified\":\"2021-02-25T07:42:48+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/blog.capdata.fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Verrous sur INSERT IGNORE en mode d’isolation par d\u00e9faut\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.capdata.fr\/#website\",\"url\":\"https:\/\/blog.capdata.fr\/\",\"name\":\"Capdata TECH BLOG\",\"description\":\"Le blog technique sur les bases de donn\u00e9es de CAP DATA Consulting\",\"publisher\":{\"@id\":\"https:\/\/blog.capdata.fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.capdata.fr\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/blog.capdata.fr\/#organization\",\"name\":\"Capdata TECH BLOG\",\"url\":\"https:\/\/blog.capdata.fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp\",\"contentUrl\":\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp\",\"width\":800,\"height\":254,\"caption\":\"Capdata TECH BLOG\"},\"image\":{\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.linkedin.com\/company\/cap-data-consulting\/mycompany\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf\",\"name\":\"David Baffaleuf\",\"sameAs\":[\"http:\/\/www.capdata.fr\"],\"url\":\"https:\/\/blog.capdata.fr\/index.php\/author\/dbaffaleuf\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Verrous sur INSERT IGNORE en mode d'isolation par d\u00e9faut - Capdata TECH BLOG","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/","og_locale":"fr_FR","og_type":"article","og_title":"Verrous sur INSERT IGNORE en mode d'isolation par d\u00e9faut - Capdata TECH BLOG","og_description":"En pr\u00e9ambule: il peut \u00eatre int\u00e9ressant de lire les articles sur le verrouillage en 4 \u00e9pisodes de Kuba \u0141opusza\u0144ski: – \u00e9pisode 1 : introduction – \u00e9pisode 2 : locks – \u00e9pisode 3 : locks deep dive – \u00e9pisode 4 :… Continuer la lecture →","og_url":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/","og_site_name":"Capdata TECH BLOG","article_published_time":"2021-02-24T22:06:21+00:00","article_modified_time":"2021-02-25T07:42:48+00:00","og_image":[{"width":2071,"height":1448,"url":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2021\/02\/lockedin-d2670e799df5407dbce235c22ed38152.jpg","type":"image\/jpeg"}],"author":"David Baffaleuf","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"David Baffaleuf","Dur\u00e9e de lecture estim\u00e9e":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#article","isPartOf":{"@id":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/"},"author":{"name":"David Baffaleuf","@id":"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf"},"headline":"Verrous sur INSERT IGNORE en mode d’isolation par d\u00e9faut","datePublished":"2021-02-24T22:06:21+00:00","dateModified":"2021-02-25T07:42:48+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/"},"wordCount":2135,"commentCount":0,"publisher":{"@id":"https:\/\/blog.capdata.fr\/#organization"},"keywords":["deadlock","InnoDB","insert intention","lock","supremum","trigger"],"articleSection":["MySQL"],"inLanguage":"fr-FR","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/","url":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/","name":"Verrous sur INSERT IGNORE en mode d'isolation par d\u00e9faut - Capdata TECH BLOG","isPartOf":{"@id":"https:\/\/blog.capdata.fr\/#website"},"datePublished":"2021-02-24T22:06:21+00:00","dateModified":"2021-02-25T07:42:48+00:00","breadcrumb":{"@id":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.capdata.fr\/index.php\/verrous-sur-insert-ignore-insert-on-duplicate-key-update\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/blog.capdata.fr\/"},{"@type":"ListItem","position":2,"name":"Verrous sur INSERT IGNORE en mode d’isolation par d\u00e9faut"}]},{"@type":"WebSite","@id":"https:\/\/blog.capdata.fr\/#website","url":"https:\/\/blog.capdata.fr\/","name":"Capdata TECH BLOG","description":"Le blog technique sur les bases de donn\u00e9es de CAP DATA Consulting","publisher":{"@id":"https:\/\/blog.capdata.fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.capdata.fr\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/blog.capdata.fr\/#organization","name":"Capdata TECH BLOG","url":"https:\/\/blog.capdata.fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/","url":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp","contentUrl":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp","width":800,"height":254,"caption":"Capdata TECH BLOG"},"image":{"@id":"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.linkedin.com\/company\/cap-data-consulting\/mycompany\/"]},{"@type":"Person","@id":"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf","name":"David Baffaleuf","sameAs":["http:\/\/www.capdata.fr"],"url":"https:\/\/blog.capdata.fr\/index.php\/author\/dbaffaleuf\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/8538","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/comments?post=8538"}],"version-history":[{"count":11,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/8538\/revisions"}],"predecessor-version":[{"id":8561,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/8538\/revisions\/8561"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/media\/8542"}],"wp:attachment":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/media?parent=8538"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/categories?post=8538"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/tags?post=8538"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}