Pourquoi les mises à jour simples du «_edit_lock» de wp_postmeta sont-elles si lentes?

Dans notre journal des requêtes lentes MySQL, la requête cumulativement la plus lente est une simple mise à jour de wp_postmeta. Voici un exemple:

UPDATE `wp_postmeta`
  SET `meta_value` = '1392835505:386'
  WHERE `post_id` = 94705 AND `meta_key` = '_edit_lock';

Détails pertinents sur notre configuration:

• Temps de requête lent MySQL défini sur 1 s
• Le moteur de stockage de wp_postmeta est InnoDB
• Fonctionnant dans une grande installation multisite avec des dizaines de milliers de messages sur le blog principal de WP (où ces requêtes lentes se produisent)
• Forte activité dans la zone d'administration de WP (beaucoup d'écrivains / éditeurs travaillant simultanément, mais généralement sur leur propre contenu (pas sur celui des autres))
• Faible activité du côté public de WP (ne servant pas réellement le contenu du blog principal)
• Les requêtes lentes semblent toutes utiliser la touche "_edit_lock"; les requêtes du même format (qui utilisent une clé autre que "_edit_lock") ne semblent pas être lentes.

Pourquoi est-ce la requête la plus lente sur notre système? Cela a-t-il quelque chose à voir avec l'utilisation spécifique par WP des «verrous d'édition»?

Merci! :)

Mise à jour: sortie de mysqlsla ci-dessous:

______________________________________________________________________ 001 ___
Count         : 606  (16.83%)
Time          : 2257.760468 s total, 3.725677 s avg, 1.00512 s to 84.645869 s max  (20.60%)
  95% of Time : 1355.289277 s total, 2.357025 s avg, 1.00512 s to 12.343604 s max
Lock Time (s) : 182.502 ms total, 301 μs avg, 29 μs to 157.542 ms max  (0.21%)
  95% of Lock : 22.882 ms total, 40 μs avg, 29 μs to 57 μs max
Rows sent     : 0 avg, 0 to 0 max  (0.00%)
Rows examined : 1 avg, 1 to 2 max  (0.00%)
Database      : xxx_wp
Users         :
        xxx_wp@localhost  : 98.84% (599) of query, 51.03% (1837) of all users
        yyy_wp@localhost  : 1.16% (7) of query, 0.94% (34) of all users

Query abstract:
SET timestamp=N; UPDATE wp_postmeta SET meta_value = 'S' WHERE post_id = N AND meta_key = 'S';

Query sample:
SET timestamp=1392835506;
UPDATE `wp_postmeta` SET `meta_value` = '1392835505:386' WHERE `post_id` = 94705 AND `meta_key` = '_edit_lock';

le _edit_lock est généré chaque fois que vous modifiez un article ou une page. il s'agit du timecode et de l'utilisateur. WordPress sait donc qui le modifie actuellement.

meta_id     post_id     meta_key    meta_value
9           5           _edit_lock  1388386997:1

si vous le manipulez, WordPress réagit d'une manière ou d'une autre sensible ... J'ai essayé de récupérer combien de secondes quelqu'un a travaillé sur un post. Tout le temps, cela cassait le temps de chargement de ma base de données.

Comme vous l'avez dit, vous exécutez cela sur un grand multisite. Je ne sais pas combien d'utilisateurs écrivent des articles là-bas, mais cela pourrait certainement casser la mémoire RAM du serveur si de nombreuses personnes modifiaient un article en même temps.

Une solution pourrait être: se débarrasser de _edit_lock

Comment désactiver le "Post Lock / Edit Lock"?

Normalement, WordPress devrait avoir un "_edit_lock" par publication. Certaines bases de données ont du mal à les générer à chaque fois.

Comme ce gars http://wordpress.org/support/topic/can-i-remove-_edit_lock-_edit_last-from-wp_postmeta

Sa solution était de les supprimer tous. Pour l'accélérer, vous pouvez les supprimer tous les soirs à 3 heures dans phpMyAdmin avec

DELETE FROM `yourdb`.`wp_postmeta` WHERE `wp_postmeta`.`meta_key` = '_edit_lock'

peut-être que vous trouvez un travail cron qui fait exactement cela.

essaye ça :)

UPDATE `wp_postmeta` 
    SET `meta_value` = concat(unix_timestamp(),':386')  
    WHERE `post_id`  = 94705 
      AND `meta_key` = '_edit_lock';