关于left join 底层算法的困惑

Question

有个SQL的问题咨询下：
关于PostgreSQL 或者 MySQL的left join 实现

假设：表结构

table_name ：user
uid    name
1      张三
2      李四
3      王五

table_name : age
uid    age
1      10
2      20
3      30
4      40

SQL如下：

示例1：
SELECT t1.user,t2.age
FROM user t1
LEFT JOIN age t2 ON t1.uid=t2.uid

示例2：
SELECT t1.user
       ,(SELECT age FROM age WHERE uid=t1.uid) as age
FROM user t1

结果：示例2的查询时间优于示例1，为什么........unbelievable

怀疑点：

示例1的SQL执行顺序是否是：
    第一种：
    1. 查询user全表
    2. 查询age全表
    3. 算法引擎将两种数据进行逐个匹配，获取结果

    第二种：
    1. 查询user全表
    2. 根据user查询出的数据为查询条件，查询age表
    3. 算法引擎将两种数据进行逐个匹配，获取结果

是哪一种？？

望解惑~

补充：

    上面表是假设的，实际表有些复杂，但是逻辑是这个样子….
    
    总结一下问题：
    
    SQL中可能基础数据（主表数据）就10条，但是关联表中的数据可能百万条（与这10条相关的就几十万条），
    是查询百万条数据匹配，还是查询几十万条匹配

Answer 1

left join 的执行过程：
1.FROM:对左右两张表执行笛卡尔积，产生第一张表vt1（临时表）。行数为n*m（n为左表的行数，m为右表的行数
2.ON:根据ON的条件逐行筛选vt1，将结果插入vt2中
3.JOIN:添加外部行，如果指定了LEFT JOIN，则先遍历一遍左表的每一行，其中不在vt2的行会被插入到vt2，该行的剩余字段将被填充为NULL，形成vt3；如果指定了RIGHT JOIN也是同理。但如果指定的是INNER JOIN，则不会添加外部行，上述插入过程被忽略，vt2=vt3（所以INNER JOIN的过滤条件放在ON或WHERE里 执行结果是没有区别的，下文会细说）
4.WHERE:对vt3进行条件过滤，满足条件的行被输出到vt4
5.SELECT:取出vt4的指定字段到vt5

从Left join 过程你会发现步骤要比2要复杂一些，可能会造成一些耗时

Answer 2

要看场景的好吧，数据量千条， hash join明细比全表扫描快