小编VB_*_*VB_的帖子

提高多达 1 亿行的表的读/写性能的常用方法是什么？

表有 column SEGMENT_ID INT NOT NULL，其中每个段有大约 100.000-1.000.000 行。写入 -SEGMENT_ID一次插入所有行，SEGMENT_ID之后不更新。读取 - 非常频繁，我需要良好的SELECT * FROM table WERE SEGMENT_ID = ?.

最明显的方法是SEGMENT_ID动态创建新表，但动态表意味着使用 ORM 甚至本机 SQL 查询框架进行黑客攻击。换句话说，你完成了有味道的代码。

您也可以使用分片，对吗？数据库是否在幕后创建新表？

我可以通过SEGMENT_ID. 但是，如果我一次插入所有与段相关的数据，我的插入是否会聚集在一起？

Postgres 还建议使用分区来处理非常大的表。

也许有某种神奇的索引可以帮助我避免动态创建新表或配置分片？

还有其他选择吗？

我已经阅读了相同架构/查询的 MySQL 和 PostgreSQL 之间的性能差异。以下是对文章的简要复述：

PostgreSQL 表是堆表（意味着没有聚集索引）......（Postgres）表的主键查找需要点击索引，查找文件中的位置，然后点击堆表并拉出记录。这意味着随机磁盘 I/O 的数量... InnoDB 使用不同的方法。使用 InnoDB，表是一个 b 树索引（聚集，物理排序）...... PK 查找所需的随机磁盘 I/O 更少......同时，索引扫描需要遍历两个索引而不是一个（index -> PK index -> table row )，这意味着使用主键以外的任何索引最终都会变慢，而顺序扫描仍然更慢。

哪种查询使用 Postgres 比使用 MySQL InnoDB 快得多？

我理解为什么 PK 查找对于 MySQL 来说要好得多。我不明白：

1. 为什么通过两个索引（InnoDB，通过非 PK 索引查找）查找要慢得多？它是否需要两倍以上的 I/O 或 CPU？它可以弥补 PK 查找提升的巨大好处吗？
2. 为什么 InnoDB 顺序扫描更慢？

PS Internet 说 Postgres 更适合复杂查询和子查询，但我仍然不明白为什么它更好？

我已经阅读了相同架构/查询的 MySQL 和 PostgreSQL 之间的性能差异。. 它是否仍然与固态硬盘的外观有关？

那篇文章说 Postgres 更适合复杂查询和子查询，而对于通过 id 和顺序扫描进行的简单查询则更差。

对于某些查询，Postgres 更糟糕/更慢，因为每个表都是一个堆，意味着没有聚集索引，意味着行没有按主键在硬盘驱动器上物理排序。因此，如果您想从 Postgres 读取大部分记录（根据我的理解，通过 id） - 如果与 MySQL 相比，这将导致许多随机 I/O 和更差的性能。

问题：

1. 但是SSD呢？Postgres 和 MySQL 的顺序读取性能是否相同？
2. 在 RDBM 中使用 SSD 而不是 HHD 是否有意义？

更新：与 Rick James 的回答有关

1. MySQL 使用Plan A和 Postgres 使用Plan B，对吗？
2. Plan A表示聚集索引，对吗？该表按 物理排序lastName + firstName。
3. Plan A在 HDD 上的性能可能比Plan B在 SSD 上更好，因此 Postgres + SSD 不是灵丹妙药。查询聚集索引需要选择MySQL，对吗？
4. 请详细了解 I/O 绑定是指哪些查询？在我的理解中any call …