共享鎖和共享鎖可以共存，共享鎖和排它鎖不能共存，只有在serializable隔離級別下做查詢會新增共享鎖
案例：開啟兩個客戶端並都設定隔離級別為serializable，分別在兩個客戶端中進行查詢
實現步驟：
1.開啟2個視窗分別設定隔離級別都為serializable
2.開啟事務執行查詢
視窗1：
視窗2：
3.在 視窗2中執行更新操作，出現如下情況，程序被阻塞
通過上面的測試可以得出結論：共享鎖就是多個事務對於同一資料可以共享一把鎖，都能訪問到資料，但是只能讀不能修改
排它鎖與任何鎖都不能共存，任何隔離級別下做增刪改操作時都會新增排它鎖
案例：基於前面的案例
在兩邊都查詢的基礎上，將其中一邊進行增刪改操作
任意一邊：update user set money=money+100 where name='b';
執行結果就是共享鎖中描述的步驟3
兩個執行緒彼此握著對方需要的資源，互不釋放
mysql可以檢測到死鎖的存在，讓其中一方報錯，另一方執行
1、當事務在運算元據時把這部分資料進行鎖定，直到操作完畢後再解鎖，其他事務操作才可操作該部分資料。這將防止其他程序讀取或修改表中的資料。
2、實現：
一般使用 select ...for update 對所選擇的資料進行加鎖處理，例如 select * from `yzm_order` where `order_no` = 's201909277894' limit 1 for update ，這樣就通過開啟排他鎖的方式實現了悲觀鎖。此時在 yzm_order 表中，order_no 為 s201909277894 的那條資料就被我們鎖定了，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的資料不會被其它事務修改。
1、如果有人在你之前更新了，你的更新應當是被拒絕的，可以讓使用者重新操作。
2、實現：
大多數基於資料版本（version）記錄機制實現，
具體可通過給表加乙個版本號或時間戳字段實現，當讀取資料時，將version欄位的值一同讀出，資料每更新一次，對此version值加一。當我們提交更新的時候，判斷當前版本資訊與第一次取出來的版本值大小，如果資料庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期資料，拒絕更新，讓使用者重新操作。
資料庫 持續更新中
explain plan forselect from test select from table dbms xplan.display select b.uniqueness,a.index name,a.table name,a.column name from all ind columns...
資料庫優化（持續更新中 ）
1 合理使用索引 經常進行連線，但沒有指定為外來鍵的列上建立索引 在頻繁進行排序或分組 即進行group by或order by操作 的列上建立索引 在條件表示式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引 如性別只有兩種，不用索引 如果待排序的列有多個，可以在這些列上建立復合...
資料庫優化（持續更新）
資料庫是程式的倉庫，也是程式中最脆弱的一部分，因為它的脆弱性和重要性，所以需要專門進行管理和優化。在如今的網路化的時代更加需要資料庫的靈活和快捷，乙個高效的資料庫能夠使程式執行效率更快，提高程式的執行效率。但往往對資料庫的設計達不到我們想要的效果，所以資料庫的優化顯得尤為重要。該系列文章正是考慮大資...