你的想法不錯，只是做法不好。
如果當有一堆商品且數量都高達1000以上的情況下，這樣做就不太合適。

以前的購物車做法給你參考。

商品欄位會區分「庫存量」「等待售出庫存量」

在下訂商品的當下，就會產生訂單。並將「庫存量」扣除到「等待售出庫存量」
訂單狀態會是在等待確認的情況。「等待確認單」最多只會等15分~1個小時(時間當時設計給業主自行設定)。
當一個小時超過還沒進入「確認」的情況下。
會將該單列為取消單。並將原本在「等待售出庫存量」轉回「庫存量」

在同時間同時下訂的情況下。基本當下會鎖表處理。

每開啟這個限量商品就從資料庫中取得限量的水號，資料庫同時也標記這筆記錄已被取走，記錄取用時間並更新回資料庫，這時並不代表交易已經完成，只是在取得交易流水號的動作而已，在完成交易後再更新這筆交易編號的狀態為已售出，如果用戶中途離線或交易過久，你的後端再把標記時間超過10分鐘但尚未標記完成交易的記錄收回並重新發給客戶端使用(放SESSION)，直到所有水號都已經更動狀態成售出為止

這就不會發生超量的問題

有人會說要是有人故意多開瀏覽器來佔水號，那你不會做同IP只能取一次啊？或是讓用戶必需加入會員，每一會員只能同時開一個..

這只是我的做法，別人或有別的想法，你參考看看

我怎麼覺得，應該先解決 MYSQL 問題，也不能用unsigned型態 和 innodb，這基本東西不處理掉，沙灘上蓋大樓，安穏嗎？

我並不主張追求太太太新的東西，但對於太太太舊的古董則十分排斥，有些時候，新工具一行或一分鐘能解決的問題，老古董可能得花好幾十倍的心力。