這邊是比較好的討論平台，所以把我的心得放這邊好了。

就我看完的想法是， Database 效能影響的點有兩個，第一個是 index tree 的維護，第二個是「資料在硬碟上的儲存方式」

前者兩者用的都是 b+tree ，所以有同樣的問題，如果照 PK 循序寫入，因為樹會變的不平衡，會需要常常重新平衡樹，會有 lock tree or sub-tree 的發生，這時 DB 的效能會下降。

在儲存方式上，MySQL用的是 Index Optimized Table ，儲存資料的方式是照 index 的型式去寫入，所以循序寫入也有「平衡」的需求。而 PostgreSQL 則是有洞就塞，再用另外一張表去儲存 key -> 儲存位址。在 Update 時，MySQL是 in-place 把值給替換掉， PostgreSQL 則是把「儲存位址」標個墓碑，等 full vaccum 時再清掉

因為不想造成 index 上的 hotspot ， Triton Ho 主張是要用 UUID ，不要在 insert 時，全部都往同一個 sub-tree 寫入，同時也省去了維護 Sequence Generator 的困擾。

這點我是同意的，對 PG 來說，是不是依 PK 的順序寫入跟本沒差，不依 PK 順序寫入，反而對 PG 來說維護 index 的成本較小，在寫入硬碟時，仍是循序寫入。

但是對 MySQL 來說就不一樣了，不依 PK 順序寫入的話，在寫入硬碟時，是 random access ，效能低 40~50%。

所以 Ant 才會說，要用 v1 Time-based UUID ，但是我覺得兩個人的對話跟本沒交集，用 v1 UUID ，那就直接用 Int/Long Sequence 就好了， index size 還可以更小。

至於 VACUUM 我更不覺得是個問題，因為除了 MYSQL 外，我用過的 MongoDB CouchDB Cassandra 全都是設計成要 FULL VACUUM 才會把空間釋放出來，

至於 PG 為什麼要引入 AUTO VACUUM 呢？我猜想是因為有太多非 DBA 的工程師，因為跟本不了解 DB 底層的運作，一跑就跑了半年沒清理過，所以 PG 才要把雞婆的幫使用者跑 VACUUM

( 這裡好酷呀，首波 )

1. 我只是覺得作者 "用 PostgreSQL 的優勢直接對等套用在 MySQL 上，而不考慮 MySQL 特性做修正，然後再說 MySQL 很差"，以藉此推廣 PostgreSQL 比較好的方式很不妥，所以寫了這篇簡報。

2. PostgreSQL 寫入時，單位是 block，然後會與 page 對齊，所以如果 PK 不是順序寫，那表示會落在很多個不同的 pages，如此在 checkpoint 時雖然是順序寫入，但若順著 PK scan 讀出時，就會變成 random read。但後者對 SSD 效能其實影響不大，只是剛好跟 MySQL 建議的方式有點不同。

3. 使用 UUID 是要看情況，因為 MySQL 的 AUTO_INCREMENT 及 PostgreSQL Sequence 本身依賴的就是 locking，所以若要避用的話，PostgreSQL 天生有優勢，但 MySQL 則要小心不要用到 Random UUID (例如 UUIDv4)，否則效能如你所言會差很多。而 MySQL 要用 INT 還是 UUIDv1 就看個人了，因為 UUID 是標準資料交換時通用的 KEY。

4. VACUUM 其實就跟程式語言的 GC 一樣，讓人又愛又恨，一旦累積太多，GC 時就要一點有心理準備，抖動會比平常大一些。MongoDB 及 Cassandra 在發生 GC 時，也一樣很令人頭痛。AUTO VACUUM 其實最大的重點就是，依據內部的偵測機制，讓 PostgreSQL 自行決定什麼時候 VACUUM 最好；再者，PostgreSQL 官方也說了，若是定期 VACUUM，要小心累積太多的 dead tuples，而導致碎片嚴重到 VACUUM 修不好，最終只能 VACUUM FULL 而導致 table lock。

我兩個資料庫都用，確實要看應用而選。不然以 PostgreSQL 狂派傳教士而言，好似用 MySQL 的 Google / Facebook / 阿里巴巴都是笨蛋一樣。