传统数据库，特别是交易（TP）数据库，用于分析型计算经常会出现性能问题。TP数据库的性能优化主要是提高事务处理和写操作（增删改）的效率，这和分析型计算的优化方向并不一致，也就很难让分析计算跑的快。
常见的解决办法是把历史数据从TP数据库搬到专业OLAP数据仓库中计算。不过，OLAP数据仓库太沉重，经常需要集群，硬件成本较高，还可能有昂贵的授权费用，更重要的是，整个技术架构也变得非常复杂。
这些历史数据大多数情况下是不再变化的，如果能存成文件会更简单。但是文件本身没有计算能力，无法直接实施条件过滤、分组汇总等运算，更谈不上复杂的分析任务了。
SPL可以让文件拥有计算能力，用它的轻量级列存文件存储不变的历史数据，较小的投入就能实现高速查询。
SPL引擎非常轻，部署后占用存储空间仅几百M，单机就可以运行，无须集群。SPL还能嵌入前端应用中，只需要几个jar包和配置文件，就可以在应用内提供强计算能力。实现数据外置提速的同时，也不会让系统架构变得很复杂：
轻量的SPL，计算能力却非常强大，在列式存储、数据压缩、多线程并行等方面都做了深度优化，能让条件过滤、分组汇总这些常规运算的性能大幅提升，完全不输于专业的MPP数据仓库，更是远远超过TP数据库。
SPL常规计算与MYSQL对比（单位：秒）
注：测试环境和方法参见 《如何用esProc将数据库表转储提速查询》
SPL代码也很简单，比如大订单表的过滤和分组汇总：
专业OLAP数据仓库利用列存压缩等技术能让常规运算中跑出较高性能，但对于某些更较复杂的计算场景中性能并不理想。这是因为SQL缺少必要的数据类型和相应的基础运算，对高性能算法支持不足，比如有序计算、分组子集等。而用SQL调优、集群分布式、UDF等工程上的优化方法不仅成本高，还常常没有什么效果。
SPL提供了更丰富的数据类型和基础运算，很容易写出低复杂度的代码，对于这些较复杂任务，可以用更小资源跑出超过OLAP数据仓库的性能，经常能做到单机顶集群。
比如以快著称的ClickHouse数据库，在同样环境下跑国际通行的TPC-H测试题，简单的Q1和SPL的性能基本相当，但是稍复杂一些的Q2、Q3、Q7就完全不如SPL了：
TPC-H（单位：秒）
再看实际案例，比如某个时空碰撞问题，总数据量约 250 亿行。SQL 看起来并不算很复杂：
WITH DT AS ( SELECT DISTINCT id, ROUND(tm/900)+1 as tn, loc FROM T WHERE tm<3*86400)
SELECT * FROM (
SELECT B.id id, COUNT( DISINCT B.tn ) cnt
FROM DT AS A JOIN DT AS B ON A.loc=B.loc AND A.tn=B.tn
WHERE A.id=a AND B.id<>a
GROUP BY id )
ORDER BY cnt DESC
LIMIT 20
传统数据库跑得太慢，用户转而求助于 ClickHouse，结果用了 5 节点的集群，也跑了 30 分钟多，达不到期望。同样数据量，SPL只用一个节点不到 6 分钟即可完成计算，超出了用户期望。考虑到硬件资源的差距，SPL相当于比 ClickHouse 快了 25 倍以上。
同时，SPL代码仍很简单：
