資料庫問題請教
 

請教一下版上的各位

目前碰到一個狀況...

多名USER 同時會買一個東西...

而東西有限量...

所以會有一個欄位統計這個東西目前已有多少人購買...

每有一人購買就會於該欄位 +1

可是在壓力測試時，這個欄位UPDATE的速度會愈來愈慢....

因為在排隊UPDATE....

不知有沒有可以建議改善的方法...

謝謝

PS:資料庫是 SQL SERVER

我的建議是你弄一小段程式，針對目前有幾筆交易紀錄，去統計目前的購買量，然後這個數值看是要即時顯示在甚麼地方（例如製作成報表或者弄在系統畫面某一個地方），或者用作於限制目前購買量的程式邏輯都可以

不需要一直針對資料庫交易，只需簡單的一筆查詢筆數就可以即時知道購買量有多少

能用查詢解決問題，就不要一直對資料庫交易

如果你是要限定購買量，也只需要在另一個資料表（例如：目前該商品庫存量），查詢然後比對目前的購買交易紀錄即可限制購買量

非同步....:cool:,
MSMQ.....:cool:.

你可能當初建了一個"累計購買數量"欄位在物料主檔
物料主檔是很多動作都會參考到的檔案
可能資料筆數也多
造成異動成本過高

一般資料庫都不會這樣做
如果需要最即時的庫存量
通常是直接去計算銷售紀錄再去跟可用庫存量比對

:D

1. 如果你有對該欄位做索引，把索引移除試試，常更新的欄位用索引只會更慢。
2. 跟其他網友看法一樣，從程式邏輯上去克服，不要去維護累計購買數(不要 update)，而是直接去查詢庫存量跟購買數來做比對，select 比 update 快很多。

讓相關交易盡快完成確認(committed)。

不過如果是很短的時間內會有大量的購買紀錄，再加上可購買的數量也會快速的更新，那就還要一些程式邏輯來控制，不過這就看有沒有其他高手來介紹可行的方案，這點我就比較沒太多經驗了

當然也可以修改購買流程與制度來控制，就不需要透過複雜的程式避免出錯

伺服端程式讀取一次欄位數量後，做虛擬切割如下：

交易ID 1、3、5.... 去虛擬倉庫A存取。
交易ID 2、4、6.... 去虛擬倉庫B存取。
.
.
.
伺服端程式被存量不足信號觸發後，負責自動調撥、比對物件數量。
依此類推自行擴充完善......

累計購買數量放在記憶體裡，每次訂單進來做對應的遞增。
即使系統重啟，累計購買數量也可以由過去訂單記錄推算。
這樣需要的IO最少。

我們的狀況就是類似您舉出的狀況，

依shinRong的建議
目前的確也是有建一個欄位在物件主檔...
我會試著去把這個欄位拉出來...

因為大量同時INSERT 購買的紀錄...
如果再去用 SELECT 統計總數，在同時大量購買的狀況下反而造成DATA LOCK...

我在想是否可以用 TRIGGER 自動去加總異動人數統計..