MySQL : можно ли сохранить уникальный индекс, не блокируя таблицу, за исключением случаев, когда значение сталкивается?

#mysql #indexing #locking #unique

#mysql #индексация #запирающийся #уникальный

Вопрос:

У меня есть следующая таблица.

 CREATE TABLE `FooBar` (  `id` int(10) AUTO_INCREMENT,  `foobar_id` int(10),  PRIMARY KEY (`id`),  UNIQUE KEY `foobar_id` (`foobar_id`) ) ENGINE=InnoDB;  

Основываясь на моем тестировании, всякий foobar_id раз, когда обновляется, любое другое обновление, связанное foobar_id с ним, будет заблокировано до тех пор, пока не закончится первое.

В идеале я хочу, чтобы, когда кто-то обновляет не конфликтующее значение, таблица не была заблокирована

 begin;  update `FooBar` set foobar_id=2 where id=1;  commit;  
  begin;  update `FooBar` set foobar_id=3 where id=2;  commit;   

Эти два запроса, очевидно, не будут сталкиваться друг с другом, и второй в идеале должен быть выполнен до фиксации первого, если первое обновление не установлено 3 . Однако мой результат тестирования показывает, что второй запрос не будет выполнен до тех пор, пока не будет выполнен первый коммит.

Когда ключ не уникален, этого не произойдет.

Есть ли способ обойти блокировку стола?

Комментарии:

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

2. На мой взгляд, это должно быть теоретически возможно. Просто проверьте все существующие ключи плюс все незафиксированные транзакции, а затем, если значение обновления не совпадает ни с одним из них, оно должно работать. (MySQL уже проверяет все существующие ключи, поэтому часть выполнена). Есть ли какая-либо причина, по которой MySQL не поддерживал этот подход, или он действительно поддерживается (этим или любым другим подходом, который достигает того же эффекта), просто я не знаю?

3. Проверка существующих ключей устанавливает общую блокировку ключей.

4. Извините, что я не высказался ясно в приведенном выше комментарии. Я имел в виду «проверить значения существующих строк (которые уже отправлены), а также проверить «подлежащее обновлению значение» строк, которые вставляются/обновляются в транзакции, которые не были отправлены». Разве этот подход не должен работать теоретически?

5. Сколько записей в вашей таблице? Только несколько для целей тестирования?