8.10.2. Табличные Проблемы Блокировки

Табличная блокировка позволяет многим сеансам читать из таблицы одновременно, но если сеанс хочет записать в таблицу, это должно сначала получить эксклюзивный доступ, означая, что этому, возможно, придется ожидать других сеансов, чтобы закончиться с таблицей сначала. Во время обновления должны ожидать все другие сеансы, которые хотят получить доступ к этой определенной таблице, пока обновление не делается.

Таблица, блокирующая проблемы причин, когда сеанс ожидает, потому что диск полон и свободное пространство, должна стать доступной прежде, чем сеанс сможет продолжиться. В этом случае все сеансы, которые хотят получить доступ к проблемной таблице, также помещаются в состояние ожидания, пока больше дискового пространства не делается доступным.

A SELECT оператор, который занимает много времени, чтобы работать, препятствует тому, чтобы другие сеансы обновили таблицу тем временем, заставляя другие сеансы казаться медленным или безразличным. В то время как сеанс ожидает, чтобы получить эксклюзивный доступ к таблице для обновлений, другие сеансы та проблема SELECT операторы будут стоять в очереди позади этого, уменьшая параллелизм даже для сеансов только для чтения.

Рассмотрите переключение таблицы к InnoDB механизм хранения, любое использование CREATE TABLE ... ENGINE=INNODB во время установки, или использования ALTER TABLE ... ENGINE=INNODB для существующей таблицы. См. Раздел 14.2," InnoDB Механизм хранения" для большего количества деталей об этом механизме хранения.

Оптимизировать SELECT операторы, чтобы работать быстрее так, чтобы они заблокировали таблицы в течение более короткого времени. Вам, возможно, придется создать некоторые сводные таблицы, чтобы сделать это.

Запустите mysqld с --low-priority-updates. Для механизмов хранения, которые используют только блокировку на уровне таблицы (такой как MyISAM, MEMORY, и MERGE), это дает все операторы, что обновление (изменяет) таблицу более низкий приоритет чем SELECT операторы. В этом случае, второе SELECT оператор в предыдущем сценарии выполнился бы перед UPDATE оператор, и не ожидал бы первого SELECT закончиться.

Определить, что все обновления, выпущенные в определенном соединении, должны быть сделаны с низким приоритетом, набор low_priority_updates системная переменная сервера, равная 1.

Дать определенное INSERT, UPDATE, или DELETE оператор более низкий приоритет, используйте LOW_PRIORITY атрибут.

Дать определенное SELECT оператор более высокий приоритет, используйте HIGH_PRIORITY атрибут. См. Раздел 13.2.9,"SELECT Синтаксис".

Запустите mysqld с низкой стоимости для max_write_lock_count системная переменная, чтобы вынудить MySQL временно поднять приоритет всех SELECT происходят операторы, которые ожидают таблицы после определенного числа вставок к таблице. Это разрешает READ блокировки после определенного числа WRITE блокировки.

Если у Вас есть проблемы с INSERT объединенный с SELECT, рассмотрите переключение на MyISAM таблицы, которые поддерживают параллельный SELECT и INSERT операторы. (См. Раздел 8.10.3, "Параллельные Вставки".)

Если Вы смешиваетесь, вставляет и удаляет на той же самой нетранзакционной таблице, INSERT DELAYED может помочь. См. Раздел 13.2.5.2,"INSERT DELAYED Синтаксис".

Если у Вас есть проблемы со смешанным SELECT и DELETE операторы, LIMIT опция к DELETE может помочь. См. Раздел 13.2.2,"DELETE Синтаксис".

Используя SQL_BUFFER_RESULT с SELECT операторы могут помочь сделать продолжительность блокировок таблицы короче. См. Раздел 13.2.9,"SELECT Синтаксис".

Разделение табличного содержания в отдельные таблицы может помочь, позволяя запросы работать против столбцов в одной таблице, в то время как обновления ограничиваются столбцами в различной таблице.

Вы могли изменить привязывающийся код mysys/thr_lock.c использовать единственную очередь. В этом случае запишите блокировки и читайте, у блокировок был бы тот же самый приоритет, который мог бы помочь некоторым приложениям.