| p;
还有一种选择在特定的环境下会使用索引合并（INDEX MERGE），更多信息见INDEX MERGE优化器和Index Merge Optimization。
上述的特定情况不能用于如果两条件的字段是一样。如下：
WHERE column1 = ''x'' OR column1 = ''y''
这种情况，由于语句是RANG查询，所以会走索引的。这个话题会在IN限定（predicate）的讨论中再次看到。
UNION查询
所有含有UNION的SELECT查询语句会被各自优化。因此，这个查询：
SELECT * FROM Table1 WHERE column1 = ''x''
UNION ALL
SELECT * FROM TABLE1 WHERE column2 = ''y''
如果column1和column2都有索引的，每个SELECT都会使用索引扫描，各自的结果集会被合并。注意：此查询可能产生相同的结果集，如果查询使用了顺序扫描OR的例子。
NOT（<>）关系
一个逻辑条件如下 ：
column1 <> 5
等价于：
column1 < 5 OR column1 > 5
然而，MySQL不会对这种条件进行转化语句。如果你觉得用RANG查询效果会更好，你必需自己手动做语句转化。
还有一个逻辑条件如下：
WHERE NOT (column1 != 5)
等价于：
WHERE column1 = 5
对这种情况，MySQL也不会做语句转化的。
我们期待能针对上述两个情况加入新的优化方法。
ORDER BY语句
通常，如果优化器发现行记录不管怎么样都是有序的，在ORDER BY语句中它也会跳过SORT过程。但是还是验证几个例外的情况。
例：
SELECT column1 FROM Table1 ORDER BY ''x'';
优化器会扔掉ORDER BY语句，这也是死代码删除一个例子。
例：
SELECT column1 FROM Table1 ORDER BY column1;
优化器会使用column1的索引，如果存在的话。
例：
SELECT column1 FROM Table1 ORDER BY column1+1;
优化器会使用column1的索引，如果存在的话。但是不要被弄混了，索引只用来查找记录值。另外：顺序扫描索引的成本比顺序扫描全表的成本是更便宜的（一般索引的大小会比数据值的大小小的），这也是为什么INDEX JOIN联接类型会比ALL类型更优化。见确定JOIN联接类型。
还有一种结果集的全部排序SORT，例：
SELECT * FROM Table1
WHERE column1 > ''x'' AND column2 > ''x''
ORDER BY column2;
如果column1和column2都有索引的，优化器会走在column1上的索引。在这个查询语句，对column2值的排序不会影响驱动的选择。
源
|
