Связь и интернет Архив Программирование
   
Сделать стартовойСделать закладку            
   ПОИСК  
   
Главная / MySQL / Типы таблиц MySQL /
8  Perl
8  PHP
8  JavaScript
8  HTML
8  DHTML
8  XML
8  CSS
8  C / C++
8  Pascal и Delphi
8  Турбо Ассемблер
8  MySQL
8  CASE-технологии
8  Алгоритмы
8  Python
8  Обратная связь
8  Гостевая книга
Новости о мире


Таблицы InnoDB - Программирование от RIN.RU
Таблицы InnoDB



Транзакционная модель InnoDB




Назначение транзакционной модели InnoDB заключается в том, чтобы совместить лучшие свойства многовариантной базы данных и традиционной двухфазной блокировки. Для таблиц InnoDB осуществляется блокировка на уровне строки и запросы по умолчанию запускаются как целостное считывание без блокировок, подобно тому, как это реализовано в Oracle. Хранение таблицы блокировок InnoDB организовано настолько экономично, что нет необходимости в расширении блокировки: обычно несколько пользователей могут блокировать любую строку или любой набор строк в базе данных, не занимая всю память, доступную для InnoDB.


В таблицах InnoDB все действия пользователей осуществляются при помощи транзакций. Если в MySQL используется режим автоматической фиксации, то для каждого оператора SQL будет создаваться отдельная транзакция. Если режим автоматической фиксации отключен, то мы предполагаем, что у пользователя постоянно имеется открытая транзакция. Если он выполняет оператор SQL COMMIT или ROLLBACK, которые завершают текущую транзакцию, сразу же запускается новая транзакция. Оба упомянутых оператора снимают все блокировки InnoDB, которые были установлены во время выполнения текущей транзакции. Оператор COMMIT означает, что изменения, внесенные во время выполнения текущей транзакции, зафиксированы и становятся видимыми для других пользователей. Оператор ROLLBACK отменяет все изменения, внесенные текущей транзакцией.


Согласованное чтение


Согласованное чтение означает, что для того, чтобы предоставить запросу копию базы данных на текущий момент времени, используется многовариантность таблиц InnoDB. Для запроса доступны лишь те изменения, которые были внесены транзакциями, зафиксированными на этот момент времени, и не доступны изменения, сделанные незафиксированными или проведенными позже транзакциями. Исключением из данного правила могут стать только изменения, внесенные транзакцией, направляющей текущий запрос.


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


Согласованное чтение является режимом по умолчанию, в котором в InnoDB обрабатываются операторы SELECT. При согласованном чтении не устанавливаются блокировки на таблицы, к которым обращается запрос, и, таким образом, остальные пользователи могут вносить изменения в эти таблицы одновременно с согласованным чтением


Чтение с блокировкой


В некоторых случаях использовать согласованное чтение нецелесообразно. Приведем пример. Допустим, что необходимо добавить новую строку в таблицу CHILD, предварительно убедившись, что для нее имеется родительская строка в таблице PARENT.


Предположим, что для чтения таблицы PARENT было использовано согласованное чтение, и в таблице была обнаружена родительская строка. Можно ли теперь безопасно добавить дочернюю строку в таблицу CHILD? Нет, потому что в это время другой пользователь мог без вашего ведома удалить родительскую строку из таблицы PARENT.


В данной ситуации необходимо выполнить операцию SELECT в режиме блокировки, LOCK IN SHARE MODE.


SELECT * FROM PARENT WHERE NAME = 'Jones' LOCK IN SHARE MODE;


Выполнение чтения в режиме совместного использования (share mode) означает, что считываются самые новые доступные данные и производится блокировка строк, чтение которых осуществляется. Если последние данные принадлежат еще не зафиксированной транзакции, мы ждем, пока транзакция не будет зафиксирована. Блокировка в режиме совместного использования не позволяет другим пользователям обновить или удалить читаемую строку. После того, как указанный выше запрос вернет родительскую строку 'Jones', мы можем безопасно добавить дочернюю строку в таблицу CHILD и зафиксировать транзакцию. В этом примере показано, как использовать целостность ссылочных данных в своей программе.


Рассмотрим еще один пример. Пусть у нас есть поле целочисленного счетчика в таблице CHILD_CODES, которое мы используем для назначения уникального идентификатора каждой дочерней записи, добавляемой к таблице CHILD. Очевидно, что использование согласованного чтения или чтения в режиме совместного доступа для получения текущего значения счетчика не подходит, так как два пользователя базы данных могут получить одно и то же значение счетчика и создать дублирующиеся ключи при добавлении двух дочерних записей в таблицу.


Для этого случая возможны два способа произвести чтение и увеличить значение счетчика: (1) сначала обновить значение счетчика, увеличив его на 1, и только после этого прочитать его или (2) сначала прочитать счетчик в режиме блокировки FOR UPDATE, а после этого увеличить его значение:


SELECT COUNTER_FIELD FROM CHILD_CODES FOR UPDATE;
UPDATE CHILD_CODES SET COUNTER_FIELD = COUNTER_FIELD + 1;


Оператор SELECT ... FOR UPDATE прочитает последние доступные данные с установкой отдельной блокировки на каждую считываемую строку. Таким образом, блокировка на строки устанавливается точно так же, как и в случае поиска по UPDATE.


Блокировка следующего ключа: устранение проблемы с фантомом


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


Блокировка, которая в InnoDB устанавливается на индексные записи, влияет также на интервал перед этой индексной записью. Если у пользователя имеется совместная или эксклюзивная блокировка записи R в индексе, то другой пользователь не может вставить новую индексную запись перед R в порядке следования индексов. Такая блокировка интервалов производится для предотвращения так называемой проблемы с фантомом. Предположим, что необходимо прочитать и заблокировать все дочерние записи с идентификатором, превышающим 100, из таблицы CHILD, и обновить некоторые поля в выбранных строках.


SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;


Допустим, что создан индекс таблицы CHILD по столбцу ID. Наш запрос произведет сканирование, начиная с первой записи, в которой ID больше 100. Теперь, если установленная на записи индекса блокировка не заблокирует вставки в интервалы, за это время в таблицу может быть вставлена новая дочерняя запись. Если теперь в транзакции запустить


SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;


еще раз, то в результате запроса будет выдана новая дочерняя запись. Это противоречит принципу изоляции транзакции: транзакция должна запускаться таким образом, чтобы считываемые ею данные не изменялись на протяжении выполнения транзакции. Если мы рассматриваем набор строк как элемент данных, то новая дочерняя "запись-фантом" нарушит этот принцип изоляции.


Когда InnoDB сканирует индекс, то возможна также блокировка интервалов после последних записей в индексе. Именно это иллюстрируется в предыдущем примере: блокировка, установленная InnoDB, предотвратит вставку в таблицу, если ID будет больше 100.


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


Блокировка, осуществляемая различными операторами SQL в InnoDB


  • SELECT ... FROM ...: согласованное чтение, которое производится из образа базы данных без блокировки.

  • SELECT ... FROM ... LOCK IN SHARE MODE: устанавливает совместно используемую блокировку следующего ключа на все считываемые индексные записи.

  • SELECT ... FROM ... FOR UPDATE: устанавливает эксклюзивную блокировку следующего ключа на все считываемые индексные записи.

  • INSERT INTO ... VALUES (...): устанавливает эксклюзивную блокировку на вставленную строку. Обратите внимание, что эта блокировка не является блокировкой следующего ключа и не предотвращает вставку другими пользователями записей в интервал перед вставленной строкой. Если произойдет ошибка дублирующегося ключа, оператор устанавливает блокировку совместного доступа на запись дублирующегося индекса.

  • INSERT INTO T SELECT ... FROM S WHERE ... устанавливает эксклюзивную (не следующего ключа) блокировку на каждую вставляемую в T строку. Осуществляет поиск по S как согласованное чтение, но устанавливает блокировки совместного доступа к следующему ключу на S, если включено ведение журнала MySQL. InnoDB в последнем случае должен устанавливать блокировки, так как при восстановлении работоспособности системы с повтором всех завершенных транзакций из резервной копии все операторы SQL должны запускаться точно таким же образом, как и изначально.

  • CREATE TABLE ... SELECT ... выполняет операцию SELECT как согласованное чтение или совместную блокировку, как и в предыдущем пункте.

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

  • UPDATE ... SET ... WHERE ...: устанавливает эксклюзивную блокировку следующего ключа для каждой записи, по которой производится поиск.

  • DELETE FROM ... WHERE ...: устанавливает эксклюзивную блокировку следующего ключа для каждой записи, по которой производится поиск.

  • Если для таблицы определены ограничения FOREIGN KEY, для любой вставки, обновления или удаления, для которых требуется проверка
    условий ограничения, устанавливается совместная блокировка на уровне записей, которые просматриваются для проверки ограничения. В InnoDB
    эти блокировки устанавливаются также в случае нарушения ограничения.

  • LOCK TABLES ...: устанавливает блокировку таблицы. Эта блокировка производится кодом уровня MySQL. Механизм автоматического обнаружения взаимоблокировок (deadlock) InnoDB не может детектировать взаимоблокировки, в которых участвуют такие блокировки таблиц (см. следующий раздел). Кроме того, поскольку MySQL "знает" о блокировке на уровне строки, возможно установление блокировки таблицы, в которой
    другой пользователь заблокировал строки. Но это не опасно для целостности транзакции. См. раздел Ограничения для таблиц InnoDB.




Обнаружение и откат взаимоблокировки (deadlock)


InnoDB автоматически обнаруживает взаимоблокировку транзакций и производит откат транзакций, запрос на блокировку которых вызвал возникновение взаимоблокировки, то есть замкнутого цикла в графике ожиданий транзакций. InnoDB не может обнаружить взаимоблокировку, установленную оператором MySQL LOCK TABLES, или блокировку, установленную отличным от InnoDB обработчиком таблиц. Такие ситуации необходимо исправлять при помощи параметра innodb_lock_wait_timeout, который задается в 'my.cnf'.


Когда InnoDB выполняет полный откат транзакции, все блокировки, установленные транзакцией, снимаются. Тем не менее, если в результате ошибки производится откат только одного оператора SQL, некоторые блокировки, установленные оператором, могут остаться в силе. Это происходит потому, что InnoDB хранит блокировку строк в формате, по которому впоследствии нельзя определить, каким оператором SQL была
установлена блокировка.


Пример работы согласованного чтения в InnoDB


При выполнении согласованного чтения (т.е. обычного оператора SELECT) InnoDB определяет для транзакции момент времени, по состоянию на который запросу будет предоставляться информация из базы данных. Таким образом, если транзакция удаляет строку и фиксирует это изменение после назначенного момента времени, то вы не увидите, что строка была удалена. Это справедливо также для вставок и обновлений.


Чтобы такой момент времени "передвинуть вперед", нужно зафиксировать транзакцию, а затем выполнить новую команду SELECT.


Это называется многовариантным контролем совпадений.


Пользователь A Пользователь B


SET AUTOCOMMIT=0; SET AUTOCOMMIT=0;


время
| SELECT * FROM t;
| пустой набор данных
| INSERT INTO t VALUES (1, 2);
|
v SELECT * FROM t;
пустой набор данных
COMMIT;
SELECT * FROM t;
пустой набор данных;


COMMIT;


SELECT * FROM t;
---------------------
| 1 | 2 |
---------------------


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


Чтобы увидеть "самое свежее" состояние базы данных, необходимо использовать чтение с блокировкой:


SELECT * FROM t LOCK IN SHARE MODE;




<<<  НазадВперед  >>>
 1  2  3  4  5  6  7  8  9  10  11 


 8  Комментарии к статье  8 8  Обсудить в чате

8  В тему

Таблицы MyISAM

Таблицы MERGE

Таблицы ISAM

Таблицы BDB или Berkeley_DB

Таблицы HEAP

 
  
  
    Copyright ©  RIN 2003 - 2004      * Обратная связь