幾個重點問題回顧

Ⅰ、鎖與併發控制

locking、concurrency、isolation、serializability這幾個是同一個意思

1.1 併發訪問控制的準則

第一準則：不出錯
Concurrent execution should not cause application programs to malfunction

第二準則：性能要比單線程高
Concurrent execution should not have lower throughput or much higher response times than serial execution

特例：線程池,秒殺場景,1024個線程確定比1個線程慢,單線程qps能達到將近1000,1024線程只能幾十

數據庫中並行執行會存在三個問題

髒讀         rc解決
不可重複讀    rr解決,innodb在rr下也解決了幻讀,因此rr被稱爲2.99度隔離性
幻讀         serializable    大多數數據庫廠商不遵循

serializable纔是數據庫真正的隔離性要求,隔離性和隔離級別不同,兩階段加鎖(讀寫都加鎖,序列化),任何操做都加鎖

acid中的i,數據庫產品都沒有符合要求的

oracle db2 sqlserver默認事務隔離級別都是rc的,只解決髒讀不解決不可重複讀和幻讀

innodb默認rr,解決了髒讀,不可重複讀,幻讀

tips：
若是開啓了分佈式事務,必定要用serializable,這是官方文檔裏說的,不知道爲何,不懂

Ⅱ、幻讀VS不可重複讀

幻讀(phantom read)：連續執行兩次一樣的sql語句可能致使不一樣的結果,而且第二次的sql語句可能會返回以前不存在的行(記錄數量不同)

不可重複讀是同一條記錄結果不同(修改),而幻讀是讀到的記錄數量不同

Ⅲ、爲何如今都用rc呢？

rc不解決幻讀,但rc相對rr,鎖持有時間短 ,開銷更小

可是

咱們應用程序對生活中的application來講好像不是一個問題

對記錄的修改,大部分時候都是一條一條的,本身處理本身。

有問題的是減庫存的的時候,多線程對一條記錄操做,但這個時候是有for update鎖定這條記錄,因此現實生活中,不可重複讀和幻讀沒影響,並非那麼重要

4、其餘

innodb表鎖的獲取

lock table l read;
lock table l write;
unlock tables;

這是server層的鎖(mdl鎖)

從原理上講innodb也是能夠對錶加X鎖的,可是沒有一個具體的命令來觸發,也能夠把lock table l read; 理解爲加X鎖

一般來講不須要加表級別的鎖,mysqldump都不加,ddl不支持online的時候就是先對一張表先加一個S鎖,如今不同了