关于mysql执行计划 表示有问题！！

[VertigozZ]

sql 和 执行计划如下：



既然执行计划中的 id 都是 1 那么执行的顺序就是从上往下执行
那么问题就来了
1，为什么优先执行的是u(用户表)表？
2，就算第一个执行的是u表，第二个怎么紧接着就是执行了ttr表 ，这两个表我压根没有做直接的关联呀，
我做的关联明明是u和train表的？
3，更奇怪的是，第三个执行tr表 而且 rows 还是 1 我明明要筛选2个人的信息，为什么只执行了一次筛选？
4，整个执行计划的顺序匪夷所思，不禁让我怀疑 ，同一个id下 真的是从上而下执行的吗？

[致命的西瓜]

这只是sql解析的优先级，因为你的U表有where条件限制了两条数据，所以优先解析U，之后的表没有区别，都是简单关联，所以按顺序进行，rows 可以理解为扫描次数，为1表示一次扫描完成所有匹配，属于执行计划比较完美的，你的train和ttr都是全表（all）扫描，可以增加索引列进行优化。

[VertigozZ]

U 和 ttr 没有做关联 ，优先解析u表 后 再解析 ttr 他们怎么关联的 让我想不明白

[致命的西瓜]

引用 2 楼 VertigozZ 的回复:

U 和 ttr 没有做关联 ，优先解析u表 后 再解析 ttr 他们怎么关联的 让我想不明白

贴出来的解析结果是最终解析结果，没有关联的信息,毕竟把具体的解析过程贴出来也没什么必要

[致命的西瓜]

要想了解具体解析过程，可以先去了解mysql内核和事务处理

[VertigozZ]

引用 3 楼 wangjian0228 的回复:

引用 2 楼 VertigozZ 的回复:

U 和 ttr 没有做关联 ，优先解析u表 后 再解析 ttr 他们怎么关联的 让我想不明白

贴出来的解析结果是最终解析结果，没有关联的信息,毕竟把具体的解析过程贴出来也没什么必要

那如何查看具体的解析过程???

[LongRui888]

确实是id相同的，从上往下执行。

至于，这个执行计划，确实不好理解，不像sql server那样有图形化的执行计划，一目了然，mysql中的执行计划都是文本型的，哪个表和那个表，先关联，之后做什么都不是很清晰。

我觉得大致的过程是这样的，首先u过滤只有2条数据，而且是主键过滤，效率很高。

然后，ttr是全表扫描，每次与tr关联，是用的tr的索引，然后tr和tt关联，用的是tt的索引

[VertigozZ]

引用 6 楼 yupeigu 的回复:

确实是id相同的，从上往下执行。 至于，这个执行计划，确实不好理解，不像sql server那样有图形化的执行计划，一目了然，mysql中的执行计划都是文本型的，哪个表和那个表，先关联，之后做什么都不是很清晰。 我觉得大致的过程是这样的，首先u过滤只有2条数据，而且是主键过滤，效率很高。 然后，ttr是全表扫描，每次与tr关联，是用的tr的索引，然后tr和tt关联，用的是tt的索引

谢谢 版主 大概明白了 是不是虽然第一步解析了u，但是最后才用的u的两条数据？？

[致命的西瓜]

postgrel也有详细的解析过程和消耗时间等等，mysql只有explain，也可以用show profile查看sql开销

[LongRui888]

引用 7 楼 VertigozZ 的回复:

[quote=引用 6 楼 yupeigu 的回复:] 确实是id相同的，从上往下执行。 至于，这个执行计划，确实不好理解，不像sql server那样有图形化的执行计划，一目了然，mysql中的执行计划都是文本型的，哪个表和那个表，先关联，之后做什么都不是很清晰。 我觉得大致的过程是这样的，首先u过滤只有2条数据，而且是主键过滤，效率很高。 然后，ttr是全表扫描，每次与tr关联，是用的tr的索引，然后tr和tt关联，用的是tt的索引

谢谢 版主 大概明白了 是不是虽然第一步解析了u，但是最后才用的u的两条数据？？[/quote] 对的，应该是这样，不然没办法关联的，只是mysql优化器做了优化之后，关联顺序发生了变化