鎖定是否意味著等待？

我真的不明白在並發數據訪問的情況下等待的承諾。

所有手冊均按期限鎖定。沒有人解釋鎖可能會導致 SQL 客戶端在伺服器端等待鎖獲取（並且可能需要幾秒/分鐘/無窮大）？

是否存在鎖不會導致等待的情況？我能想像：

• 可能READ UNCOMMITTED在某些情況下，比如沒有 DDL？
• 不等就報錯了…
• 沒有人等待，但誰先commit獲勝，其他人失敗commit

我回顧了JDBC API：它從字面上提到：

SQLTimeoutException - 當驅動程序確定已超過****setQueryTimeout方法指定的超時值並且至少嘗試取消目前正在執行的語句時`

根據文件在客戶端檢測到超時。廣泛使用的客戶端 API對伺服器端超時沒有影響（包括由鎖引起的）。可能您可以設置一些專有的連接屬性來影響數據庫行為。

我看到了一些專有的 SQL 擴展，例如：

• https://docs.microsoft.com/en-us/sql/t-sql/statements/set-lock-timeout-transact-sql SET LOCK_TIMEOUT timeout_period
• https://www.postgresql.org/docs/13/runtime-config-client.html set lock_timeout ms &set statement_timeout ms

對我來說**，由於鎖而等待的**數據庫是一個灰色區域。鎖定是否意味著等待？

在大多數情況下，鎖不會導致等待。

想像一下，我有一個簡單的銀行系統。為了將資金從賬戶 A 轉移到賬戶 B，我啟動了一個事務並在兩個賬戶記錄上獲取了行級鎖。這讓我可以執行我的驗證（即 A 有足夠的資金進行轉賬，欺詐部門在任何一個賬戶上都沒有標記，等等），更新兩個賬戶以反映新余額，生成任何需要的日誌記錄，然後送出無需擔心其他會話已對一個或兩個帳戶進行了更改，而這本應阻止轉移。

除非在我正在處理嘗試鎖定 A 或 B 的傳輸的幾分之一秒內出現其他會話，否則我獲得的鎖不會產生任何等待。當然，另一個會話可能會在我的會話同時處理 A 的事務，因此需要鎖定。但考慮到需要處理的數千個賬戶和數百萬筆交易，鎖的競爭不太可能發生。特別是如果我明智地設計系統，例如，特定帳戶的所有批處理交易都由一個執行緒處理。如果沒有爭用，就沒有等待。

引用自：https://dba.stackexchange.com/questions/289106