Как WordPress обрабатывает ошибки блокировки строк MySQL?

Если есть плагин WordPress, который обновляет строки в пользовательской таблице, но это обновление встречает блокировку строк, что происходит? Например, два пользователя одновременно запускают обновление в TABLE1, один параметр AGE = 1, а другой параметр AGE = 2:

  • Будет ли блокировка строк вообще?
  • Будет ли MySQL обрабатывать это «изящно», и одно из двух обновлений просто «потеряно»?
  • WordPress обрабатывает его изящно?
  • Нужно ли мне позаботиться об этом в плагине?

Данные не очень важны, так как мне не нужно отслеживать каждое изменение. Но мне нужно обрабатывать любые ошибки, которые могут возникнуть.

Solutions Collecting From Web of "Как WordPress обрабатывает ошибки блокировки строк MySQL?"

Строго из точки зрения MySQL

УКОРОЧЕННАЯ ВЕРСИЯ

MyISAM Storage Engine

  • Столовые замки
  • Сначала пишут, сначала подают
  • Считывает замедление записи от инициирования

Двигатель хранения InnoDB

  • Строчные замки
  • Транзакции (без блокировки)
  • При обновлении индексов может возникать взаимоблокировка

ДОЛГОСРОЧНАЯ

Если базовые таблицы используют MyISAM Storage Engine , блокировки строк невозможны. Каждый оператор DML (INSERT, UPDATE и DELETE) вызывает полную блокировку таблицы.

Если 50 соединителей DB попытаются обновить строку mydb.mytable в mydb.mytable

  • 1 блокировка таблицы, 1 обновление, 49 DB Подключения ждут
  • 1 блокировка таблицы, 1 обновление, 48 DB Connections wait
  • 1 блокировка таблицы, 1 обновление, 47 DB Подключения ждут
  • 1 блокировка таблицы, 1 обновление, 02 DB Подключения ждут
  • 1 блокировка таблицы, 1 обновление, 01 DB Подключения ждут

Получить картину? Вы можете увидеть, где узкое место может возникнуть только на одном столе. Теперь представьте, что сайт WordPress сильно пострадал. SELECT получают приоритет над утверждениями DML (исключение будет одновременным INSERT на таблицах MyISAM, если таблица MyISAM имеет только SELECT и INSERT, без промежутков между ними). Сотни или даже десятки SELECT в промежутках между заявлениями DML могут замедлить вышеупомянутое узкое место еще больше.

Спасительная изящество MyISAM на сильно пострадавшем сайте WordPress заключается в том, что взаимоблокировки никогда не могут произойти.

Если базовые таблицы используют InnoDB Storage Engine , блокировки строк (даже в одной строке) никогда не могут блокировать чтение, но во время записи все еще возможны блокировки. Если AUTOCOMMIT=0 установлен в /etc/my.cnf, каждый оператор DML (INSERT, UPDATE и DELETE) будет выполнен как транзакция с одной строкой. Выпускаются отдельные блокировки строк. Таким образом, 50 DB Connections могут идти после 50 разных строк и ничего трагичного не происходит.

Где могут возникнуть взаимоблокировки?

Поскольку PRIMARY KEY таблиц InnoDB содержится в кластерном индексе (внутренне известном как gen_clust_index) , данные строки тесно связаны с индексами. Любой индекс, сделанный против столбцов, не входящих в PRIMARY KEY, каталогизируется с двумя основными элементами: 1) значением столбца и 2) ключом gen_clust_index. Время от времени обновление индексированных столбцов в InnoDB может привести к тому, что я в шутку вызываю индексный запор. Это происходит, когда две или более блокировок генерируются в записях индекса, хранящихся близко друг к другу. Это возможно на веб-сайте с большой нагрузкой.

Однажды я помог разработчику понять, почему это может произойти в DBA StackExchange. Этот разработчик впоследствии изменил код. Здесь были те сообщения:

  • Будут ли эти два запроса привести к тупиковой ситуации, если они будут выполняться последовательно?
  • Проблема дешифрования блокировки в журнале состояния innodb
  • Причины иногда медленных запросов?

ВАШ ВОПРОС

Одно из обновлений будет потеряно независимо от механизма хранения. Только последнее UPDATE в столбце устанавливает окончательное значение.

ВЫВОД

Этот пост не подходит ни для Storage Engine. Это просто факты о том, что может и произойдет при написании таблиц.