MySQL支持多種存儲引擎，其中最常用的InnoDB和MyISAM，他倆的主要區別呢，就是一個支持事務，一個不支持事務，一個查詢的快一個查詢的慢一些，其實對于新的項目可以自由的選擇，但是對于已經運行了很多年的系統，想要切換就很難。
事情的起因事什么呢，手術護理系統在確認了患者的信息之后，把所有需要用到的數據表中加入這個患者的基本信息創建一條數據，但是現在出現了這樣一個情況， 在網絡不好或者請求重復的情況下，可能會每個表中都存在OPERATIONID 相同的數據兩條或者三條以上的重復性數據，導致數據在聯查的時候出錯，但是目前數據庫的數據量很大，可能改不了主鍵來限制的方法。
于是呢就想到要可以用鎖來解決這個問題，但是現在的收據庫類型使用的事MyISAM類型，為什么要使用這個類型呢，因為數據庫的屬于越來越多，查詢的速度越來越慢，在使用InnoDB的情況下，查詢的速度要比使用MyISAM慢好幾倍，為什么MyISAM的查詢更快呢，因為MyISAM：索引與數據分離全表掃描時更快。
由于用的是MyISAM所以沒有辦法使用事務和行鎖，那么就嘗試一下使用表級鎖；
1. MyISAM：表級鎖（Coarse-Grained Locking）
工作機制：MyISAM僅支持表級鎖，任何寫操作（INSERT/UPDATE/DELETE）都會鎖定整個表，阻塞所有其他讀寫操作。讀操作（SELECT）會施加共享鎖，允許多個查詢并發，但與寫操作互斥
時會話B需等待會話A的UNLOCK TABLES才能執行，這樣就有點卡巴了，會話B還得等一會才能執行，我感覺有點坑，影響使用體驗，所以我放棄了這個方案，先還是保持現狀吧。
最后做個總結
MyISAM：適合只讀為主的場景（如數據倉庫），優勢在簡單查詢速度和低內存開銷，但表級鎖和缺乏事務是其硬傷。
InnoDB：適用于高并發寫入和需事務的場景（如電商），行級鎖和MVCC保障并發性能與數據安全，通過索引優化可縮小查詢差距。
在SSD和內存成本下降的當下，InnoDB+硬件優化已成為主流方案。MyISAM僅建議用于歸檔數據或特定只讀負載，新項目應優先InnoDB。
