筆記1－鎖

 

1. innodb的讀採用的是select @@tx_isolation\G來得出隔離的級別。而後innodb默認的是repeatable read。同時咱們能夠知道讀的方式採用一致性的非鎖定讀，即不用上鎖的方式，採用mvcc的併發的多個版本的控制來進行讀。經過實驗，開兩個事務進行比較，發現了RC（read commitment） 和RR（repeatable read）的區別。

2. 對於有時候須要顯示的加鎖的方式來讀，則分爲了select。。。。lock in share mode的方式，則別的事務只可以加上的是s鎖。若是一個讀採用select。。。。。for update 那麼別的事務則對於這一行不能加上鎖了。測試了一下阻塞的狀況，發現了就是在那裏空等着，指導另外的一個事務提交，釋放了鎖

3. 在建立外鍵的時候，若是主鍵是兩個字段，那麼必須兩個字段都須要。此次報錯了主要是由於兩個表的字段的類型應該須要一摸同樣，不然則會建立不成功。另外就是看看engine是否是innodb，只有innodb支持外鍵。因此若是不是的話，須要修改一下engine。

   alter table child add constraint c_fk foreign key(pid) references parent(pid);

   ps(mou 的Fenced Code Block 柵欄代碼塊的寫法) 是須要在上下行加上```

4. 行鎖有三種算法，record lock和gap lock以及next_key lock（previous_key lock）,當查詢的索引惟一的時候，next－key鎖會降爲record lock，只是鎖定單行，而不是連續行。這樣能夠提升相應的併發性

5. 數據丟失問題 主要是由於多個事務同時去讀的時候，讀到的數據同樣，而後分別在原數據的基礎上進行操做的話，那麼提交的時候，天然會形成覆蓋，而形成了數據的丟失。所以方法就是把並行搞成了串行。在update的時候，先去select一下，同時這個select獲取到的x鎖，那麼直有前一個事務操做完成了再去操做。

6. 阻塞 阻塞不是死鎖，阻塞只是一個事務中鎖須要去等待另一個事務中的鎖釋放它鎖佔用的資源。阻塞不是壞事情，爲了更好的併發正常運行。

7. 死鎖 兩個互相爭奪鎖資源