共计 2291 个字符，预计需要花费 6 分钟才能阅读完成。
一、问题背景与实用场景
在《性能优化技巧：预关联》中，咱们测试了将数据表当时全副加载进内存并做好关联后的查问性能优化问题，但如果内存不够大，不能将维表和事实表全副装入，那怎么办呢？此时，能够将维表事后装入内存，建好索引，实现维表局部的预关联，省去一半 hash 计算。
咱们上面再来测试一下这种场景，这次用数据量最大、内存装不下的 lineitem 表做测试，在 SPL 局部预关联中，将其它 7 张表事后装进内存，而 lineitem 在查问时才实时读入。
二、SQL 测试
仍然用 Oracle 数据库作为 SQL 测试的代表，从 lineitem 表里查问每年整机订单的总收入。
1. 两表关联
查问的 SQL 语句如下：
select
l_year,
sum(volume) as revenue
from
(
select
extract(year from l_shipdate) as l_year,
(l_extendedprice * (1 – l_discount) ) as volume
from
lineitem,
part
where
p_partkey = l_partkey
and length(p_type)>2
) shipping
group by
l_year
order by
l_year;
2. 六表关联
查问的 SQL 语句如下：
select
l_year,
sum(volume) as revenue
from
(
select
extract(year from l_shipdate) as l_year,
(l_extendedprice * (1 – l_discount) ) as volume
from
supplier,
lineitem,
orders,
customer,
part,
nation n1,
nation n2
where
s_suppkey = l_suppkey
and p_partkey = l_partkey
and o_orderkey = l_orderkey
and c_custkey = o_custkey
and s_nationkey = n1.n_nationkey
and c_nationkey = n2.n_nationkey
and length(p_type) > 2
and n1.n_name is not null
and n2.n_name is not null
and s_suppkey > 0
) shipping
group by
l_year
order by
l_year;
3. 测试后果
这两个测试数据仍然是屡次运行后取最快的那次。
从测试后果能够看出，六表关联比两表关联慢了 2669/235=11.4 倍！性能降落十分多。
三、SPL 局部预关联测试
1. 局部预关联
实现预关联的 SPL 脚本如下：
脚本中前 6 行别离将 6 个维表读入内存，生成内表，并建好索引，再设成全局变量。后 4 行实现维表间连接。在 SPL 服务器启动时，就先运行此脚本，实现环境筹备。
2. 两表关联
编写 SPL 脚本如下：
长期装载须要用游标，而后在游标上进行关联，之后的写法和全内存差不多。
3. 六表关联
编写 SPL 脚本如下：
相似地，建设好游标及关联后的写法和全内存差不多，一样十分简洁易懂。
4. 运行后果
六表关联仅仅比两表关联慢 1.8 倍，减少的工夫次要用于事实表 lineitem 中 L_ORDERKEY 和 L_SUPPKEY 字段的关联以及减少的过滤条件计算量（援用这些关联表字段）的工夫。因为有了局部预关联，维表之间关联运算自身不再耗费工夫，而维表与 lineitem 表关联的工夫，也因为当时建好索引而进步了性能（能够缩小一半的 hash 计算）。
四、论断
测试后果汇总：
六表关联比两表关联，SQL 慢了 11.4 倍，阐明 SQL 解决 JOIN 耗费 CPU 很大，性能升高显著。而采纳局部预关联机制后的 SPL 只慢 1.8 倍，多 JOIN 几个表影响不大，性能不会显著降落。
在进行关联表较多的查问时，如果内存大到足以将除事实表之外的维表数据全副读入内存，应用局部预关联技术仍然能无效地晋升计算性能！而关系数据库用在关联表很多的时候会产生数据库引擎不会优化的问题，导致性能降落很重大。
