在实际生产中，关于 join 语句使用的问题，一般会集中在以下两类：
我们 DBA 不让使用 join，使用 join 有什么问题呢？
如果有两个大小不同的表做 join，应该用哪个表做驱动表呢？
第一个问题：能不能使用 join 语句？
如果可以使用 Index Nested-Loop Join 算法，也就是说可以用上被驱动表上的索引，其实是没问题的；
如果使用 Block Nested-Loop Join 算法，扫描行数就会过多。尤其是在大表上的 join 操作，这样可能要扫描被驱动表很多次，会占用大量的系统资源。所以这种 join 尽量不要用。
所以你在判断要不要使用 join 语句时，就是看 explain 结果里面，Extra 字段里面有没有出现“Block Nested Loop”字样。
第二个问题是：如果要使用 join，应该选择大表做驱动表还是选择小表做驱动表？
如果是 Index Nested-Loop Join 算法，应该选择小表做驱动表；
如果是 Block Nested-Loop Join 算法：
在 join_buffer_size 足够大的时候，是一样的；
在 join_buffer_size 不够大的时候（这种情况更常见），应该选择小表做驱动表。
所以，这个问题的结论就是，总是应该使用小表做驱动表。
案例：
1）优化前的sql语句以channels_news为第一个关联表，找到161590条记录；
2）优化后的sql语句以news表为第一关联表，找到255440条记录，比第一条sql语句查找多了9W多条。因此，优化前的sql语句的关联顺序是MySQL优化器的选择，可以让查询进行更小的嵌套循环和回溯操作。MySQL通过选择合适的关联顺序来让查询执行的成本尽可能低，重新定义关联的顺序是优化器很重要的一部分功能。不过有时候，优化器给出的并不是最优的关联顺序。这时可以使用STRAIGHT_JOIN关键字重写查询，让优化器按照你认为的最优关联顺序执行。
造成这次sql语句查询耗时5s的原因是，sql语句order by的字段不在mysql的优化器选在驱动表上，所以导致这次关联查询排序字段上的索引没有被使用。因此，通过使用STRAIGHT_JOIN来强制制定关联查询的表顺序，以达到优化的目的。但是，有时候我们人为地指定顺序不一定比mysql的优化引擎准确，所以在使用STRAIGHT_JOIN的时候三思而后行
