三種併發策略：
1.什麼都不做，任由併發產生，以最終提交結果為準。
2.開放式併發，衝突產生時，告訴使用者當前資源被占用。
3.保守式併發，強制加鎖，只有當前使用者更新提交完畢才能被下乙個使用者占用。
保守式併發
保守式併發通常用於兩個目的。第一，在某些情況下，存在對相同記錄的大量爭用。在資料上放置鎖所費的成本小於發生併發衝突時回滾更改所費的成本。
在事務過程中不宜更改記錄的情況下，保守式併發也非常有用。庫存應用程式便是乙個很好的示例。假定有乙個公司代表正在為一名潛在的客戶檢查庫存。您通常要鎖定記錄，直到生成訂單為止，這通常會將該項標記為「已訂購」狀態並將其從可用庫存中移除。如果未生成訂單，則將釋放該鎖，以便其他檢查庫存的使用者得到準確的可用庫存計數。
但是，在斷開的結構中無法進行保守式併發控制。連線開啟的時間只夠讀取資料或更新資料，因此不能長時間地保持鎖。此外，長時間保留鎖的應用程式將無法進行伸縮。
開放式併發
在開放式併發中，只有在訪問資料庫時才設定並保持鎖。這些鎖將防止其他使用者在同一時間更新記錄。除了進行更新這一確切的時刻之外，資料始終可用。有關更多資訊，請參見開放式併發
。當試圖更新時，已更改行的初始版本將與資料庫中的現有行進行比較。如果兩者不同，更新將失敗，並引發併發錯誤。這時，將由您使用所建立的業務邏輯來協調這兩行。
最後的更新生效
當使用「最後的更新生效」時，不會對初始資料進行檢查，而只是將更新寫入資料庫。很明顯，可能會發生以下情況：
在上述情況中，使用者 a 永遠也不會看到使用者 b 作出的更改。如果您計畫使用併發控制的「最後的更新生效」方法，則要確保這種情況是可以接受的。
資料庫層面的鎖
那是一種行級鎖，一旦使用者對某個行施加了行級加鎖，則該使用者可以查詢也可以更新被加鎖的資料行，其它使用者只能查詢但不能更新被加鎖的資料行 如果其它使用者想更新該表中的資料行，則也必須對該錶施加行級鎖 即使多個使用者對乙個表均使用了共享更新，但也不允許兩個事務同時對乙個表進行更新，真正對錶進行更新時，...
mysql資料庫高併發處理
總體思想 短,少,分流 短 1.頁面靜態化,2.使用快取 3.使用儲存過程,對於處理一次請求需要多次訪問資料庫的操作,將操作整合到儲存過程,這樣只需要一次資料庫訪問 4.延遲修改,將修改請求儲存到記憶體中,但可能會斷電丟失資料 5.使用索引 少 1.分表,但應盡量避免多表關聯查詢 2.分離活躍資料,...
資料庫高併發
案例一 訂票系統案例某航班只有一張機票，假定有1w個人開啟你的 來訂票，問你如何解決併發問題 可擴充套件到任何高併發 要考慮的併發讀寫問題 問題 1w個人來訪問，票沒出去前要保證大家都能看到有票，不可能乙個人在看到票的時候別人就不能看了。到底誰能搶到，那得看這個人的 運氣 網路快慢等 其次考慮的問題...