СУБД/лекция 4 семестр 2 - История изменений

Vidokq: /* Синтаксис LOCK TABLES, UNLOCK TABLES */

2014-03-10T11:59:42Z

‎Синтаксис LOCK TABLES, UNLOCK TABLES

Vidokq: /* Синтаксис LOCK TABLES, UNLOCK TABLES */

2014-03-10T11:58:58Z

‎Синтаксис LOCK TABLES, UNLOCK TABLES

Vidokq: /* Синтаксис LOCK TABLES, UNLOCK TABLES */

2014-03-10T11:57:52Z

‎Синтаксис LOCK TABLES, UNLOCK TABLES

Vidokq: /* Синтаксис LOCK TABLES, UNLOCK TABLES */

2014-03-10T11:56:01Z

‎Синтаксис LOCK TABLES, UNLOCK TABLES

Vidokq: /* Синтаксис LOCK TABLES, UNLOCK TABLES */

2014-03-10T11:48:42Z

‎Синтаксис LOCK TABLES, UNLOCK TABLES

Vidokq: /* Пример */

2014-03-10T11:41:51Z

‎Пример

Vidokq: /* Пример */

2014-03-10T11:41:15Z

‎Пример

Vidokq: /* Синтаксис SET TRANSACTION */

2014-03-10T11:40:47Z

‎Синтаксис SET TRANSACTION

Vidokq: /* Синтаксис SET TRANSACTION */

2014-03-10T11:33:50Z

‎Синтаксис SET TRANSACTION

Vidokq: /* Синтаксис LOCK TABLESи UNLOCK TABLES */

2014-03-10T11:28:38Z

‎Синтаксис LOCK TABLESи UNLOCK TABLES

@@ Строка 70: / Строка 70: @@
   ERROR 1100: Table t was not locked with LOCK TABLES
 <source lang="sql">
 SELECT * FROM t AS myalias;</source>

@@ Строка 59: / Строка 59: @@
 * Если ваш запрос обращается к таблице через псевдоним, вы должны блокировать таблицу, используя тот же псевдоним. Блокировка таблицы не будет работать, если не указан псевдоним:
-<source lang="sql">LOCK TABLE READ;
+<source lang="sql">
- SELECT * FROM t AS myalias;</source>
+LOCK TABLE READ;
   ERROR 1100: Table 'myalias1 was not locked with LOCK TABLES
@@ Строка 66: / Строка 67: @@
 <source lang="sql">
 LOCK TABLE t AS myalias READ;
- SELECT * t;</source>
+SELECT * t;</source>
   ERROR 1100: Table t was not locked with LOCK TABLES
-<source lang="sql">SELECT * FROM t AS myalias;</source>
+<source lang="sql">
 Блокировки по записи (WRITE) обычно имеют более высокий приоритет, чем блокировки по чтению (READ), чтобы гарантировать, что обновления данных пройдут как можно быстрее. Это означает, что если один поток получает блокировку по чтению, а затем другой поток запрашивает блокировку по записи, то последующие запросы на блокировку по чтению будут ожидать, пока не будет установлена и снята блокировка по записи.
@@ Строка 92: / Строка 94: @@
 Если вы используете механизм хранения MySQL, которые не поддерживает транзакций, вы должны выдавать LOCK TABLES, если хотите гарантировать, что между SELECT и UPDATE не будут выданы другие операторы. Приведенный ниже пример требует LOCK TABLES для безопасного выполнения:
-<source lang="sql">LOCKTABLEStransREAD,customerWRITE;
+<source lang="sql">
   SELECT SUM(value) FROM trans WHERE customer_2.6.=идентификатор;
   UPDATE customer

@@ Строка 63: / Строка 63: @@
   ERROR 1100: Table 'myalias1 was not locked with LOCK TABLES
-* И наоборот, если таблица блокирована по псевдониму, вы должны обращаться к ней, используя этот псевдоним:
+  ERROR 1100: Table t was not locked with LOCK TABLES
-<source lang="sql">LOCK TABLE t AS myalias READ;
- SELECT * ШЖ t;</source>
-  ERROR 1100: Table Ч1 was not locked with LOCK TABLES
 <source lang="sql">SELECT * FROM t AS myalias;</source>
@@ Строка 77: / Строка 78: @@
 * Если таблица блокируется и по чтению и по записи, устанавливается блокировка записи перед блокировкой чтения.
 * Блокируется по одной таблице за раз до тех пор, пока поток не получит все блокировки.
 Эта политика гарантирует, что при этом не случится взаимных блокировок (deadlocks). Существуют, однако, и другие обстоятельства в отношении этой политики, которые следует принимать во внимание.
 * Если вы используете блокировку LOW_PRIORITY WRITE для таблицы, это означает только, что MySQL будет ожидать момента, когда не будет ни одного потока, который желает установить блокировку чтения.

@@ Строка 64: / Строка 64: @@
-И наоборот, если таблица блокирована по псевдониму, вы должны обращаться к ней, используя этот псевдоним:
+* И наоборот, если таблица блокирована по псевдониму, вы должны обращаться к ней, используя этот псевдоним:
- <source lang="sql">LOCK TABLE t AS myalias READ;
+<source lang="sql">LOCK TABLE t AS myalias READ;
   SELECT * ШЖ t;</source>
   ERROR 1100: Table Ч1 was not locked with LOCK TABLES
- <source lang="sql">SELECT * FROM t AS myalias;</source>
+<source lang="sql">SELECT * FROM t AS myalias;</source>
 Блокировки по записи (WRITE) обычно имеют более высокий приоритет, чем блокировки по чтению (READ), чтобы гарантировать, что обновления данных пройдут как можно быстрее. Это означает, что если один поток получает блокировку по чтению, а затем другой поток запрашивает блокировку по записи, то последующие запросы на блокировку по чтению будут ожидать, пока не будет установлена и снята блокировка по записи. Вы можете использовать блокировки по записи с пониженным приоритетом (LOW_PRIORITY WRITE), чтобы позволить другим потокам устанавливать блокировки по чтению, пока текущий поток ожидает возможности поставить блокировку по записи. Вы должны устанавливать блокировки LOW_PRIORITY WRITE только тогда, когда уверены, что в процессе работы сервера будет время, когда ни один из потоков не будет удерживать блокировки по чтению.
-LOCK TABLES работает следующим образом:
+Блокировки по записи (WRITE) обычно имеют более высокий приоритет, чем блокировки по чтению (READ), чтобы гарантировать, что обновления данных пройдут как можно быстрее. Это означает, что если один поток получает блокировку по чтению, а затем другой поток запрашивает блокировку по записи, то последующие запросы на блокировку по чтению будут ожидать, пока не будет установлена и снята блокировка по записи.
 В определенном внутреннем порядке сортируются все таблицы, подлежащие блокировке. С точки зрения пользователя, этот порядок не определен.
-Если таблица блокируется и по чтению и по записи, устанавливается блокировка записи перед блокировкой чтения.
+Вы можете использовать блокировки по записи с пониженным приоритетом (LOW_PRIORITY WRITE), чтобы позволить другим потокам устанавливать блокировки по чтению, пока текущий поток ожидает возможности поставить блокировку по записи. Вы должны устанавливать блокировки LOW_PRIORITY WRITE только тогда, когда уверены, что в процессе работы сервера будет время, когда ни один из потоков не будет удерживать блокировки по чтению. '''LOCK TABLES''' работает следующим образом:
-Блокируется по одной таблице за раз до тех пор, пока поток не получит все блокировки.
+* В определенном внутреннем порядке сортируются все таблицы, подлежащие блокировке.
 Эта политика гарантирует, что при этом не случится взаимных блокировок (deadlocks). Существуют, однако, и другие обстоятельства в отношении этой политики, которые следует принимать во внимание.
-Если вы используете блокировку LOW_PRIORITY WRITE для таблицы, это означает только, что MySQL будет ожидать момента, когда не будет ни одного потока, который желает установить блокировку чтения. Когда потоку удается установить блокировку записи одной таблицы, и он ожидает возможности заблокировать следующую таблицу в списке, все остальные потоки будут приостановлены до тех пор, пока блокировка записи не будет снята. Если это представляет серьезную проблему для ваших приложений, вы должны рассмотреть возможность преобразования некоторых ваших таблиц в нетран-закционную форму.
+* Если вы используете блокировку LOW_PRIORITY WRITE для таблицы, это означает только, что MySQL будет ожидать момента, когда не будет ни одного потока, который желает установить блокировку чтения.
-Можно безопасно использовать KILL для прерывания потока, который ожидает блокировки таблицы. См. раздел 6.5.4.3.
+* Когда потоку удается установить блокировку записи одной таблицы, и он ожидает возможности заблокировать следующую таблицу в списке, все остальные потоки будут приостановлены до тех пор, пока блокировка записи не будет снята.
-Заметьте, что вы не должны блокировать никаких таблиц из тех, в которых выполняете INSERT DELAYED, потому что в этом случае INSERT выполняется отдельным потоком сервера.
+* Если это представляет серьезную проблему для ваших приложений, вы должны рассмотреть возможность преобразования некоторых ваших таблиц в не транзакционную форму.
 Обычно вам не нужно блокировать таблицы, поскольку все отдельные операторы INSERT атомарны - то есть никакой другой поток не может вмешаться в исполняемый в данный момент SQL-оператор. Однако существуют случаи, когда блокировать таблицы все же необходимо:
-Если вы собираетесь выполнять множество операций над набором таблиц MyISAM, то гораздо быстрее получится, если их предварительно заблокировать. Блокировка таблиц MyISAM ускоряет вставку, обновление или удаление в них. Отрицательная сторона этого состоит в том, что ни один поток не может обновлять заблокированную по чтению таблицу (включая тот, что установил блокировку), и ни один поток не может получить никакого доступа к таблице, заблокированной по записи, кроме потока, установившего блокировку.
+* Если вы собираетесь выполнять множество операций над набором таблиц MyISAM, то гораздо быстрее получится, если их предварительно заблокировать.
-Причина того, что некоторые операции MylSAM работают быстрее на блокированных таблицах, связана с тем, что MySQL не сбрасывает на диск индексный кэш для этих таблиц до тех пор, пока не будет вызван UNLOCK TABLES. Обычно индексные кэши сбрасываются после каждого SQL-оператора.
+** {{V|24px}}Блокировка таблиц MyISAM ускоряет вставку, обновление или удаление в них.
 Если вы используете механизм хранения MySQL, которые не поддерживает транзакций, вы должны выдавать LOCK TABLES, если хотите гарантировать, что между SELECT и UPDATE не будут выданы другие операторы. Приведенный ниже пример требует LOCK TABLES для безопасного выполнения:
- <source lang="sql">LOCKTABLEStransREAD,customerWRITE;
+<source lang="sql">LOCKTABLEStransREAD,customerWRITE;
   SELECT SUM(value) FROM trans WHERE customer_2.6.=идентификатор;
   UPDATE customer
@@ Строка 89: / Строка 98: @@
   WHERE сизЬотег_1<к=идентификатор;
   UNLOCK TABLES; </source>
 Без LOCK TABLES существует возможность того, что другой поток может вставить новую строку в таблицу trans между выполнением ваших операторов SELECT и UPDATE.
-Вы можете избежать применения LOCK TABLES во многих случаях, применяя относительные обновления (UPDATE customer SET value=value+new_value), либо функцию LAST_INSERT_ID(). См. раздел Транзакции и атомарные операции
+Вы можете избежать применения LOCK TABLES во многих случаях, применяя относительные обновления (
-Избежать блокировки таблиц можно также в некоторых случаях, используя функции пользовательского уровня GET_LOCK () и RELEASE_LOCK (). Эти блокировки сохраняются в хэш-таблице на сервере и для скорости реализуются вызовами pthread_mutex_lock() и pthread_mutex_unlock(). См. раздел Различные функции
+<source lang="sql">
-Вы можете заблокировать по чтению все таблицы во всех базах данных оператором flush tables with read LOCK. См. разделСинтаксис LOCK TABLES и UNLOCK TABLES Это очень удобный способ получить резервные копии, если вы работаете с файловой системой вроде Veritas, которая может делать снимки во времени.
+UPDATE customer SET value=value+new_value)
-%Назаметку! Если вы используете ALTER TABLE на блокированной таблице, она может разблокироваться. См. раздел Проблемы с ALTER TABLE
+LAST_INSERT_ID()</source>
 === Синтаксис SET TRANSACTION ===

@@ Строка 45: / Строка 45: @@
 [, имя_таблицы[AS псевдоним] {READ [LOCAL] | [LOW_PRIORITY] WRITE}] ...
 UNLOCK TABLES</source>
-LOCK TABLES блокирует таблицы для текущего потока сервера. UNLOCK TABLES снимает любые блокировки, удерживаемые текущим потоком. Все таблицы, заблокированные в текущем потоке, неявно разблокируются, когда поток выполняет другой оператор LOCK TABLES либо когда закрывается соединение с сервером.
+* LOCK TABLES блокирует таблицы для текущего потока сервера.
-На заметку!
+* UNLOCK TABLES снимает любые блокировки, удерживаемые текущим потоком. Все таблицы, заблокированные в текущем потоке, неявно разблокируются, когда поток выполняет другой оператор LOCK TABLES либо когда закрывается соединение с сервером.
-LOCK TABLES не является оператором, безопасным в отношении транзакций, и неявно завершает транзакцию перед попыткой блокировать таблицы.
+* {{X|24px}}LOCK TABLES не является оператором, безопасным в отношении транзакций, и неявно завершает транзакцию перед попыткой блокировать таблицы.
-Начиная с версии MySQL 4.0.2, для того, чтобы выполнять LOCK TABLES, необходимо иметь привилегию LOCK TABLES и привилегию SELECT для соответствующих таблиц. В MySQL 3.23 необходимо иметь привилегии SELECT, INSERT, DELETE и UPDATE для этих таблиц.
+Начиная с версии MySQL 4.0.2, для того, чтобы выполнять '''LOCK TABLES''', необходимо иметь привилегию '''LOCK TABLES''' и привилегию '''SELECT''' для соответствующих таблиц. В MySQL 3.23 необходимо иметь привилегии '''SELECT, INSERT, DELETE и UPDATE''' для этих таблиц.
-Основная причина применения LOCK TABLES - эмуляция транзакций или повышение скорости обновления таблиц. Ниже это объясняется более подробно.
+* Основная причина применения '''LOCK TABLES''' - эмуляция транзакций или повышение скорости обновления таблиц. Ниже это объясняется более подробно.
-Если поток устанавливает блокировку по чтению (READ) на таблице, то этот поток (и все остальные) может только читать данные из таблицы. Если поток устанавливает блокировку записи (WRITE) таблицы, то лишь этот поток может читать и писать в таблицу. Доступ остальных нитей к таблице блокируется.
+** Если поток устанавливает блокировку по чтению (READ) на таблице, то этот поток (и все остальные) может только читать данные из таблицы.
-Разница между READ LOCAL и READ состоит в том, что READ LOCAL позволяет неконфликтующим операторам INSERT (параллельным вставкам) выполняться, пока блокировка удерживается. Однако это не может быть выполнено, если вы пытаетесь манипулировать файлами базы данных извне MySQL в то время, пока удерживается блокировка.
+** Если поток устанавливает блокировку записи (WRITE) таблицы, то лишь этот поток может читать и писать в таблицу.
-В случае применения LOCK TABLES необходимо блокировать все таблицы, которые используются в запросах. Если одна и та же таблица используется несколько раз в запросе (через псевдонимы), вы должны получить блокировку на каждый псевдоним. Пока блокировка, полученная от LOCK TABLES, активна, вы не можете получить доступ ни к каким таблицам, которые не были блокированы этим оператором.
+** Доступ остальных нитей к таблице блокируется.
-Если ваш запрос обращается к таблице через псевдоним, вы должны блокировать таблицу, используя тот же псевдоним. Блокировка таблицы не будет работать, если не указан псевдоним:
+Разница между READ LOCAL и READ состоит в том, что
-<source lang="sql">LOCKTABLEtREAD;
+<source lang="sql">LOCK TABLE READ;
   SELECT * FROM t AS myalias;</source>
   ERROR 1100: Table 'myalias1 was not locked with LOCK TABLES

@@ Строка 117: / Строка 117: @@
 * Первый '''READ UNCOMMITTED'''
- Рассмотрим транзакцию выше. После INSERT данные сразу-же станут доступны для чтения. Тоесть еще до вызова COMMIT вне транзакции можно получить только что добавленные данные. В английской литературе это называется dirty read («грязное чтение»). Этот уровень редко используется на практике, да вообще редко кто меняет эти самые уровни.
+Рассмотрим транзакцию выше. После INSERT данные сразу-же станут доступны для чтения. Тоесть еще до вызова COMMIT вне транзакции можно получить только что добавленные данные. В английской литературе это называется dirty read («грязное чтение»). Этот уровень редко используется на практике, да вообще редко кто меняет эти самые уровни.
 * Второй '''READ COMMTITED'''
@@ Строка 125: / Строка 125: @@
 * Третий '''REPEATABLE READ'''
 Этот уровень используется по умолчанию в MySQL. Отличается от второго тем, что вновь добавленные данные уже будут доступны внутри транзакции, но не будут доступны до подтверждения извне.
- Здесь может возникнуть теоретическая проблема «фантомного чтения». Когда внутри одной транзакции происходит чтение данных, другая транзакция в этот момент вставляет новые данные, а первая транзакция снова читает те-же самые данные.
+Здесь может возникнуть теоретическая проблема «фантомного чтения». Когда внутри одной транзакции происходит чтение данных, другая транзакция в этот момент вставляет новые данные, а первая транзакция снова читает те-же самые данные.
 * И последний '''SERIALIZABLE'''
- На данном уровне MySQL блокирует каждую строку над которой происходит какое либо действие, это исключает появление проблемы «фантомов».
+На данном уровне MySQL блокирует каждую строку над которой происходит какое либо действие, это исключает появление проблемы «фантомов».
 На самом деле смысла использовать этот уровень нет, т.к. InnoDB и менее популярный Falcon решают эту проблему.

@@ Строка 128: / Строка 128: @@
 * И последний '''SERIALIZABLE'''
-  На данном уровне MySQL блокирует каждую строку над которой происходит какое либо действие, это исключает появление проблемы «фантомов». На самом деле смысла использовать этот уровень нет, т.к. InnoDB и менее популярный Falcon решают эту проблему.
+  На данном уровне MySQL блокирует каждую строку над которой происходит какое либо действие, это исключает появление проблемы «фантомов».
 * Увидеть текущий уровень изоляции
@@ Строка 150: / Строка 151: @@
 SELECT * FROM two;</source>
- Что будет в первой таблице, а что во второй?
+Что будет в первой таблице, а что во второй?

← Предыдущая		Версия 11:40, 10 марта 2014
Строка 100:		Строка 100:
	''MySQL. Руководство администратора'' (М. : Издательский дом "Вильяме", 2005, ISBN 5-8459-0805-1). InnoDB поддерживает эти уровни, начиная с версии MySQL 4.O.5. Уровень изоляции по умолчанию - REPEATABLE READ.		''MySQL. Руководство администратора'' (М. : Издательский дом "Вильяме", 2005, ISBN 5-8459-0805-1). InnoDB поддерживает эти уровни, начиная с версии MySQL 4.O.5. Уровень изоляции по умолчанию - REPEATABLE READ.
	*{{Карандаш\|24px}}Вы можете также установить начальный глобальный уровень изоляции для сервера mysqld, запустив его с опцией —transaction-isolation		*{{Карандаш\|24px}}Вы можете также установить начальный глобальный уровень изоляции для сервера mysqld, запустив его с опцией —transaction-isolation
		+	Кто-бы ни купил MySQL, она еще долго будет будоражить ресурсы Наших с Вами серверов — и это хорошо.
		+	===Пример ===
		+	*'''Есть таблица'''
		+	<source lang="sql">CREATE TABLE test (id INT, value VARCHAR(255)) ENGINE=InnoDB;</source>
		+	Что по Вашему покажет этот запрос?
		+
		+	<source lang="sql">START TRANSACTION;
		+	INSERT INTO test(id, value) VALUES (1, 'test'), (2, 'test 2');
		+	SELECT * FROM test;
		+	COMMIT;
		+	SELECT * FROM test;
		+	</source>
		+
		+	А что покажет простейший SELECT во время выполнения текущей транзакции? Не ясно. Вот и придумали такие правила.
		+
		+
		+	* Первый '''READ UNCOMMITTED'''
		+	Рассмотрим транзакцию выше. После INSERT данные сразу-же станут доступны для чтения. Тоесть еще до вызова COMMIT вне транзакции можно получить только что добавленные данные. В английской литературе это называется dirty read («грязное чтение»). Этот уровень редко используется на практике, да вообще редко кто меняет эти самые уровни.
		+
		+	* Второй '''READ COMMTITED'''
		+	В данном случае прочитать данные возможно только после вызова COMMIT. При чем внутри транзакции данные тоже будут еще не доступны.
		+	Если рассмотреть транзакцию выше, то первый SELECT ничего не вернет, т.к. таблица у нас еще пустая и транзакция не подтверждена.
		+
		+	* Третий '''REPEATABLE READ'''
		+	Этот уровень используется по умолчанию в MySQL. Отличается от второго тем, что вновь добавленные данные уже будут доступны внутри транзакции, но не будут доступны до подтверждения извне.
		+	Здесь может возникнуть теоретическая проблема «фантомного чтения». Когда внутри одной транзакции происходит чтение данных, другая транзакция в этот момент вставляет новые данные, а первая транзакция снова читает те-же самые данные.
		+
		+	* И последний '''SERIALIZABLE'''
		+	На данном уровне MySQL блокирует каждую строку над которой происходит какое либо действие, это исключает появление проблемы «фантомов». На самом деле смысла использовать этот уровень нет, т.к. InnoDB и менее популярный Falcon решают эту проблему.
		+
		+	* Увидеть текущий уровень изоляции
		+	<source lang="sql">SHOW VARIABLES LIKE '%tx_isolation%';</source>
		+
		+	* Установить
		+	<source lang="sql">SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;</source>
		+
		+
		+	''P.S. Это всего лишь попытка вольного перевода самой обычной документации.''
		+
		+	'''Задачка:'''
		+	<source lang="sql">CREATE TABLE one(id INT, value VARCHAR(12)) ENGINE = MyISAM;
		+	CREATE TABLE two(id INT, value VARCHAR(12)) ENGINE = InnoDB;
		+
		+	START TRANSACTION;
		+	INSERT INTO one (id, value) VALUES (1, 'test');
		+	INSERT INTO two (id, value) VALUES (1, 'test');
		+	ROLLBACK;
		+	SELECT * FROM one;
		+	SELECT * FROM two;</source>
		+
		+	Что будет в первой таблице, а что во второй?

@@ Строка 99: / Строка 99: @@
 Описание уровней изоляции транзакций InnoDB приведено в книге:
 ''MySQL. Руководство администратора'' (М. : Издательский дом "Вильяме", 2005, ISBN 5-8459-0805-1). InnoDB поддерживает эти уровни, начиная с версии MySQL 4.O.5. Уровень изоляции по умолчанию - REPEATABLE READ.
-{{Карандаш|24px}}Вы можете также установить начальный глобальный уровень изоляции для сервера mysqld, запустив его с опцией —transaction-isolation
+*{{Карандаш|24px}}Вы можете также установить начальный глобальный уровень изоляции для сервера mysqld, запустив его с опцией —transaction-isolation

@@ Строка 40: / Строка 40: @@
   ERROR 1181: Got error 153 during ROLLBACK
 Все точки сохранения транзакций удаляются, если выполняется оператор COMMIT или ROLLBACK без указания имени точки сохранения.
-=== Синтаксис LOCK TABLESи UNLOCK TABLES ===
+=== Синтаксис LOCK TABLES, UNLOCK TABLES ===
 <source lang="sql">LOCK TABLES
 имя_таблицы[AS псевдоним] {READ [LOCAL] | [LOW_PRIORITY] WRITE}
@@ Строка 90: / Строка 90: @@
 Вы можете заблокировать по чтению все таблицы во всех базах данных оператором flush tables with read LOCK. См. разделСинтаксис LOCK TABLES и UNLOCK TABLES Это очень удобный способ получить резервные копии, если вы работаете с файловой системой вроде Veritas, которая может делать снимки во времени.
 %Назаметку! Если вы используете ALTER TABLE на блокированной таблице, она может разблокироваться. См. раздел Проблемы с ALTER TABLE
 === Синтаксис SET TRANSACTION ===
 <source lang="sql">SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL