Spec-Zone .ru
спецификации, руководства, описания, API
|
LOCK TABLEStbl_name
[[AS]alias
]lock_type
[,tbl_name
[[AS]alias
]lock_type
] ...lock_type
: READ [LOCAL] | [LOW_PRIORITY] WRITEUNLOCK TABLES
MySQL позволяет клиентским сеансам получить блокировки таблицы явно с целью сотрудничества с другими сеансами для доступа к таблицам, или препятствовать тому, чтобы другие сеансы изменили таблицы в течение периодов, когда сеанс требует эксклюзивного доступа к ним. Сеанс может получить или выпустить блокировки только для себя. Один сеанс не может получить блокировки для другого сеанса или выпустить блокировки, сохраненные другим сеансом.
Блокировки могут использоваться, чтобы эмулировать транзакции или получить больше скорости, обновляя таблицы. Это объясняется более подробно позже в этом разделе.
LOCK TABLES
явно получает блокировки таблицы для текущего клиентского сеанса.
Блокировки таблицы могут быть получены за базовые таблицы или представления. Вы должны иметь LOCK TABLES
полномочие, и SELECT
полномочие для каждого объекта, который будет заблокирован.
Для блокировки представления, LOCK
TABLES
добавляют все базовые таблицы, привыкшие в представлении к набору таблиц, которые будут
заблокированы, и блокируют их автоматически. Если Вы блокируете таблицу явно с LOCK TABLES
, любые таблицы, используемые в триггерах, также блокируются
неявно, как описано в Разделе 13.3.5.2,"LOCK TABLES
и Триггеры".
UNLOCK TABLES
явно выпуски любые блокировки таблицы сохранены текущим сеансом. LOCK TABLES
неявно выпуски любые блокировки таблицы, сохраненные текущим сеансом
прежде, чем получить новые блокировки.
Другое использование для UNLOCK
TABLES
должен выпустить глобальную блокировку чтения, полученную с FLUSH TABLES WITH READ LOCK
оператор, который позволяет Вам заблокировать все
таблицы во всех базах данных. См. Раздел
13.7.6.3,"FLUSH
Синтаксис". (Это - очень удобный способ получить
резервные копии, если у Вас есть файловая система, такая как Veritas, который может взять снимки вовремя.)
Блокировка таблицы защищает только от несоответствующих чтений или записей другими сеансами. Сеанс, содержащий
блокировку, даже блокировка чтения, может выполнить операции на уровне таблицы такой как DROP TABLE
. Усеченные операции не безопасны от транзакции, таким образом,
ошибка происходит, если сеанс пытается один во время активной транзакции или содержа блокировку таблицы.
Следующее обсуждение применяется только к не -TEMPORARY
таблицы. LOCK TABLES
разрешается (но игнорируется) для a TEMPORARY
таблица. К таблице может получить доступ свободно сеанс, в пределах
которого она создавалась, независимо от того, чем другая блокировка может быть в действительности. Никакая
блокировка не необходима, потому что никакой другой сеанс не может видеть таблицу.
Для получения информации о других условиях на использовании LOCK TABLES
и операторы, которые не могут использоваться в то время как LOCK TABLES
в действительности, см. Раздел
13.3.5.3, "Блокирующие таблицу Ограничения и Условия"
Правила для Сбора Блокировки
Чтобы получить блокировки таблицы в пределах текущего сеанса, используйте LOCK TABLES
оператор. Следующие типы блокировки доступны:
READ [LOCAL]
блокировка:
Сеанс, который содержит блокировку, может считать таблицу (но не записать это).
Многократные сеансы могут получить a READ
блокировка
для таблицы одновременно.
Другие сеансы могут считать таблицу, явно не получая a READ
блокировка.
LOCAL
модификатор позволяет неконфликтовать INSERT
операторы (параллельные вставки) другими сеансами, чтобы выполниться, в то время как блокировка
сохранена. (См. Раздел 8.10.3, "Параллельные
Вставки".) Однако, READ LOCAL
не может использоваться, если Вы
собираетесь управлять процессами использования базы данных, внешними к серверу, в то время как Вы
содержите блокировку. Для InnoDB
таблицы, READ
LOCAL
то же самое как READ
.
[LOW_PRIORITY] WRITE
блокировка:
Сеанс, который содержит блокировку, может считать и записать таблицу.
Только сеанс, который содержит блокировку, может получить доступ к таблице. Никакой другой сеанс не может получить доступ к этому, пока блокировка не выпускается.
Блокировка запрашивает на таблицу другим блоком сеансов в то время как WRITE
блокировка сохранена.
LOW_PRIORITY
модификатор не имеет никакого эффекта. В
предыдущих версиях MySQL это влияло на поведение при блокировании, но это больше не истина. С MySQL
5.6.5 это осуждается, и его использование производит предупреждение. Использовать WRITE
без LOW_PRIORITY
вместо этого.
Если LOCK TABLES
оператор должен ожидать из-за блокировок, сохраненных другими сеансами на любой из таблиц, он блокирует, пока
все блокировки не могут быть получены.
Сеанс, который требует блокировок, должен получить все блокировки, в которых требуется в сингле LOCK TABLES
оператор. В то время как блокировки, таким образом полученные,
сохранены, сеанс может получить доступ только к заблокированным таблицам. Например, в следующей
последовательности операторов, ошибка происходит для попытки получить доступ t2
потому что это не было привязано LOCK
TABLES
оператор:
mysql>LOCK TABLES t1 READ;
mysql>SELECT COUNT(*) FROM t1;
+----------+| COUNT(*) |+----------+| 3 |+----------+mysql>SELECT COUNT(*) FROM t2;
ERROR 1100 (HY000): Table 't2' was not locked with LOCK TABLES
Таблицы в INFORMATION_SCHEMA
база данных является исключением. К ним можно получить
доступ, не будучи заблокированным явно даже, в то время как сеанс содержит блокировки таблицы, полученные с LOCK TABLES
.
Невозможно обратиться к заблокированной таблице многократно в единственном запросе, используя то же самое имя. Используйте псевдонимы вместо этого, и получите отдельную блокировку для таблицы и каждого псевдонима:
mysql>LOCK TABLE t WRITE, t AS t1 READ;
mysql>INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLESmysql>INSERT INTO t SELECT * FROM t AS t1;
Ошибка происходит для первого INSERT
потому что есть две ссылки на то же самое имя для заблокированной таблицы.
Второе INSERT
успешно выполняется, потому что ссылки на таблицу используют различные
имена.
Если Ваши операторы обращаются к таблице посредством псевдонима, следует заблокировать таблицу, используя тот же самый псевдоним. Это не работает, чтобы заблокировать таблицу, не определяя псевдоним:
mysql>LOCK TABLE t READ;
mysql>SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
Наоборот, если Вы блокируете таблицу, используя псевдоним, следует обратиться к этому в Ваших операторах, используя тот псевдоним:
mysql>LOCK TABLE t AS myalias READ;
mysql>SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLESmysql>SELECT * FROM t AS myalias;
WRITE
у блокировок обычно есть более высокий приоритет чем READ
блокировки, чтобы гарантировать, что обновления обрабатываются как можно скорее. Это означает это, если один
сеанс получает a READ
блокировка и затем другой сеанс запрашивают a WRITE
блокировка, последующая READ
запросы
блокировки ожидают до сеанса, который запрашивал WRITE
блокировка получила
блокировку и выпустила ее.
LOCK TABLES
получает блокировки следующим образом:
Вид все таблицы, которые будут заблокированы во внутренне определенном порядке. С пользовательской точки зрения этот порядок неопределен.
Если таблица должна быть заблокирована с чтением и блокировкой записи, поместите запрос блокировки записи перед запросом блокировки чтения.
Заблокируйте одну таблицу за один раз, пока сеанс не получает все блокировки.
Эта политика гарантирует, что табличная блокировка является свободной мертвой блокировкой.
LOCK TABLES
или UNLOCK TABLES
, когда
применено к разделенная таблица, всегда блокирует или разблокировала всю таблицу; эти операторы не
поддерживают сокращение блокировки раздела. См. Раздел 18.6.4,
"Деля и Блокируя".
Правила для Выпуска Блокировки
Когда блокировки таблицы, сохраненные сеансом, выпускаются, они все выпускаются одновременно. Сеанс может выпустить свои блокировки явно, или блокировки могут быть выпущены неявно при определенных условиях.
Сеанс может выпустить свои блокировки явно с UNLOCK TABLES
.
Если сеанс проблемы a LOCK TABLES
оператор уже, чтобы получить блокировку, в то время как
фиксаторы, ее существующие блокировки выпускаются неявно прежде, чем новые блокировки предоставляют.
Если сеанс начинает транзакцию (например, с START TRANSACTION
), неявное UNLOCK TABLES
выполняется, который заставляет существующие блокировки
быть выпущенными. (Для дополнительной информации о взаимодействии между табличной блокировкой и
транзакциями, см. Раздел 13.3.5.1,
"Взаимодействие Табличной Блокировки и Транзакций".)
Если соединение для клиентского сеанса завершается, или обычно или неправильно, сервер неявно выпускает все блокировки таблицы, сохраненные сеансом (транзакционный и нетранзакционный). Если клиент повторно соединится, то блокировки больше не будут в действительности. Кроме того, если у клиента была активная транзакция, сервер откатывает транзакцию на разъединение, и если повторно соединяются, происходит, новый сеанс начинается с включенной автоматической фиксации. Поэтому клиенты могут хотеть отключить, % автоповторно соединяются. С % автоповторно соединяются в действительности, клиент не уведомляется, если повторно соединяются, происходит, но любые блокировки таблицы, или текущая транзакция будет потеряна. С % автоповторно соединяются отключенный, если соединение отбрасывает, ошибка происходит для следующего сделанного заявления. Клиент может обнаружить ошибку и принять соответствующие меры, такие как переполучение блокировок или восстановления транзакция. См. Раздел 22.8.16, "Управляя Автоматическим Поведением Пересоединения".
Если Вы используете ALTER TABLE
на заблокированной таблице это может стать разблокированным. Например, если Вы делаете попытку секунды ALTER TABLE
работа, результатом может быть ошибка Table
'
. Чтобы
обработать это, заблокируйте таблицу снова до второго изменения. См. также Раздел
C.5.7.1, "Проблемы с tbl_name
' was not locked with LOCK TABLESALTER TABLE
".