oracle 中的or 到底走不走索引,inner join ,left join ,merge join

看具体情况，有的情况下走，有的情况不走。

merge join

-- 有表t1plcbase 和t1isd ，plcno都是这两个表的索引
-- 你觉得下面的or走索引么？

select* from t1plcbase x,t1isd y where x.plcno=y.plcno and  x.plcno = '2021120106294500019728' or x.plcno = '2021120106294500019728' ;

--看执行计划，里面cost 284593 。cost可以理解为成本，值越大成本越高。
CBO（cost based Optimizer）评估每种不同的执行路径，执行消耗成本最低的获胜。
这里的cost可以理解为评估后的结果。
oracle 中select * from a,b 有人说a,b是inner join ，是不对的，
这种查询方式是生成笛卡尔积——它不使用任何匹配或者选取条件，
而是直接将一个数据源中的每个行与另一个数据源的每个行一一匹配

Merge Join 是先将关联表的关联列各自做排序，然后从各自的排序表中抽取数据，到另一个排序表中做匹配。

因为merge join需要做更多的排序，所以消耗的资源更多。 通常来讲，能够使用merge join的地方，hash join都可以发挥更好的性能,即散列连接的效果都比排序合并连接要好。然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接。

可以使用USE_MERGE(table_name1 table_name2)来强制使用排序合并连接
Cartesian 笛卡尔积

select* from t1plcbase x,t1isd y where x.plcno=y.plcno  如果单执行这句，是hash join

select* from t1plcbase x,t1isd y where x.plcno=y.plcno and  (x.plcno = '2021120106294500019728' or x.plcno = '2021120106294500019728' ) ;
-- 这个里面的or 是走了索引的，

left join

select* from t1plcbase x left join t1isd y on x.plcno=y.plcno where  x.plcno = '2021120106294500019728' or x.plcno = '2021120106294500019728' ;
//包含左边表的全部行（不管右边的表中是否存在与它们匹配的行）以及右边表中全部匹配的行
// 这也是走索引的

inner join

select* from t1plcbase x inner join t1isd y on x.plcno=y.plcno where  x.plcno = '2021120106294500019728' or x.plcno = '2021120106294500019728' ;	
-- 这也是走索引的

nested loop 嵌套循环连接

Nested loops 工作方式是循环从一张表中读取数据(驱动表outer table)，然后访问另一张表（被查找表 inner table,通常有索引）。驱动表中的每一行与inner表中的相应记录JOIN。类似一个嵌套的循环。

对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择。在嵌套循环中，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大（大于1 万不适合），要把返回子集较小表的作为外表（CBO 默认外表是驱动表），而且在内表的连接字段上一定要有索引。当然也可以用ORDERED 提示来改变CBO默认的驱动表。

使用USE_NL(table_name1 table_name2)可是强制CBO 执行嵌套循环连接。

适用情况：

适用于驱动表的记录集比较小（<10000）而且inner表需要有有效的访问方法（Index），并且索引选择性较好的时候.

JOIN的顺序很重要，驱动表的记录集一定要小，返回结果集的响应时间是最快的。

参考：https://www.cnblogs.com/xqzt/p/4469673.html