在非常大的表上按sorting顺序排列的MySQL退役行

我有一个MyISAM表T与以下架构:

f1(整数无符号不为空)f2(整数无符号不为空)

这个表格有一个f2的索引,目前包含了3.2亿行,预计每周会以约20万行的速度增长。 我在这个表上执行以下查询:

SELECT DISTINCT T.f1 FROM T WHERE f2 = @ Var LIMIT?,30

@Var是一个传递给执行这个查询的存储过程的variables,LIMITvariables根据显示的页码(从0开始等)

检索的速度非常好(考虑到表格非常大),但是行按照写入表格的顺序出现(即不按f1顺序)。 我希望能够在上面的查询中包含子句“ORDER BY f1 DESC”,但是,如果不使用INDEX,则会自杀! (有时可能有超过一百万行满足查询,并没有索引sorting可能会杀死服务器)

我的问题是…什么样的指数(es)应该是为了迎合我正在运行的查询,也是为了sorting结果中的行? 如果查询和sorting不能满足使用索引,我正在考虑更新后执行ALTER TABLE T ORDER BY f1 DESC(而用户仍然可以查询数据)。 在这种情况下,在我的开发机器上,alter语句花了大约50分钟,这也不算太坏。 显然,在LIVE机器上,我需要拥有与原始表的大小一样多的磁盘可用空间…是否还有其他需要考虑的事项?

提前感谢蒂姆

我不确定你的假设ORDER BY子句将需要在f1上的索引实际上是正确的。 我创build了这样一个表,跑了

 解释SELECT DISTINCT T.f1作为结果FROM rowtest T WHERE f2 = 10按结果LIMIT 0,30的顺序 

我回来了这个:

 id |  select_type | 表| | 键入|  possible_keys | 键|  key_len |  ref | 行| 额外
 1 | 简单|  T |  ref |  idx_f2 |  idx_f2 |  4 |  const |  3 | 在哪里使用; 使用临时; 使用filesort

现在,服务器将使用临时表和文件的事实并不暗示在这样做的特别快速或有效的方式。 但是,那里没有什么说你需要在f1上的索引。 忽略这个事实,在我的情况下,结果集中只有3行(我无法创build一个拥有3.2亿行的表)。

现在:如果我在列f1的表上添加一个索引,解释的结果根本不会改变,这意味着你是否有索引无关紧要。

原因在于服务器首先检索满足where条件的所有行(使用f2上的索引),然后使用临时文件对其进行sorting。 在检索行时,f1上的索引没有帮助,在订购阶段它不存在。

考虑到你的结果集不会超过30行,临时文件中的sorting不会占用任何时间。 自己尝试一下。

编辑忘记最后一句,那是无稽之谈。 我刚刚意识到LIMIT子句是在sorting发生应用的。 所以:是的,sorting需要一些时间。 如果你的查询真的只返回一个数字列,它应该是相当快,但。 还有一个道理:f1的索引没有任何区别。 Plus:AFAIK,一旦所有行都被检索到,表格就不会被locking,不能进行任何其他访问。 而且,因为这不会改变,所以不pipe你使用ORDER BY子句,对其他用户都没有影响。