0
據我所知，innoDB使用一致的非阻塞機制讀取， ，因此每個事務都有自己的快照。MySql InnoDB可重複讀取意外的鎖定行爲
它也告訴記者，在官方documentation
持續讀不設置就可以訪問，因此其他會話都是免費的，同時讀一致性是修改這些表的表的任何鎖在桌子上進行。
但我意外地遇到問題時，會出現經典的 '讀取/更新' 僵局：
隔離級別重複讀取（也被轉載與提交讀）
交易1讀取行（不是鎖定共享模式）。
事務2讀取相同的行（也不鎖定在共享模式）。 然後
交易1嘗試更新此行。
交易2也嘗試更新此行。
最後步驟之後，INNODB檢測死鎖（下面有最新DETECTED DEADLOCK）： ---------------- 2017年3月31日16時07分： 03 0x1f58 ***（1）TRANSACTION： TRANSACTION 413412，ACTIVE 20秒開始索引讀取 正在使用的MySQL表1，鎖定1 鎖定等待9鎖結構，堆大小1136,6行鎖，取消日誌條目3 MySQL線程ID 33，OS線程句柄8148，查詢ID 102005本地主機127.0.0.1根更新
/* update Order */ update `Order` set ... <fields to update>
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2151 page no 709 n bits 88 index PRIMARY of table `ooapp2`.`order` trx id 413412 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 54; compact format; info bits 0
*** (2) TRANSACTION:
TRANSACTION 413413, ACTIVE 11 sec starting index read
mysql tables in use 1, locked 1
9 lock struct(s), heap size 1136, 6 row lock(s), undo log entries 3
MySQL thread id 28, OS thread handle 8024, query id 102008 localhost 127.0.0.1 root updating
/* update Order */ update `Order` set ...<fields to update>
*** (2) **HOLDS THE LOCK(S):**
RECORD LOCKS space id 2151 page no 709 n bits 88 index PRIMARY of table `ooapp2`.`order` trx id 413413 lock mode S locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 54; compact format; info bits 0
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2151 page no 709 n bits 88 index PRIMARY of table `ooapp2`.`order` trx id 413413 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 54; compact format; info bits 0
*** WE ROLL BACK TRANSACTION (2)
我不明白，發生了什麼，爲什麼事務2
持有鎖（S）
所以如果InnoDB的。然而不要使用一致的閱讀與快照和套S-鎖 這樣做不符合官方手冊所寫的事實。