Sql 向具有聚集索引的表中添加新行时，是否保持了行的物理顺序？

在IDS？.SE？。。SQL Server、Oracle、MySQL和其他自动将新行插入数据文件中的适当位置以维护集群。

Informix处理集群索引的方法是重建表（和索引），以便在创建索引时表中的数据处于索引的正确物理序列中。此后，在最合适的位置插入行，这不会继续保持聚集顺序。自（1985年的Informix SQL 1.10）1986年的Informix SQL 2.10（可能是2.00；我还没有这方面的手册）到2010年的Informix Dynamic Server 11.70，情况就是这样

声明：

ALTER INDEX idxname TO NOT CLUSTERED;

ALTER INDEX idxname TO CLUSTERED;

他总是很快。补充声明：

ALTER INDEX idxname TO NOT CLUSTERED;

ALTER INDEX idxname TO CLUSTERED;

通常是一个缓慢的过程，包括在删除旧表和索引之前创建表和索引的全新版本

---

---

ISQL 1.10手册没有ALTER索引；2.10手册中确实有更改索引。

我不能回答IDS问题，但我可以回答您提到的一些问题

这取决于平台：它是否使用页面，是否将数据与索引树分离

通常，不会维护行的物理顺序：只能维护逻辑顺序

原因：你不能在固定大小的页面上“腾出空间”（正如波希米亚人所建议的）

因此，如果您扩展一行（例如向长varchar添加更多数据）或在行之间插入（

ID=3

interrows

ID in（2,4）

），则会发生以下情况之一

• 行被带到带有指针的新页
• 行溢出（例如SQL Server 2005+）
• 页面被拆分

---

这会导致逻辑/索引碎片化和数据密度降低（每页）：这就是为什么我们需要索引维护来删除它。

“…插入最合适的位置…”意思是像在EOF？。。我不再使用2.10，我已经升级到了4.10（DOS），并且在虚拟PC 2007下运行良好。在SELECT语句中卸载带有ORDER BY的表，然后重新创建表和索引，这相当于创建聚集索引？。。我每七天做一次，处理20000个NROW效果很好，但可以想象，处理500000个NROW需要很长时间。我的目标是，当我查询20000个客户中的一个时，我希望快速响应以查找子表中所有查询的客户交易。。如果客户事务分散在整个表中，则返回这些事务所需的时间较长，而按customer.id对这些事务进行聚类将它们放在一起。@Frank:“意思是像在EOF一样”；如果您没有删除任何内容，则在结尾处为“是”。如果删除了行，那么这些插槽可能会被重用。对使用ORDER BY卸载，然后再加载，本质上与创建聚集索引相同-尽管系统上的工作负载更高，因为聚集索引不必在卸载时将所有数据传输到客户端，然后在加载时将其传输回服务器。根据客户ID定期聚集索引将使事情足够接近总之，响应时间不会受到明显影响。当然，一些记录可能分散在其他记录之外，但您不太可能注意到，而且大多数记录将靠得很近。此表中的任何行都不会被用户或进程删除，因此新行将放置在EOF。我尝试在fk_id上卸载、重新加载和创建非聚集索引，与将索引改为聚集索引相比，使用非聚集索引时，查询检索时间要快得多！。。我认为使用聚集索引比使用非聚集索引检索更快。你能解释一下基于成本的查询优化器是如何处理这个问题的吗？