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