1：悲觀鎖
1.1 特點：
每次查詢都會進行鎖行，怕“其他人”進行數據的修改。
1.2 實現步驟：
步驟1：開啟事務test1，並對id=2的記錄進行查詢，並加鎖，如：
步驟2：在事務test1沒有進行commit的情況下，開啟事務test2，並對id=2的記錄進行修改，看執行結果
最終執行結果顯示獲取鎖超時。
而在獲取鎖的過程中，執行 show processlist 命令可以看到：修改id=2的sql命令一直在等待鎖。
而由於事務test1我沒有commit，因此事務test2是獲取不到鎖的，因此就超時了。
步驟3：當我事務test1進行commit之后，我在事務test2中進行id=2的記錄的修改操作時會是什么情況：
最終可以看到在事務test1進行commit之后，事務test2的修改操作終於成功了。
1.3 總結：
在事務中執行 select * from table where id = ? for update 並沒有進行commit時，id = ? 的記錄將進行鎖行，另外一個事務想要修改 id = ? 的記錄將會一直阻塞直至事務超時。
2：樂觀鎖
2.1 特點：
1：適用於讀多於寫的情況。
2：不會鎖行，樂觀主義。
2.2 實現方式：
常見的就是增加version字段或時間戳字段，每次修改都進行這個字段的更新。
2.3 那么如何解決多個人同時進行修改/新增/刪除等操作時，最終只有一個執行成功？
我這里采用version的方式進行演示，測試步驟如下：
2.3.1：事務1的 DDL
2.3.2：事務2的 DDL
2.3.3：流程圖
當事務1和事務2同時修改id=2 and version = 1 的記錄的時候，最終事務1成功修改，而到事務2進行修改時符合條件的記錄已經不存在了，因此修改失敗！！
流程圖如下：
結果：通過控制version，可以合理的解決資源競爭問題。
在日常開發中，可以利用事務的一致性，做更多的判斷及操作。
