способ предотвратить запросы от ожидания блокировки на уровне таблицы

Мы столкнулись с проблемой после перемещения базы данных нашего клиента на дополнительный сервер. Это должно было оказать положительное влияние на производительность сайта, но есть проблема с блокировкой таблицы в MyISAM. (Я слышал об использовании InnoDB вместо MyISAM, но мы не можем изменить движок в ближайшем будущем).
Мы могли бы заметить это по запросу на обновление, который выполняется, когда модератор активирует комментарий на сайте. Это процесс:

• обработан запрос на обновление SET status = 1 WHERE id = 5(индекс установлен)
• кэшированные файлы страницы удалены

На этом этапе вся страница становится медленной. Сама база данных занята в течение нескольких минут. Я получил список процессов несколько раз и увидел около 60 записей различных запросов выбора, которые все находились в состоянии ожидания блокировки на уровне таблицы .

1. Я не понимаю, почему это обновление таблицы article_commentsможет повлиять на операторы выбора для таблицы, ожидающей articleблокировки на уровне таблицы. В списке процессов почти все ожидающие запросы были из этой таблицы. Я читал о том, что обновления / вставки предпочтительнее, чем выбор, и что это может вызвать такие проблемы, но сама таблица статей не обновляется при активации комментариев, поэтому выбор не должен ждать. Я неправильно понял это?
2. Есть ли что-то кроме изменения InnoDB, чтобы предотвратить это поведение или, по крайней мере, получить лучший баланс? Меня очень раздражает тот факт, что эта проблема не появилась до переноса базы данных на новый сервер. Я предполагаю, что есть некоторая неправильная конфигурация, но я не знаю, как идентифицировать.

MyISAM Storage Engine чрезвычайно известен тем, что выполняет полные блокировки таблиц для любого DML (INSERT, UPDATEs, DELETEs). InnoDB определенно решит эту проблему в долгосрочной перспективе.

Я писал о плюсах и минусах использования MyISAM против InnoDB

• InnoDB против MyISAM со многими индексами (5 июля 2012 г.)
• Что быстрее, InnoDB или MyISAM? (3 мая 2012 г.)
• Есть ли какие-либо проблемы с преобразованием из MyISAM в InnoDB? (09 января 2012 г.)
• Должен ли я использовать механизм хранения, отличный от MyISAM, для оптимизации этих таблиц или лучше получить диски? (07 октября 2011 г.)
• Преимущества блокировки на уровне стола (14 сентября 2011 г.)
• Каковы основные различия между InnoDB и MyISAM? (14 апреля 2011 г.)

Что касается вашего текущего вопроса, вот возможный сценарий:

• articleи article_commentsобе таблицы MyISAM
• article_commentsимеет один или несколько индексов statusв качестве столбца
• Обновления страницы индекса для article_commentsкэшируются в буфере ключа MyISAM (размер по ключу key_buffer_size ), в результате чего старые страницы индекса выходят из буфера ключа MyISAM
• У вас есть запросы SELECT, которые выполняют соединения между articleиarticle_comments

В моем предложенном сценарии SELECTs для articleтаблицы могут быть запрещены для записи из-за необходимости ждать article_commentsосвобождения от любого DML (в данном случае, an UPDATE)

На этом этапе вся страница становится медленной. Сама база данных занята в течение нескольких минут.

Пахнет, как будто у тебя большой Query_cache?

mysql> SHOW VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 | -- Not over 50M
| query_cache_type             | DEMAND   | -- Only if using SQL_CACHE
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

Для производственных систем с большим количеством записей вы также можете отключить query_cache.

Все записи в query_cache для данной таблицы очищаются при любой записи в эту таблицу. Чем больше КК, тем медленнее эта задача.

MyISAM использует блокировки на уровне таблицы. Чтение и запись не могут происходить одновременно (в одной таблице). Грубый, но эффективный.