我一直在尝试加速涉及复杂查询的 ORDER BY 的 MySQL 查询。我已经用尽了几个选项，并且已经非常接近了——我找到了在有问题的表上实现伪反向索引的最佳解决方案。
我基本上效仿了这篇文章的建议（包括使用 id 而不是发布日期的变体，使用联合索引等）： http ://www.igvita.com/2007/08/20/pseudo-reverse-indexes-in -mysql/
并成功添加了额外的列，填充了它，添加了一个索引，但是查询
SELECT * FROM products USE INDEX (index_reverse_created);
似乎不起作用。插入随机单词或常规列代替索引名称会引发错误，因此我意识到它成功检测到索引。
然而，使用 EXPLAIN SELECT *... 进一步检查显示：
http://i44.tinypic.com/2aes304.png
possible_keys和的特殊部分是 (NULL) key。
SHOW INDEX FROM products 产生这个：
http://i41.tinypic.com/fvvdl1.png
这似乎是一组健康的指数。
总的来说，我很难过。似乎索引在那里，但是在尝试实际使用它时出现了问题。