<div class="paragraphs-wrap">html
<div class="ui internally grid translate-paragraph" data-paragraph-id="64659" data-translated-paragraph-id="64674">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<p>
既然 <a href="https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally-available/" target="_blank" rel="nofollow">MySQL 8</a> 和 <a href="https://www.postgresql.org/about/news/1786/" target="_blank" rel="nofollow">PostgreSQL 10</a> 已經發布了，如今是時候回顧一下這兩大開源關係型數據庫是如何彼此競爭的。
</p> <p> 在這些版本以前，人們廣泛認爲，Postgres 在功能集表現更出色，也因其「學院派」風格而備受稱讚，MySQL 則更善長大規模併發讀/寫。 </p> <p> 可是隨着它們最新版本的發佈，二者之間的差距明顯變小了。 </p> </div> <div class="four wide computer tablet only column translate-user"> <div class="ui items"> <div class="item"> <a class="ui image" href="https://my.oschina.net/u/1391023" target="_blank"> <div class="osc-avatar small-portrait _35x35 avatar" title="LinuxTech" data-user-id="1391023"> <span class="text-portrait" style="background: #e74c3c">L</span> </div> </a> <div class="content"> <a href="https://my.oschina.net/u/1391023" target="_blank" class="ui small header user __user">LinuxTech</a> <div class="extra"> <div class="ui mini list"> <div class="item">翻譯於 2018/05/28 21:26</div> </div> <div class="ui mini labeled button"> <div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64674"> <i class="thumbs up outline icon"></i> 頂 </div> <span class="ui active disabled basic label vote-count">1</span> </div> <div class="ui small horizontal list actions">mysql
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64660" data-translated-paragraph-id="64675">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h2>
特性比較<br></h2><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">讓咱們來看看咱們都喜歡談論的「時髦」功能。</span></p><p></p><table><tbody><tr><th>
特性 </th><th>
MySQL 8 </th><th>
PostgreSQL 10 </th></tr></tbody><tbody><tr><th>
查詢 & 分析 </th><th><br></th><th><br></th></tr><tr><td style="word-break: break-all;">公用表表達式 (CTEs) </td><td>
✔ New </td><td>
✔ </td></tr><tr><td style="word-break: break-all;">
窗口函數</td><td>
✔ New </td><td>
✔ </td></tr><tr><th>
數據類型 </th><th><br></th><th><br></th></tr><tr><td style="word-break: break-all;">
JSON 支持 </td><td>
✔ Improved </td><td>
✔ </td></tr><tr><td>
GIS / SRS </td><td>
✔ Improved </td><td>
✔ </td></tr><tr><td>
全文檢索 </td><td>
✔ </td><td>
✔ </td></tr><tr><th>
可擴展性 </th><th><br></th><th><br></th></tr><tr><td>
邏輯複製 </td><td>
✔ </td><td>
✔ New </td></tr><tr><td>
半同步複製 </td><td>
✔ </td><td>
✔ New </td></tr><tr><td style="word-break: break-all;">聲明式分區 </td><td>
✔ </td><td style="word-break: break-all;">
✔ New</td></tr></tbody></table><p></p><p>過去常常會說 MySQL 最適合在線事務，PostgreSQL 最適合分析流程。但如今不是了。</p><p>公共表表達式(CTEs) 和窗口函數是選擇 PostgreSQL 的主要緣由。可是如今，經過引用同一個表中的 boss_id 來遞歸地遍歷一張僱員表，或者在一個排序的結果中找到一箇中值（或 50%），這在 MySQL 上再也不是問題。</p><p>在 PostgreSQL 中進行復制缺少配置靈活性，這就是 <a href="https://eng.uber.com/mysql-migration/" target="_blank" rel="nofollow">Uber 轉向 MySQL</a> 的緣由。可是如今，有了邏輯複製特性，就能夠經過建立一個新版本的 Postgres 並切換到它來實現零停機升級。在一個巨大的時間序列事件表中截斷一個陳舊的分區也要容易得多。</p><p>就特性而言，這兩個數據庫如今都是一致的。</p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193">
<span class="text-portrait" style="background: #f1c40f">雪</span>
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/28 22:13</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64675">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">1</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64661" data-translated-paragraph-id="64676">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h2>
有哪些不一樣之處呢？<br>
</h2> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">如今，咱們只剩下一個問題 —— 那麼，選擇一個而不選另外一個的緣由是什麼呢？</span> </p> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;"><strong>生態系統</strong>是其中一個因素。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">MySQL 有一個充滿活力的生態系統，包括 MariaDB、Percona、Galera 等等，以及除 InnoDB 之外的存儲引擎，但這也多是和使人困惑的。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">Postgres 的高端選擇有限，但隨着最新版本引入的新功能，這會有所改變。</span> </p> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;"><strong>治理</strong>是另外一個因素。當 Oracle（或最初的 SUN）收購 MySQL時，每一個人都擔憂他們會毀掉這個產品，但在過去的十年裏，這並非事實。事實上，在收購以後，發展反倒加速了。而 Postgres 在工做管理和協做社區方面有着豐富的經驗。</span> </p> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;"><strong>基礎架構</strong>不會常常改變，<span style="color:#333333;font-family:Arial, "font-size:13.3333px;line-height:26px;background-color:#FFFFFF;">雖然近來沒有對這方面的詳細討論，</span>這也是值得再次考慮的。</span> </p> <p> <span style="font-size:10pt;">來複習下：</span> </p> <table> <tbody> <tr> <th> 特性 </th> <th> MySQL 8 </th> <th> PostgreSQL 10 </th> </tr> </tbody> <tbody> <tr> <td> 架構 </td> <td> 單進程 </td> <td> 多進程 </td> </tr> <tr> <td> 併發 </td> <td> 多線程 </td> <td> fork(2) </td> </tr> <tr> <td> 表結構 </td> <td> 聚簇索引 </td> <td> 堆 </td> </tr> <tr> <td> 頁壓縮 </td> <td> Transparent </td> <td> TOAST </td> </tr> <tr> <td> 更新 </td> <td> In-Place / Rollback Segments </td> <td> Append Only / <a href="http://www.interdb.jp/pg/pgsql07.html" rel="nofollow">HOT</a> </td> </tr> <tr> <td> 垃圾回收 </td> <td> 清除線程 </td> <td> 自動清空進程 </td> </tr> <tr> <td> 事務日誌 </td> <td> REDO Log (WAL) </td> <td> WAL </td> </tr> <tr> <td> 複製日誌 </td> <td> Separate (Binlog) </td> <td> WAL </td> </tr> </tbody> </table> </div> <div class="four wide computer tablet only column translate-user"> <div class="ui items"> <div class="item"> <a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank"> <div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193"> <span class="text-portrait" style="background: #f1c40f">雪</span> </div> </a> <div class="content"> <a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a> <div class="extra"> <div class="ui mini list"> <div class="item">翻譯於 2018/05/28 22:28</div> </div> <div class="ui mini labeled button"> <div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64676"> <i class="thumbs up outline icon"></i> 頂 </div> <span class="ui active disabled basic label vote-count">2</span> </div> <div class="ui small horizontal list actions">sql
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64662" data-translated-paragraph-id="64677">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h3>進程vs線程</h3><p>當 <a href="https://www.postgresql.org/docs/10/static/tutorial-arch.html" target="_blank" rel="nofollow">Postgres 派生出一個子進程</a>來創建鏈接時，<a href="https://www.citusdata.com/blog/2017/05/10/scaling-connections-in-postgres/" target="_blank" rel="nofollow">每一個鏈接最多能夠佔用 10MB</a>。與 MySQL 的線程鏈接模型相比，它的內存壓力更大，在 64 位平臺上，線程的默認堆棧大小爲 256KB。（固然，線程本地排序緩衝區等使這種開銷變得不那麼重要，即便在不能夠忽略的狀況下，仍然如此。）</p><p>儘管「<a href="https://en.wikipedia.org/wiki/Copy-on-write" target="_blank" rel="nofollow">寫時複製</a>」保存了一些與父進程共享的、不可變的內存狀態，可是當您有 1000 多個併發鏈接時，基於流程的架構的基本開銷是很繁重的，並且它多是容量規劃的最重要的因素之一。</p><p>也就是說，若是你在 30 臺服務器上運行一個 Rails 應用，每一個服務器都有 16 個 CPU 核心 32 線程，那麼你有 960 個鏈接。可能只有不到 0.1% 的應用會超出這個範圍，但這是須要記住的。</p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193">
<span class="text-portrait" style="background: #f1c40f">雪</span>
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/28 22:41</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64677">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">1</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64663" data-translated-paragraph-id="64678">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h3>
聚簇索引 vs 堆表<br>
</h3> <p> <a href="https://docs.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described?view=sql-server-2017" target="_blank" rel="nofollow"><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">聚簇索引</span></a><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">是一種表結構，其中的行直接嵌入其主鍵的 b 樹結構中。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">一個（非彙集）堆是一個常規的表結構，它與索引分別填充數據行。</span> </p> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">有了聚簇索引，當您經過主鍵查找記錄時，單次 I/O 就能夠檢索到整行，而非集羣則老是須要查找引用，至少須要兩次 I/O。因爲外鍵引用和 JOIN 將觸發主鍵查找，因此影響可能很是大，這將致使大量查詢。</span> </p> <p> <span style="color:#333333;"><span style="font-family:Arial, font-size:13.3333px;line-height:26px;background-color:#FFFFFF;">聚簇</span></span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">索引的一個理論上的缺點是，當您使用二級索引進行查詢時，它須要遍歷兩倍的樹節點，第一次掃描二級索引，而後遍歷<span style="color:#333333;font-family:Arial, "font-size:13.3333px;line-height:26px;background-color:#FFFFFF;">彙集</span>索引，這也是一棵樹。</span> </p> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">可是，若是按照現代<a href="https://en.wikipedia.org/wiki/Convention_over_configuration" target="_blank" rel="nofollow">表設計的約定</a>，將一個自動增量整數做爲主鍵<a href="https://blog.dumper.io/showdown-mysql-8-vs-postgresql-10/#fn1" target="_blank" rel="nofollow">[1]</a>——它被稱爲<a href="https://en.wikipedia.org/wiki/Surrogate_key" target="_blank" rel="nofollow">代理鍵</a>——那麼擁有一個<a href="https://www.mssqltips.com/sqlservertutorial/3209/make-sure-all-tables-have-a-clustered-index-defined/" target="_blank" rel="nofollow">彙集索引幾乎老是可取的</a>。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">更重要的是，若是您作了大量的<span style="color:#333333;font-family:Arial, "font-size:13.3333px;line-height:26px;background-color:#FFFFFF;"> ORDER BY id 來</span>檢索最近的（或最老的）N 個記錄的操做，我認爲這是很適用的。</span> </p> <p> <span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">Postgres 不支持彙集索引，而 MySQL(InnoDB)不支持堆。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">但無論怎樣，若是你有大量的內存，差異應該是很小的。</span> </p> </div> <div class="four wide computer tablet only column translate-user"> <div class="ui items"> <div class="item"> <a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank"> <div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193"> <span class="text-portrait" style="background: #f1c40f">雪</span> </div> </a> <div class="content"> <a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a> <div class="extra"> <div class="ui mini list"> <div class="item">翻譯於 2018/05/28 22:54</div> </div> <div class="ui mini labeled button"> <div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64678"> <i class="thumbs up outline icon"></i> 頂 </div> <span class="ui active disabled basic label vote-count">0</span> </div> <div class="ui small horizontal list actions">數據庫
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64664" data-translated-paragraph-id="64679">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h3>頁結構和壓縮</h3><p>Postgres 和 MySQL 都有基於頁面的物理存儲。(8KB vs 16KB)</p><p><img alt="" src="https://static.oschina.net/uploads/space/2018/0528/115001_ZvRa_2720166.png" class="zoom-in-cursor"><br><a href="http://rachbelaid.com/introduction-to-postgres-physical-storage/" rel="nofollow">PostgreSQL 物理存儲的介紹</a></p><p>頁結構看起來就像右邊的圖。它包含一些咱們不打算在這裏討論的條目，可是它們包含關於頁的元數據。條目後面的項是一個數組標識符，由指向元組或數據行的（偏移、長度）對組成。在 Postgres 中，相同記錄的多個版本能夠以這種方式存儲在同一頁面中。</p><p><img alt="" src="https://static.oschina.net/uploads/space/2018/0528/115017_2Ujt_2720166.jpg" class="zoom-in-cursor"><br>MySQL 的表空間結構與 Oracle 類似，它有多個層次，包括層、區段、頁面和行層。</p><p>此外，它還有一個用於撤銷的單獨段，稱爲「回滾段」。與 Postgres 不一樣的是，MySQL 將在一個單獨的區域中保存同一記錄的多個版本。</p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193">
<span class="text-portrait" style="background: #f1c40f">雪</span>
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/28 23:01</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64679">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">0</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64665" data-translated-paragraph-id="64680">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<p>若是存在一行必須適合兩個數據庫的單個頁面，，這意味着一行必須小於 8KB。（至少有 2 行必須適合 MySQL 的頁面，恰巧是 16KB/2 = 8KB）</p><p><br></p><p><img alt="" src="https://static.oschina.net/uploads/space/2018/0528/115033_Akyb_2720166.png" class="zoom-in-cursor"><br>那麼當你在一個列中有一個大型 JSON 對象時會發生什麼呢？</p><p>Postgres 使用 <a href="https://wiki.postgresql.org/wiki/TOAST" target="_blank" rel="nofollow">TOAST</a>，這是一個專用的影子表(shadow table)存儲。當行和列被選中時，大型對象就會被拉出。換句話說，大量的黑盒不會污染你寶貴的緩存。它還支持對 TOAST 對象的壓縮。</p><p>MySQL 有一個更復雜的特性，叫作<a href="https://dev.mysql.com/doc/refman/8.0/en/innodb-page-compression.html" target="_blank" rel="nofollow">透明頁壓縮</a>，這要歸功於高端 SSD 存儲供應商 <a href="https://en.wikipedia.org/wiki/Fusion-io" target="_blank" rel="nofollow">Fusio-io</a> 的貢獻。它設計目的是爲了更好地使用 SSD，在 SSD 中，寫入量與設備的壽命直接相關。</p><p>對 MySQL 的壓縮不只適用於頁面外的大型對象，並且適用於全部頁面。它經過在<a href="https://en.wikipedia.org/wiki/Sparse_file" target="_blank" rel="nofollow">稀疏文件</a>中使用打孔來實現這一點，這是被 <a href="https://en.wikipedia.org/wiki/Ext4" rel="nofollow">ext4</a> 或 <a href="https://en.wikipedia.org/wiki/Btrfs" rel="nofollow">btrfs</a> 等現代文件系統支持的。</p><p>有關更多細節，請參見：<a href="https://mariadb.org/significant-performance-boost-with-new-mariadb-page-compression-on-fusionio/" target="_blank" rel="nofollow">在 FusionIO 上使用新 MariaDB 頁壓縮得到顯著的性能提高</a>。</p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193">
<span class="text-portrait" style="background: #f1c40f">雪</span>
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/28 23:08</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64680">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">0</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64666" data-translated-paragraph-id="64681">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h3>
更新的開銷<br></h3><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">另外一個常常被忽略的特性，可是對性能有很大的影響，而且多是最具爭議的話題，是更新。</span></p><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">這也是Uber放棄Postgres的另外一個緣由，這激起了許多Postgres的支持者來反駁它。</span></p><ul><li><p><a href="https://dzone.com/articles/on-ubers-choice-of-databases" rel="nofollow">MySQL 對Uber</a><a href="https://dzone.com/articles/on-ubers-choice-of-databases" rel="nofollow">可能</a>是合適的, 可是未必對你合適 </p></li><li><p><a href="http://thebuild.com/presentations/uber-perconalive-2017.pdf" rel="nofollow">一篇PostgreSQL對Uber的迴應 (PDF)</a></p></li></ul><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">二者都是MVCC數據庫，它們能夠隔離多個版本的數據。</span></p><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">爲了作到這一點，Postgres將舊數據保存在堆中，直到被清空，而MySQL將舊數據移動到一個名爲回滾段的單獨區域。</span></p><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">在Postgres中，當您嘗試更新時，整個行必須被複制，以及指向它的索引條目也被複制。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">這在必定程度上是由於Postgres不支持彙集索引，因此從索引中引用的一行的物理位置不是由邏輯鍵抽象出來的。</span></p><p><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">爲了解決這個問題，Postgres使用了<a href="http://www.interdb.jp/pg/pgsql07.html" target="_blank" rel="nofollow">堆上元組</a>（HOT），在可能的狀況下不更新索引。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">可是，若是更新足夠頻繁（或者若是一個元組比較大），元組的歷史能夠很容易地超過8 KB的頁面大小，跨越多個頁面並限制該特性的有效性。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">修剪和/或碎片整理的時間取決於啓發式解決方案。</span><span style="color:#333333;font-family:Arial, "font-size:14px;line-height:26px;background-color:#FFFFFF;">另外，設置不超過100的<a href="https://www.postgresql.org/docs/10/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS" target="_blank" rel="nofollow">填充參數</a>會下降空間效率——這是一種很難在建立表時考慮的折衷方案。</span></p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/u/2560193" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="雪落無痕xdj" data-user-id="2560193">
<span class="text-portrait" style="background: #f1c40f">雪</span>
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/u/2560193" target="_blank" class="ui small header user __user">雪落無痕xdj</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/28 23:16</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64681">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">0</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64667" data-translated-paragraph-id="64692">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<p>
這種限制更深刻; 由於索引元組沒有關於事務的任何信息，因此直到9.2以前一直不能支持<a href="https://use-the-index-luke.com/sql/clustering/index-only-scan-covering-index" target="_blank" rel="nofollow">僅索引掃描</a>。 它是全部主要數據庫（包括MySQL，Oracle，IBM DB2和Microsoft SQL Server）支持的最古老，最重要的優化方法之一。 但即便使用最新版本，當有許多UPDATE在<a href="http://www.interdb.jp/pg/pgsql06.html#_6.2." target="_blank" rel="nofollow">可見性映射</a>中設置髒位時，Postgres也不能徹底支持僅索引掃描，而且在咱們不須要時常常選擇Seq掃描。</p><p>
在MySQL上，更新發生在原地，舊的行數據被封存在一個稱爲回滾段的獨立區域中。 結果是你不須要VACUUM，而且提交很是快，而回滾相對較慢，這對於大多數用例來講是一個可取的折衷。</p><p>
它也<a href="https://www.percona.com/blog/2011/01/12/innodb-undo-segment-siz-and-transaction-isolation/" target="_blank" rel="nofollow">足夠聰明</a>，儘快清除歷史。 若是事務的隔離級別設置爲<strong>READ-COMMITTED</strong>或更低，則在語句完成時清除歷史記錄。</p><p>
事務記錄的大小不會影響主頁面。 碎片化是一個僞命題。 所以，在MySQL上能更好，更可預測總體性能。</p><p><br></p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/crooner" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="溪邊九節" data-user-id="553781">
<img src="https://static.oschina.net/uploads/user/276/553781_50.jpeg?t=1514855267000" alt="溪邊九節" title="溪邊九節">
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/crooner" target="_blank" class="ui small header user __user">溪邊九節</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/30 09:34</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64692">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">0</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui internally grid translate-paragraph" data-paragraph-id="64668" data-translated-paragraph-id="64682">
<div class="row">
<div class="twelve wide computer twelve wide tablet sixteen wide mobile column content translate-content">
<h3>
Garbage Collection 垃圾回收<br></h3><p>在Postgres中VACUUM上開銷很高，由於它在主要工做在堆區，形成了直接的資源競爭。它感受就像是編程語言中的垃圾回收 - 它會擋在路上，並隨時讓你停下來。<br><br>爲具備數十億記錄的表配置<a href="https://www.citusdata.com/blog/2016/11/04/autovacuum-not-the-enemy/" rel="nofollow">autovacuum</a>仍然是一項挑戰。<br><br>在MySQL上清除（Purge）也可能至關繁重，但因爲它是在單獨的回滾段中使用專用線程運行的，所以它不會以任何方式影響讀取的併發性。即便使用<a href="https://dev.mysql.com/doc/refman/8.0/en/innodb-improved-purge-scheduling.html" rel="nofollow">默認配置</a>，變膨脹的回滾段使你執行速度減慢的可能性也是很低的。<br><br>擁有數十億記錄的繁忙表不會致使MySQL上的歷史數據膨脹，諸如存儲上的文件大小和查詢性能等事情上幾乎是能夠預測的而且很穩定。</p>
</div>
<div class="four wide computer tablet only column translate-user">
<div class="ui items">
<div class="item">
<a class="ui image" href="https://my.oschina.net/tocy" target="_blank">
<div class="osc-avatar small-portrait _35x35 avatar" title="Tocy" data-user-id="734219">
<img src="https://static.oschina.net/uploads/user/367/734219_50.jpeg?t=1488431231000" alt="Tocy" title="Tocy">
</div>
</a>
<div class="content">
<a href="https://my.oschina.net/tocy" target="_blank" class="ui small header user __user">Tocy</a>
<div class="extra">
<div class="ui mini list">
<div class="item">翻譯於 2018/05/29 09:13</div>
</div>
<div class="ui mini labeled button">
<div class="ui mini basic button vote-up-btn" data-translated-paragraph-id="64682">
<i class="thumbs up outline icon"></i> 頂
</div>
<span class="ui active disabled basic label vote-count">0</span>
</div>
<div class="ui small horizontal list actions">
</div>
</div>
</div>
</div>
<div class="item footer-info">
</div>
</div>
</div>
</div>
</div>
<div class="ui basic center aligned segment pagination-wrap">
<div class="ui pagination menu">
<a class="disabled item prev-item"><</a>
<a href="?lang=chs&p=1" class="active item page-num-item">1</a>
<a href="?lang=chs&p=2" class="item page-num-item">2</a>
<a href="?lang=chs&p=2" class="item next-item">></a>
</div>
</div>
</div>
原文地址：https://www.oschina.net/translate/showdown-mysql-8-vs-postgresql-10編程