Какова фактическая разница между реализациями MySQL InnoDB повторного чтения и Serializable

Question

Согласно стандарту SQL, повторное чтение должно предотвращать нечеткие чтения и грязные чтения, в то время как Serializable также должен предотвращать фантомные чтения.

Согласно MySQL documentation:

По умолчанию InnoDB работает в REPEATABLE READ изоляции транзакций уровне. В этом случае InnoDB использует следующие блокировки для поиска и индексирует сканирование, которое предотвращает появление фантомных строк (см. Раздел 14.2.2.5, «Избегание « Призрачная проблема с использованием блокировки с помощью следующего ключа »).

Так что если повторное чтение может предотвратить фантомное чтение, что предлагает Serializable в обмен?

Разве что Serializable защищает от записи перекоса или чтения перекоса и повторного чтения нет?

Answer 1

Ответ можно найти в mysql documentation, цитата:

Этот уровень, как REPEATABLE READ, но InnoDB неявно преобразует все равнину ЗЕЬЕСТ в SELECT ... LOCK IN SHARE MODE, если автокоммит отключен. Если autocommit включен, SELECT является его собственной транзакцией. Поэтому он известен только для чтения и может быть сериализован, если выполняется как согласованное (неблокирующее) чтение и не должно блокироваться для других транзакций.

Сериализуемое расписание транзакций при использовании двухфазной блокировки предотвращает перекосы чтения и записи. Вот как это работает на SQL Server, используя блокировку или на PostgreSQL, используя их Serializable Snapshot Isolation.

Если общий доступ к коду обнаружен на любом ресурсе, который читается, тогда также предотвращается перекос и перекосы записи.