这不是 SQL，而是 UniQuery。
为了澄清这一点，您不能索引文件（somewhere在这种情况下），只能索引文件的列。您可能会发现Column1已编入索引Column2但未编入索引。键入LIST.INDEX somewhere以找出已索引的列。
对于您的问题，您仅比较了在 Column1 上的选择与在 Column1 和 Column2 上的选择，并假设响应速度慢得多纯粹是因为您在 2 列上进行了选择。您的下一个文本应该是仅在 Column2 上进行选择，并看到这有多慢。
除了索引之外，还有许多可能的原因可以解释响应的差异。在 UniData 中，列被定义为“字典项”。字典项有不同类型。最基本的是一个 D 型字典项，它只是对记录中某个字段的直接引用。另一种类型是 I 或 V 类型，它是派生字段。派生字段可以像返回常量一样简单，也可以像执行与另一个文件的 JOIN 和/或某种形式的复杂计算一样复杂。这应该很容易看出，不同的列可能需要大量不同的处理来处理。
其他原因是列在记录中的深度（第一个字段引用将比记录中后面的字段更快）以及可能影响 SELECT 时间的潜在查询缓存。
有关更多信息，请查看Rocket Software上的数据库手册。
索引字段上的单列 SELECT 甚至不需要读取任何数据文件记录。如果您深入了解，您会发现索引文件是一个普通的哈希文件，单列 SELECT 仅表示读取了键为“str”的索引文件记录。这可以在不到一秒的时间内返回成千上万个密钥。
添加第二列后，您可能会强制系统读取所有成千上万条记录，即使第二列已编入索引。这将需要更多的时间。
通常，具有少量唯一值的字段上的索引的用途是可疑的。如果第二列包含具有大量可能值的数据，导致每个特定索引值的记录数量较少，那么最好安排 SELECT 以便使用的索引位于第二列上。我不确定，但可以简单地颠倒 SELECT 语句中列的顺序来执行此操作。否则，您可能需要背靠背运行两个 SELECT 语句。
例如，假设文件有 600,000 条 Column1 = "str" 的记录，以及 2,000 条 Column2 = "int" 的记录：
>SELECT somewhere WITH Column2 = "int"
>>SELECT somewhere with Column1 = "str"
将读取 2,000 条记录并且应该几乎立即返回。
如果您将经常选择 Column1 和 Column2 的组合，那么您可能希望创建一个将两者结合起来的新字典项，并在其上建立索引。
话虽如此，U2 系统不应该花费 5 分钟来运行一百万条记录的文件。文件严重溢出的可能性很大，需要使用更大的模数来调整大小以提高性能。