一、 问题背景与实用场景
在《性能优化技巧：预关联》中，咱们测试了将数据表当时全副加载进内存并做好关联后的查问性能优化问题，但如果内存不够大，不能将维表和事实表全副装入，那怎么办呢？此时，能够将维表事后装入内存，建好索引，实现维表局部的预关联，省去一半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几个表影响不大，性能不会显著降落。
在进行关联表较多的查问时，如果内存大到足以将除事实表之外的维表数据全副读入内存，应用局部预关联技术仍然能无效地晋升计算性能！而关系数据库用在关联表很多的时候会产生数据库引擎不会优化的问题，导致性能降落很重大。