mysql left join 慢如何优化

1、今天遇到一个left join优化的问题，搞了一下午，中间查了不少资料，对MySQL的查询计划还有查询优化有了更进一步的了解，做一个简单的记录：select c.* from hotel_info_original cleft join hotel_info_collection hon c.hotel_type=h.hotel_type and c.hotel_id =h.hotel_idwhere h.hotel_id is null这个sql是用来查询出c表中有h表中无的记录，所以想到了用left join的特性（返回左边全部记录，右表不满足匹配条件的记录对应行返回null）来满足需求，不料这个查询非常慢。先来看查询计划：

3、很明显，MySQL选择了小表作为驱动表，再配合(hotel_id,hotel_type)上的索引瞬间降低了好多个数量级。。。。。薷蒴塾寒另外，我今天还明白了一个关于left join 的通用法则，即：如果where条件中含有右表的非空条件（除开is null），则left join语句等同于join语句，可直接改写成join语句。后记：随着查看MySQL reference manual对这个问题进行了更进一步的了解。MySQL在执行join时会把join分为system/const/eq_ref/ref/range/index/ALl等好几类，连接的效率从前往后依次递减，对于我的第一个sql，连接类型是index，所以几乎是全表扫描的效果。但是我很奇怪我在(hotel_id,hotel_type)两列上声明了unique key，根据官方文档连接类型应该是eq_ref才对，这个问题一直困扰了我两天，在google和stackoverflow上都没有找到能够解释这个问题的文章，莫非我这个问题无解了？抱着解决这个问题的决心今天又翻看了一遍MySQL官方文档关于优化查询的部分，看到了这样一句：这里的一个问题是MySQL能更高效地在声明具有相同类型和尺寸的列上使用索引。我感觉我找到了问题所在，于是我将original和 collection表的(hotel_type,hotel_id)的encoding和collation（决定字符比较的规则）全部改成统一的utf8_general_ci，然后再次运行第一条sql的查询计划，得到如下结果：连接类型已经由index优化到了ref，如果将hotel_type申明为not null可以优化到eq_ref，不过这里影响不大了，优化后这条sql能在0.01ms内运行完。

4、那么如何优化left join：1、条件中尽量能够过滤一些行将驱动表变得小一点，用小表去驱动大表2、右表的条件列一定要加上索引（主键、唯一索引、前缀索引等），最好能够使type达到range及以上（ref,eq_ref,const,system）3、无视以上两点，一般不要用left join~~！