批量鎖（適用各種關係型資料庫）

自己原文公眾號： https://mp.weixin.qq.com/s/3zyXC0oJtMV2hEZ6v_e2pg

   一次處理Oracle問題。看到AWR已經這樣了。說明後臺屬於慘不忍睹。

其實每個資料庫都應該有這麼一個類似AWR的才好判斷。迄今為止PG上國內瀚高做了一個類似的，連介面樣式都雷同AWR，是比較好的。希望有一天MySQL官方也出一個AWR。

     原因我這裡不貼資料了，結論是鎖導致的。分析下來是批量鎖造成的。首先說明一下資料庫不怕併發，一般來說主流資料庫併發處理一行保守估計每秒100次是沒有問題的。僅僅這個資料庫而言在發生問題的時段另外一個表每秒執行了2萬次的更新。所以不是資料庫問題，而是表和SQL的問題。

    既然同一個資料庫每秒能執行這麼多，怎麼會鎖？這就說說場景了，一般來說就像我們12306，有人買上海到北京的，有人買北京到廣州等等，都能分散。也有一等、二等座等等。每次我們每人只買一個。但是也有人報一節車廂。所以就分為單買和團購兩種。單買併發多，每個也快。團購這種少，團購一次性上百張，會多花一點時間。但是不太可能有併發團購的場景。就像我們查一條資料很快，查幾年的報表就會慢一點。但是沒人會批量併發出報表吧？

     而事實就是發生了，我見過報表有併發出的場景。（不合理吧？但是就是有）所以併發批量團購（併發批量改也一樣是可能的）

    這個很好重現，上資料。這個表有100萬資料，查詢一下50毫秒。（因為就2列，但是即使列多在億級別這都不叫事），其實無論MySQL和PG單表也是可以的。

執行一個批量改的儲存過程，模擬批量團購。

5秒完成10萬行記錄的更新。

所以一秒2萬行的更新是輕鬆的，也是做得到的。

接下來併發團購模擬一下（儘管這種不合理）

可以看出一個是5秒（沒變化），另外一個是8秒，多了3秒。這個多的就是在等第一個批量執行完成。

     也就是說如果多幾個乃至幾十個批量更新，越在後面的執行時間越長，因為她要等在她之前的所有批量執行完畢。這都是鎖等待。就我復現的場景而言，如果併發的間隔控制在5秒以上還能滿足的這個不合理的場景。