樂觀鎖和悲觀鎖
但是事情是可能有多個用戶同時操作了一個數據字段，並且要對數據庫提交了修改，此時爲了保護數據的正確性，所以人們想出了一個辦法來解決這種情況：使用版本控制或者時間戳。
簡單介紹一下版本控制和時間戳，他們的功能是爲了保證一個操作從讀取數據到更改數據提交的這段過程中，沒有其他的操作修改過這個數據字段。
實現起來也比較簡單，爲每個字段創建一個版本號，version，每次需要讀取這個字段時將版本號也讀取出來，然後提交修改的時候帶上讀取的版本號，將事先讀取的版本號和現在數據庫對應字段的版本號進行比較，如果據庫裏的版本號等於事先讀取的版本號，說明這段時間沒有其他操作修改過這個字段，然後將本次修改提交，並將版本號version+1。
如果數據庫裏的版本號比事先讀取的版本號大，說明在這次操作時間內已經有其他操作修改的這個字段，因此這次提交是無效的，不能完成提交。
時間戳的方法類似，不過將判斷的方式改成了提交時間的變化。
悲觀鎖：Pessimistic Concurrency Control，縮寫“PCC”，是一種併發控制的方法。
悲觀鎖和樂觀鎖的觀點相反，他認爲爲了自己的操作會被別的操作所影響，所以在自己操作數據庫某個字段時，別的操作都不能進行。
悲觀鎖操作數據庫時，會事先嚐試在該字段加排它鎖（加鎖之後其他操作均不可進行），如果加鎖失敗則表明有其他的操作在使用這個字段，這樣就需要等待知道其他操作完成釋放鎖，當獲得鎖並完成操作之後再將鎖釋放供其他操作使用。
數據庫實現悲觀鎖有兩種類型，行鎖和表鎖。InnoDB使用行鎖，MyISAM只能使用表鎖。
顧名思義表鎖是將整張表鎖住，消耗資源更大，併發能力弱，行鎖則只鎖住需要操作的那一行數據，併發能力強一些。
行鎖的使用必須保證索引能夠使用，換句話說如果在一次操作中沒有使用索引，則不會使用行鎖而是表鎖。
總結：
悲觀鎖的併發能力比樂觀鎖弱。
樂觀鎖可能會出現衝突，悲觀鎖不會出現衝突。
在讀多寫少的場合，樂觀鎖的使用效果比悲觀鎖好些。
在不允許髒讀，對數據庫的安全要求較高的場合，還是使用悲觀鎖好。