目前来看 inner join 在正常情况（有索引、执行计划缓存）是正常的，更高效的
结论
由于有些数据丢失了， 这里就补一些文字性的描述内容
如果两个表都能用上索引， 那么两个性能一样， 此外应注意 left join 和 inner join 写的 sql 语义是否一样的， 避免踩到了 left join 的坑里面去了。
假如索引用不上的话， 一般inner join的性能优化是优于left join的， 很多数据库对于left join的优化实在不咋滴。
RDS 类数据库
如果都有左右表都能用索引关联上， 那此处没有什么好赘述的， 这里主要聊那些索引没办法两表串联的场景。
对于 RDS 当索引无法用于快速查询时， 有自己的优化方案是：
- 好处是当满足左表的记录少时， 可以将这个 join 从 m*n 的指数级变成只是左表的 m 数量级的查询
- 坏处就是反过来，如果左表记录特别多， 就会起到反作用了。
常见数据库
将左右表满足的数据查出，如果不能一次查询的， 还会变成 batch join， 分批查询放在内存 join， 如果还放不下的话，会转为磁盘进行操作。 相比于上面的场景，当数据量少时有时可能优于上面方案， 数据量多时就和上面的坏处有的比较了