1

INFORMIX-SE：

我的用户定期运行一个 SQL 脚本 [REORG.SQL]，它按排序顺序将表中的所有行卸载到两个单独的文件（活动和非活动），删除表，重新创建表，将排序的加载文件加载回其中，在我对卸载文件进行排序的同一列上创建一个集群索引，创建其他支持索引并更新其统计信息。

（参见 REORG.SQL 脚本： SE: 'bcheck -y' anomaly）

（另请参阅：customer.pk_name 加入 transactions.fk_name 与 customer.pk_id [serial] 加入 transactions.fk_id [integer] ，因为集群索引是按名称而不是 pk_id[serial]=fk_id[int]）

使用我的 REORG.SQL 脚本时，我一直遇到索引文件一致性问题，所以我怀疑 CLUSTER INDEX 与它有关，并在没有集群的情况下创建了索引，问题就消失了！

现在我的问题是：如果我设法将按客户全名排序的所有交易数据加载到新创建的表中，我真的有必要创建一个 CLUSTER INDEX，而实际上这些行已经按相同的顺序排序集群会完成吗？..我知道随着新行的添加，集群索引开始失去集群，那么创建集群索引有什么优势？..查询优化器是否利用集群与非集群当行基本上以相同的聚集顺序排列时索引？.. 有没有人在聚集表时遇到 IDX/DAT 文件问题？.. 也许我的 SQL 脚本有问题？（请查看我的 SQL 脚本代码，看看我是否做错了什么？）

4

1 回答 1

2

该脚本将活动和非活动事务卸载到两个不同的文件，每个文件按客户名称排序。然后它将它们加载回表中，首先是活动事务，然后是非活动事务。然后在客户名称上创建聚集索引。问题是数据库现在必须返回并在构建聚集索引时按客户名称重新排序物理行。尽管每个卸载文件都按客户名称单独排序，但将两者放在一起时，结果不会按客户名称排序，从而导致数据库工作量增加。除非在其他地方需要用于活动和非活动事务的单独文件，否则您可以尝试将所有事务转储到单个文件中，按客户名称排序，然后从该单个文件重新加载表。

至于是否真的需要聚集索引 - 如果您使用该列进行查询，聚集索引可能是有价值的，因为它应该有助于减少获取数据所需的 I/O 数量。通常聚集索引是在单调增加的列上创建的，因此 TRX_NUM 可能会很好地用作要在聚集索引上命名的列。

分享和享受。

于 2010-08-05T11:29:44.003 回答