# mysql vs postgresql
rollback都會跳號

在 PostgreSQL，我們可以使用 MVCC 來解決 幻讀（Phantom Read） 問題，但 MySQL 不能用 MVCC 直接解決這個問題，所以它使用 Gap Lock 來防止新數據插入到範圍內。

原因隔離層級

高併發事務系統（例如金融、電商庫存系統） → PostgreSQL 更好
查詢密集型的 Web 應用（例如 CMS、社交平台） → MySQL 可能更好
需要嚴格的事務隔離（銀行交易） → PostgreSQL 更適合
開發簡單、快速部署（小型 SaaS） → MySQL 更適合
🎯 最終結論：

如果你的應用依賴「高併發事務處理」，PostgreSQL 是更好的選擇，因為它的 MVCC 不需要 Gap Lock，並且 SERIALIZABLE 級別下也不鎖表。
但如果你的應用主要是「讀多寫少」，並且需要更快的讀取性能，MySQL 可能更合適。

# MVCC
MVCC，Multi-Version Concurrency Control，多版本併發控制。MVCC 是一種併發控制的方法，一般在資料庫管理系統中，實現對資料庫的併發訪問；在程式語言中實現事務記憶體。

如果有人從資料庫中讀資料的同時，有另外的人寫入資料，有可能讀資料的人會看到『半寫』或者不一致的資料。有很多種方法來解決這個問題，叫做併發控制方法。最簡單的方法，通過加鎖，讓所有的讀者等待寫者工作完成，但是這樣效率會很差。MVCC 使用了一種不同的手段，每個連線到資料庫的讀者，在某個瞬間看到的是資料庫的一個快照，寫者寫操作造成的變化在寫操作完成之前（或者資料庫事務提交之前）對於其他的讀者來說是不可見的。

當一個 MVCC 資料庫需要更一個一條資料記錄的時候，它不會直接用新資料覆蓋舊資料，而是將舊資料標記為過時（obsolete）並在別處增加新版本的資料。這樣就會有儲存多個版本的資料，但是隻有一個是最新的。這種方式允許讀者讀取在他讀之前已經存在的資料，即使這些在讀的過程中半路被別人修改、刪除了，也對先前正在讀的使用者沒有影響。**這種多版本的方式避免了填充刪除操作在記憶體和磁碟儲存結構造成的空洞的開銷，但是需要系統週期性整理（sweep through）以真實刪除老的、過時的資料。**對於面向文件的資料庫（Document-oriented database，也即半結構化資料庫）來說，這種方式允許系統將整個文件寫到磁碟的一塊連續區域上，當需要更新的時候，直接重寫一個版本，而不是對文件的某些位元位、分片切除，或者維護一個鏈式的、非連續的資料庫結構。

MVCC 提供了時點（point in time）一致性檢視。MVCC 併發控制下的讀事務一般使用時間戳或者事務 ID去標記當前讀的資料庫的狀態（版本），讀取這個版本的資料。讀、寫事務相互隔離，不需要加鎖。讀寫並存的時候，寫操作會根據目前資料庫的狀態，建立一個新版本，併發的讀則依舊訪問舊版本的資料。

一句話總結就是：

MVCC(Multiversion concurrency control) 就是 同一份資料臨時保留多版本的一種方式，進而實現併發控制

###### tags: `資料庫相關`