主要区别及示例

简而言之，Postgres 和 MySQL 之间的主要区别实际上归结为主索引和辅助索引的实现方式以及数据的存储和更新方式。

让我们进一步探讨这个问题。

但首先... 基础知识

索引是一种数据结构（主要是 B + 树），允许通过多层节点进行键的搜索，数据库将其实现为页面。树的遍历允许消除不包含结果的页面，并缩小包含结果的页面的范围。这一过程一直持续到找到包含键的叶子页面。

叶子节点或页面包含有序键及其值的列表。当找到一个键时，可以获取其值，并且页面会被缓存在数据库的共享缓冲区中，希望未来的查询可能会请求相同页面中的键。

这最后一句是理解数据库工程、管理、编程和建模的基本原则。了解查询是否命中页面中相邻的键将最大程度地减少 I/O 并提高性能。

B + 树索引中的键是创建索引所在表的列（或多个列），而值在 Postgres 和 MySQL 中的实现方式有所不同。让我们探讨一下 Postgres 和 MySQL 中值的含义。

MySQL

在主索引中，值是带有所有属性 * 的完整行对象。这就是为什么主索引通常被称为聚簇索引或我更喜欢的术语 "索引组织表"。这意味着主索引就是表本身。

* 注意，对于行存储，这是正确的。数据库可能使用不同的存储模型，如列存储、图形或文档存储，从根本上讲，这些也可以作为潜在的值。

如果在主索引中查找一个键，你会找到包含该键的页面和它的值，该值是该键对应的完整行，不需要额外的 I/O 操作来获取其他列。

在二级索引中，键是你索引的列（或多个列），而值是指向实际存储完整行位置的指针。二级索引叶子页面的值通常是主键。

这就是 MySQL 的情况。在 MySQL 中，所有的表都必须有一个主索引，而所有额外的二级索引都指向主键。如果你在 MySQL 表中不创建主键，系统会为你自动创建一个。

Postgres

在 Postgres 中，严格来说没有主索引，所有的索引都是二级索引，它们都指向加载在堆中的数据页中由系统管理的元组标识符（tuple ids）。堆中的表数据是无序的，不像主索引叶子页是有序的。因此，如果你插入了 1-100 行，并且它们都在同一页中，然后后来更新了 1-20 行，这 20 行可能会跳转到另一页，并且变得无序。而在聚簇主索引中，插入操作必须按照键的顺序插入到相应的页中。这就是为什么 Postgres 表通常被称为 " 堆有序表 "而不是" 索引组织表 "。

需要注意的是，在 Postgres 中，更新和删除实际上是插入操作。每次更新或删除都会创建一个新的元组标识符（tuple id），而旧的元组标识符则保留为了多版本并发控制（MVCC）的原因。我稍后会在本文中探讨这个问题。

事实上，仅仅使用元组标识符是不够的。实际上，我们需要同时知道元组标识符和页面编号，这被称为 c_tid。想一想，仅仅知道元组标识符是不够的，我们需要知道元组所在的页。这是在 MySQL 中不需要做的事情，因为我们实际上是通过查找来找到主键所在的页。而在 Postgres 中，我们只需要进行一次 I/O 操作就可以获取到完整的行数据。

查询费用

请参考以下示例中的表格。

#TABLE T; #PRIMARY INDEX ON PK AND SECONDARY INDEX ON C2, NO INDEX ON C1 # C1 and C2 are text # PK is integer | PK | C1 | C2 | |----|----|----| | 1 | x1 | x2 | | 2 | y1 | y2 | | 3 | z1 | z1 |

让我们比较一下 MySQL 和 Postgres 中发生的情况。

SELECT * FROM T WHERE C2 = 'x2';

在 MySQL 中，执行这个查询将会产生两次 B + 树查找。首先，我们需要使用二级索引查找 x2 的主键，找到主键值为 1，然后再使用主索引进行另一次查找，找到完整的行数据，因此返回了所有属性（因此有 * 号）。

在 Postgres 中，查找任何二级索引只需要进行一次索引查找，然后进行一次常量的单个 I/O 操作，以获取包含完整行数据的页。一次 B + 树查找要比两次查找好。

为了使这个示例更加有趣，假设 C2 不是唯一的，并且有多个 x2 的条目，那么我们将会找到匹配 x2 的大量 tids（或在 MySQL 中的 PK）。问题是这些行标识符将位于不同的页面，导致随机读取。在 MySQL 中，这将导致索引查找（根据这些键的数量，查询优化器可能会选择索引扫描还是基于 seek 的操作），但是两个数据库都会导致许多随机 I/O。

Postgres 尝试通过使用位图索引扫描来最小化随机读取，将结果分组为页面而不是元组，并以尽可能少的 I/O 操作从堆中获取页面。然后应用额外的过滤来呈现候选行。

让我们看一个不同的查询。

SELECT * FROM T WHERE PK BETWEEN 1 AND 3;

对于对主键索引的范围查询，我认为 MySQL 在这方面是更好的选择，通过一次查找，我们可以找到第一个键，并在 B + 树链接的叶子页上遍历以找到附近的键，当我们遍历时，我们找到完整的行数据。

Postgres 在这方面可能会遇到一些困难，确实，二级索引查找将在叶子页上进行相同的 B + 树遍历，并找到键，但它只会收集 tids 和页码。它的工作并没有结束。Postgres 仍然需要在堆中进行随机读取，以获取完整的行数据，而这些行数据可能分布在堆中的各个位置，而不是紧凑地排列在一起，特别是如果这些行数据被更新过。

好的，我们来进行一次更新操作。

UPDATE T SET C1 = ‘XX1’ WHERE PK = 1;

在 MySQL 中，更新一个未建立索引的列只会导致更新包含该行的叶子页，并将其更新为新值。不需要更新其他任何二级索引，因为它们都指向的是未发生变化的主键。

在 Postgres 中，更新一个未建立索引的列将生成一个新的元组，并可能需要更新所有的二级索引以使用新的元组 ID，因为它们只知道旧的元组 ID。这会导致许多写入 I/O 操作。Uber 在 2016 年对此不太满意，这也是他们从 Postgres 切换到 MySQL 的主要原因之一。