此篇文章爲學生時代作品，大佬們看到這裏就別往下看了

抱歉，這是筆者非常菜時一時起意寫的文章，能引發思考就好。現在再看這篇文章，只能嫌棄自己當時水了。innodb的行級鎖是在併發更新單條記錄時，利用這個特性，可以採用CAS的方式，來達到更新單筆記錄的目的。當然，實際秒殺場景要複雜的多，數據庫是很脆弱的，流量非常大時，數據庫是扛不住的。真實場景會從各個方面減少流量（產品層面、應用各層次、限流、消息隊列削鋒、優先更新緩存再同步入庫等），最終達到數據庫的只是很少的一部分流量。

①爲什麼不能用數據庫自帶的表鎖功能？

由於下單、搶票等是要寫入數據庫的，對數據庫進行修改，所以採用的寫鎖，這樣，被鎖定的數據表就無法被其他地方使用，無論修改還是查詢。比如一位用戶購買商品時，鎖定了商品表，另一位用戶在瀏覽商品，則不能再去訪問這張數據表了，不能訪問表，意味着這一段時間加載不出商品，而高併發情況下，有很多的人下單。瀏覽商品，這段很短的鎖表時間被放大化，會拖延整個網站的訪問速度。

②如何解決這一問題？

1、首先明確我們需要的只是：在一個用戶對一張表進行修改、刪除等操作時，不讓其他用戶去對這張表進行修改、刪除等操作。

2、我們可以創建一個文件，在使用下單功能等關於數據庫修改、刪除的操作前，打開這個文件，然後對這個文件進行鎖定，在進行完對數據庫的操作之後，關閉這個文件，再對這個文件解鎖。

3、這樣就能解決高併發問題的原因是我們相當於把對數據庫操作的代碼放在鎖文件和解鎖文件之間了。這樣相當於一個標誌位。當用戶A試圖修改數據時，鎖定了這個文件。而另一個用戶B也試圖修改數據庫、但是要執行數據庫操作前，先得打開這個文件，而文件鎖定了，這樣用戶B打不這個文件，只能阻塞在打開文件的代碼處，這樣就不能繼續執行打開文件後的代碼，只能等待打開這個文件。而用戶A對數據庫操作完後，解鎖了這個文件。此時，用戶B可以打開這個文件了，則可以繼續對數據庫進行修改、刪除，同時把這個文件鎖死，其他需要對數據庫進行操作的用戶將一直阻塞在打開文件，只能等待文件解鎖，才能對這個數據庫進行修改、刪除了

4、只是在對數據庫進行修改、刪除時鎖定本地的文件，而不是鎖定數據表，這樣用戶仍然可以對數據庫進行查詢，添加等不影響用戶瀏覽網頁的訪問，商戶也可以添加新商品，不會拖延網站瀏覽等訪問速度。