Spec-Zone .ru
спецификации, руководства, описания, API
|
InnoDB
таблицы используют блокировку на уровне строки так, чтобы многократные сеансы
и приложения могли читать из и записать в ту же самую таблицу одновременно, не делая друг друга ожидать или
приведение к непоследовательным результатам. Для этого механизма хранения избегайте использования LOCK TABLES
оператор, потому что это не предлагает дополнительной защиты, но вместо этого уменьшает параллелизм.
Автоматическая блокировка на уровне строки делает эти таблицы подходящими для Ваших самых занятых баз данных с
Вашими самыми важными данными, также упрощая логику приложения, так как Вы не должны заблокировать и
разблокировать таблицы. Следовательно, InnoDB
механизм хранения является значением
по умолчанию в MySQL 5.7.
MySQL использует табличную блокировку (вместо страницы, строки, или блокировки столбца) для всех механизмов
хранения кроме InnoDB
. У операций самой блокировки нет большого количества
издержек. Но потому что только один сеанс может записать в таблицу в любой момент для лучшей производительности
с этими другими механизмами хранения, используйте их прежде всего для таблиц, которые запрашиваются часто и
редко вставляются в или обновляются.
InnoDB
Выбирая, создать ли табличное использование InnoDB
или различный механизм хранения,
имейте в виду следующие недостатки табличной блокировки:
Табличная блокировка позволяет многим сеансам читать из таблицы одновременно, но если сеанс хочет записать в таблицу, это должно сначала получить эксклюзивный доступ, означая, что этому, возможно, придется ожидать других сеансов, чтобы закончиться с таблицей сначала. Во время обновления должны ожидать все другие сеансы, которые хотят получить доступ к этой определенной таблице, пока обновление не делается.
Таблица, блокирующая проблемы причин, когда сеанс ожидает, потому что диск полон и свободное пространство, должна стать доступной прежде, чем сеанс сможет продолжиться. В этом случае все сеансы, которые хотят получить доступ к проблемной таблице, также помещаются в состояние ожидания, пока больше дискового пространства не делается доступным.
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, "Параллельные
Вставки".)
Если у Вас есть проблемы со смешанным SELECT
и DELETE
операторы, LIMIT
опция к DELETE
может помочь. См. Раздел
13.2.2,"DELETE
Синтаксис".
Используя SQL_BUFFER_RESULT
с SELECT
операторы могут помочь сделать продолжительность блокировок
таблицы короче. См. Раздел
13.2.9,"SELECT
Синтаксис".
Разделение табличного содержания в отдельные таблицы может помочь, позволяя запросы работать против столбцов в одной таблице, в то время как обновления ограничиваются столбцами в различной таблице.
Вы могли изменить привязывающийся код mysys/thr_lock.c
использовать единственную очередь. В этом случае запишите
блокировки и читайте, у блокировок был бы тот же самый приоритет, который мог бы помочь некоторым
приложениям.