INFORMIX-SE：
我的用户定期运行一个SQL脚本[REORG.SQL]，它按照排序顺序将表中的所有行卸载到两个单独的文件（活动和非活动），删除表，重新创建表，然后加载已排序的加载文件进入它，在我对卸载文件进行排序的同一列上创建一个集群索引，创建其他支持索引并更新其统计信息。
（参见：SE: 'bcheck -y' anomaly的REORG.SQL脚本）
（另请参阅：customer.pk_name joining transactions.fk_name vs. customer.pk_id [serial] joining transactions.fk_id [integer]，原因是集群索引是按名称而不是pk_id [serial] = fk_id [int]）
使用我的REORG.SQL脚本，我一直有索引文件一致性问题所以我怀疑CLUSTER INDEX与它有关并创建了没有聚类的索引，问题就消失了！
现在我的问题是：如果我设法加载我的所有交易数据，按客户全名排序到新创建的表中，是否真的有必要创建一个CLUSTER INDEX，而实际上行已经排序了集群将完成的顺序相同？我知道聚集索引在添加新行时开始丢失其集群，那么创建集群索引的优势是什么？..查询优化器是否利用了集群与当行基本上处于相同的聚簇顺序时，非聚集索引？有人在聚类表时遇到IDX / DAT文件问题吗？也许我的SQL脚本有问题吗？ （请查看我的SQL脚本代码，看看我是否有些错误？）
答案 0 :(得分：2)
该脚本将活动和非活动事务卸载到两个不同的文件，每个文件按客户名称排序。然后它将它们加载回表，首先是活动事务，然后是非活动事务。然后在客户名称上创建聚簇索引。问题是数据库现在必须在构建聚簇索引时返回并按客户名重新排序物理行。尽管每个卸载文件都是按客户名称单独排序的，但当两者放在一起时，结果不按客户名称排序，从而导致数据库的更多工作。除非在其他地方需要用于活动和非活动事务的单独文件，否则您可以尝试将所有事务转储到单个文件，按客户名称排序，然后从该单个文件重新加载表。此时，表中的数据将按客户名称排序，聚集索引create不必对数据进行重新排序。
关于是否确实需要聚簇索引 - 如果使用该列进行查询，聚簇索引可能有价值，因为它应该有助于减少获取数据所需的I / O数量。通常在列上创建聚簇索引，这些索引会单调增加，因此TRX_NUM可能很好地用作要在聚簇索引上命名的列。
分享并享受。