MySQL получает длинные семафорные блокировки на dict0dict.cc - но на операциях DML

Контекст:

Есть таблица с 2 столбцами целочисленного идентификатора столбца - автоинкремент первичного ключа и длинный текстовый столбец.

Строки одновременно добавляются, считываются и удаляются из этой таблицы многими различными процессами и соединениями. Нет никаких заявлений DDL вообще. Просто вставьте, выберите и удалите - и каждая операция выполняется не более чем в 1 строке. т.е. вставляет одну строку, выбирает одну строку по первичному ключу, а затем удаляет одну строку также по первичному ключу.

Таблица является единственной таблицей в экземпляре mysql (она находится в контейнере Docker).

В таблице мало заполненных строк, размер файла ibd составляет 199G.

проблема

Часто я вижу семафорные замки, подобные этим

--Thread 140441749952256 has waited at btr0cur.cc line 545 for 249.00 seconds the semaphore:
S-lock on RW-latch at 0x4fcb428 created in file dict0dict.cc line 2606
a writer (thread id 140441750218496) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file btr0cur.cc line 545

Иногда блокировка держится более 600 с, и innodb намеренно падает.

Глядя на код для 5.6.26 - функция в dict0dict

Adds an index to the dictionary cache.
@return DB_SUCCESS, DB_TOO_BIG_RECORD, or DB_CORRUPTION */
UNIV_INTERN
dberr_t
dict_index_add_to_cache(

И конкретно:

rw_lock_create(index_tree_rw_lock_key, &new_index->lock,
               dict_index_is_ibuf(index)
               ? SYNC_IBUF_INDEX_TREE : SYNC_INDEX_TREE);

Вопрос

Что вызывает эти замки?

До сих пор пробовал

  • Видя, что это противоречие между курсором b-дерева и словарями и некоторыми исследованиями, я отключил адаптивную индексацию хешей. Проблема все еще сохраняется.
  • Затем увеличил буферный пул со 128М по умолчанию до 1G. Проблема все еще сохраняется.

Поскольку таблица занята, я не хотел оптимизировать таблицу, но в случае, если это ответ - я хотел бы знать, почему.

0 ответов

Другие вопросы по тегам