我知道SELECT在 Postgres 中不需要行鎖。所以我可以從連接 1 中的SELECT某個表發出 a T，然后其他人可以在連接 2 中發出DELETE（同一個表中所有行的T）a，這DELETE不會導致任何阻塞。對？
此處對此進行了描述：
SELECT 是否會阻止回傳的行被洗掉？
好的...我的問題是：這種行為是否取決于ISOLATION LEVEL兩個連接中使用的那個？
我為什么要問這一切？
在現實世界中，我們有一個類似的并發場景（如上），但使用SELECTvs.TRUNCATE TABLE代替。我們有一個阻塞問題，因為TRUNCATE TABLE（不像DELETE * FROM TABLE）需要獨占表鎖（它在 a 運行時無法獲得SELECT）。所以我們正在考慮使用DELETE *而不是TRUNCATE（盡管DELETE速度有點慢）來解決這個阻塞問題。
- 這種方法會奏效嗎？
- 行為是否取決于隔離級別？
uj5u.com熱心網友回復：
無論您使用什么隔離級別（使用REPEATABLE READ或更高級別，您當然可以得到序列化錯誤，但這無關緊要），您的解決方案都會起作用。
但是，TRUNCATE效率會高得多。如果鎖有問題，則表明您有長時間運行的事務使用該表。盡量避免這種情況，因為長事務通常是有問題的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/465857.html
標籤：sql PostgreSQL
上一篇：psql沒有使用正確的組態檔