降序索引 -- 现在 MySQL 还不支持这个功能，不过这比很多人想的那样，问题少多了。首先，如果索引是顺序的并不意味着它不能倒序扫描，实际上它表现得挺好的。这就是为什么 MySQL 能优化例如 ORDER BY col DESC 查询的索引。倒序扫描能和正序扫描一样快，不过这些是由存储引擎和操作系统来处理的。例如有些操作系统无法倒序读，这对速度有所降低。或者某些存储引擎，如 MyISAM (它压缩了索引) 倒序扫描时比正序扫描来的慢。
那么什么时候才真的需要倒序索引呢？很多典型的情况是当你想要对两个字段作不同方向的排序时：使用 ORDER BY price ASC, date DESC LIMIT 10。如果已经有了对 (price,date) 的正序索引，则不能较好地优化这个查询 -- 需要用到外部排序(“filesort”)。如果能建立 price ASC, date DESC 的索引，那么这个查询就能按照已经排好的顺序取出数据了。
然而，常见的变通办法是创建一个“倒序数据”字段，并且利用它来排序。在 MySQL 5.0 中你甚至可以使用触发器来更新真实的数据使得更合适。这就是为什在 Wikipedia 的表结构中有一个 “reverse_timestamp” 字段的缘故。
减少索引扫描 -- 多年前当我刚开始使用 MySQL 时，我想它也许有些优化方法能让我记住。例如如果有一个 (A>0 and B>6) 分句和索引 (A,B)，我期望能使用索引来查找所有 A>0 的值，并且能立刻跳转到 B>6 的记录上，我想这是可行的。不过令我郁闷的是竟然不支持，并且这种优化方法还未实现。在设计新的应用程序或者移植数据库时，记住这个特点很重要。设计 MySQL 索引时只需设计保证能让索引最后的所有索引部分都使用 “=” 查询。只有最后一个索引部分才支持 “range” 分句、IN 等。所有在范围索引后面的分句都不会使用到索引。
举几个例子吧，索引 (A,B,CP) 和 A=5 and B>6 and C=7 分句的情况下，索引会检索 A=5 和 B>6 的条件，C=7 则不会用到索引(所有包含 C 的记录都会从索引中检索得到)。这个时候如果任何查询都无需使用完整的索引的话，就可以缩短索引为 KEY(A,B)，这样能让索引变小。
一个好消息是，减少索引扫描终究会以某种方式实现。MySQL 5.0 中其实已经实现了，不过只适用于少数情况的聚合查询。常规意义上的完全减少索引扫描是我最想要实现的MySQL优化器特性。 |