在MySQL中使用STRAIGHT_JOIN的教程

推荐整理分享在MySQL中使用STRAIGHT_JOIN的教程，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:,内容如对您有帮助，希望把文章链接给更多的朋友！

问题

通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL，如下：

说明：因为post和tag是多对多的关系，所以存在一个关联表post_tag。

试着用EXPLAIN查询一下SQL执行计划(篇幅所限，结果有删减)：

下面给出优化后的SQL，唯一的变化就是把连接方式改成了「STRAIGHT_JOIN」：

试着用EXPLAIN查询一下SQL执行计划(篇幅所限，结果有删减)：

对比优化前后两次EXPLAIN的结果来看，优化后的SQL虽然「rows」更大了，但是没有了「Using filesort」，综合来看，性能依然得到了提升。解释

对第一条SQL而言，为什么MySQL优化器选择了一个耗时的执行方案？对第二条SQL而言，为什么把连接方式改成STRAIGHT_JOIN之后就提升了性能？

这一切还得从MySQL对多表连接的处理方式说起，首先要确定以谁为驱动表，也就是说以哪个表为基准，在处理此类问题时，MySQL优化器采用了简单粗暴的解决方法：哪个表的结果集小，就以哪个表为驱动表，通常这都是最佳选择。

说明：在EXPLAIN结果中，第一行出现的表就是驱动表。

继续post连接post_tag的例子，MySQL优化器有如下两个选择，分别是：

显而易见，post_tag过滤的结果集更小，所以MySQL优化器选择它作为驱动表，可悲催的是我们还需要以post表中的created字段来排序，也就是说排序字段不在驱动表里，于是乎不可避免的出现了「Using filesort」，从而导致慢查询。

知道了来龙去脉，优化起来就容易了。头等大事是务必保证排序字段在驱动表中，所以必须以post是驱动表，于是乎「STRAIGHT_JOIN」就成了答案，它强制了连接顺序。

…

不过我总觉得「STRAIGHT_JOIN」这种非标准的语法属于奇技淫巧的范畴，能不用尽量不用，毕竟多数情况下，MySQL优化器都能做出正确的选择。

探究MySQL优化器对索引和JOIN顺序的选择 本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序。表结构和数据准备参考本文最后部分"测试环境"。这里主要介绍MySQL优化器的主要执行流程

使用Python的Django框架中的压缩组件Django Compressor 为了加快网站的加载速度，我们通常要多js和css进行压缩处理。这些js和css的压缩工作如果都手动处理，费时费力。DjangoCompressor可以实现js/css的自动压缩

查找MySQL线程中死锁的ID的方法 如果遇到死锁了，怎么解决呢？找到原始的锁ID，然后KILL掉一直持有的那个线程就可以了，但是众多线程，可怎么找到引起死锁的线程ID呢？MySQL发展到