是否有可能在某种随机插入和删除模式之后，叶数据节点因聚簇索引而变得碎片化？
也就是说，物理顺序不反映聚集索引强加的逻辑顺序（比如 INT 主键）？这样，范围查询即使在找到间隔开始后也需要随机 I/O。
大多数大学课程（例如 Andy Pavlo 的 CMU 数据库系统简介）都说数据是根据密钥进行物理排序的。虽然绝对接近现实，但在我看来，计算所需的频繁文件碎片整理的成本是不现实的。
AskOverflow.Dev
是否有可能在某种随机插入和删除模式之后，叶数据节点因聚簇索引而变得碎片化？
也就是说，物理顺序不反映聚集索引强加的逻辑顺序（比如 INT 主键）？这样，范围查询即使在找到间隔开始后也需要随机 I/O。
大多数大学课程（例如 Andy Pavlo 的 CMU 数据库系统简介）都说数据是根据密钥进行物理排序的。虽然绝对接近现实，但在我看来，计算所需的频繁文件碎片整理的成本是不现实的。
是的
您可以在自然键或非线性插入的键上创建聚簇索引。例如，使用电子邮件地址、社会安全号码等。在很多情况下，这些都是“足够好”的自然键。或者让数据以不同于 ID 值的物理方式存储更有意义。我认为它们仍然不应该是聚集键，但它确实有意义，并且是聚集索引可能变得碎片化的一种方式。
所以你可能会在那里变得支离破碎，因为一个新的插入可能是无序的，并且当它属于中间时被写入树的末尾。
如果您有删除，您还可以从更典型的表设计中获得碎片。场景是您有一个典型的表，其中包含一个自动递增的 ID 字段。大多数时候这是最佳实践选择。您在该 ID 字段上创建聚集索引。如果您所做的只是插入，这很好。所有新记录都在树的末尾，并按 ID 字段排序。
但是假设您删除了记录……那么现在您有碎片，因为数据页未满。或者以前的空白页面不再连续。
补充说明；您还可以通过更新记录来获得碎片。如果您有一个创建为空的列，但具有最多 100 个字符的可变宽度。当您返回并将其从 NULL 更新为一个值时，这可能会将该行的部分内容推到另一个页面上......这也会导致碎片化。
磁盘布局取决于供应商。
下面是关于 MySQL/MariaDB 中 InnoDB 引擎的一些具体信息。（注意：其他供应商不一定遵循相同的设计。）
UNIQUE.A是B。PRIMARY KEY(a_id, b_id), INDEX(b_id, a_id)请注意，向该表添加 ID 会降低性能。