不應該呀？檢查下程式碼、觸發器和儲存過程邏輯吧！八成與邏輯有關係，理下資料流向。這麼多年沒碰到你說的這種情況。既然資料庫用了觸發器，先用腳步加些測試資料，看正常不正常，如果正常就DEBUG下程式碼看看。把整個業務模型最好理一理。

限流演算法

目前程式開發過程常用的限流演算法有兩個：漏桶演算法和令牌桶演算法。

漏桶演算法

漏桶演算法的原理比較簡單，請求進入到漏桶中，漏桶以一定的速率漏水。當請求過多時，水直接溢位。可以看出，漏桶演算法可以強制限制資料的傳輸速度。

如圖所示，把請求比作是水滴，水先滴到桶裡，透過漏洞並以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢位，即拒絕服務。

漏桶的出水速度是恆定的，那麼意味著如果瞬時大流量的話，將有大部分請求被丟棄掉（也就是所謂的溢位）。

令牌桶演算法

令牌桶演算法的原理是系統以一定速率向桶中放入令牌，如果有請求時，請求會從桶中取出令牌，如果能取到令牌，則可以繼續完成請求，否則等待或者拒絕服務。這種演算法可以應對突發程度的請求，因此比漏桶演算法好。

漏桶演算法和令牌桶演算法的選擇

兩者的主要區別漏桶演算法能夠強行限制處理資料的速率，不論系統是否空閒。而令牌桶演算法能夠在限制資料的平均處理速率的同時還允許某種程度的突發流量。

如何理解上面的含義呢？

漏桶演算法，比如系統吞吐量是 120/s，業務請求 130/s，使用漏斗限流 100/s，起到限流的作用，多餘的請求將產生等待或者丟棄。

對於令牌桶演算法，每秒產生 100 個令牌，系統容量 200 個令牌。正常情況下，業務請求 100/s 時，請求能被正常被處理。當有突發流量過來比如 200 個請求時，因為系統容量有 200 個令牌可以同一時刻處理掉這 200 個請求。如果是漏桶演算法，則只能處理 100 個請求，其他的請求等待或者被丟棄。