SQL作为目前最常用的数据处理语言，广泛应用于查询、跑批等场景。当数据量较大时，使用SQL（以及存储过程）经常会发生跑得很慢的情况，这就要去优化SQL。优化SQL有一些特定的套路，通常先要查看执行计划来定位SQL慢的原因，然后针对性改写来优化SQL，比如对于连续数值判断可以用between来替代in，select语句指明字段名称，用unionall替代union，把exists改写成join等。当然还有一些工程上的优化手段，如建立索引，使用临时表/汇总表等，优化的方法有很多，相信各位DBA都不会陌生。
但遗憾的是，仍然有相当多情况无论怎样优化都不可能跑得更快。这里做SQL性能优化真是让人干瞪眼介绍了一些，并做了相应的技术分析。由于其理论基础关系代数的局限，SQL缺乏离散性和有序集合等特性的支持使得SQL在表达某些高性能算法时异常困难，甚至完全写不出来，只能采用比较笨的低性能算法，眼睁睁地看着硬件资源被白白浪费。在写着简单跑得又快的数据库语言SPL中有对SQL理论基础缺陷的通俗解释。也就是说，SQL的慢是理论性的，这种问题仅仅由数据库在工程层面优化只能局部改善（确实有不少商业数据库能够自动识别某些SQL并转换成高性能算法），而不能根本地解决问题（情况复杂时数据库优化引擎都会“晕”掉，只能按SQL的书写逻辑执行成低性能算法）。理论性的缺陷当然也不能寄希望于更换数据库而得到解决，只要还是用SQL，即使采用分布式数据库、内存数据库也还是这种情况，在消耗更大成本的资源后当然也能有一定的性能提升，但和硬件本应能够达到的性能仍然有巨大的差距。
那还能怎么办？
那就不能再用SQL！也就不能再用关系数据库了。
那用什么？
SQL描述不了这些高性能算法，用Java，C++行吗？
没问题！从理论上讲，Java、C++什么算法都能实现，而且因为可以控制计算机底层的动作，这类代码通常可以跑出很好的速度（只要程序员能力不是太差）。
不过，不要高兴得太早，虽然都写得出来，但由于这些开发语言过于原生，本身没有提供什么面向数据处理的高性能计算类库，想实现这些算法就必须从头实现，而这恐怕要累死。以哈希关联为例，Java实现至少要写几百行代码，不仅要设计合适的哈希函数，还要解决可能出现的哈希冲突，这一套下来的工程量可不小；还有在Java中进行多线程编程也并非易事，但并行计算又是提升计算性能的有效手段。类似的，涉及结构化数据计算的算法还有很多，这些都自己来做的复杂度可想而知。如果一个计算的实现过于复杂，其开发代价已经远远超过性能优化本身，那也就没有优化的意义了。
Python也面临类似的问题，虽然在结构化数据计算类库方面要比Java丰富得多，但并没有提供必要的高性能算法库和存储方案，比如没有提供为大数据服务的游标类型及相关运算，也没提供有效的并行机制。想要实施那些高性能算法也只能自己开发，但Python作为解释执行语言，本身运行效率不高，在此基础上再开发的算法也往往达不到高性能要求。同样，Scala也缺乏足够的高性能计算类库，自己编写的算法同样复杂度相当高，对于不熟悉这些算法的程序员来讲，从头实现的代码的运行效率往往还不如努力优化后商用数据库SQL的速度。
那就只能忍受SQL的慢了吗？
还可以用SPL！
SPL和高性能
开源SPL（StructuredProcessLanguage），一个专门面向结构化数据处理的程序语言。使用SPL可以让原本SQL跑得慢的计算变快。
为什么SPL能跑得快？是拥有了什么改变硬件性能的黑科技吗？
那倒没有。软件改变不了硬件的计算性能，SPL也一样。简单来说，SPL快就是上面说的，要使用更高性能的算法。SPL中提供了大量基础的高性能算法类库，基于这些算法库实现的代码可以有效减少计算量，而我们做计算就是组合运用这些算法，每种计算都快一些，那整体上就会快很多，从而达到提升计算性能的目的。
SPL设计的这些高性能算法，像遍历复用、有序归并、外键预关联、标签位维度、并行计算等，都已经封装好。这其中有很多算法都是SPL独创的，在业内也是首次出现。
基于这些封装好的算法库，再写程序会就很方便，拿来直接用而不需要从头自己开发，不仅性能高，开发也快。从这个角度来看，跑得快和写着简单其实是一回事，就是能高效率地编写高性能算法。反观Java、C++、Python、Scala由于缺少这些算法库，想要实现高性能也就很难了。
这里有一些SPL中高性能算法的例子及与SQL的对比用例：性能优化技巧：遍历复用性能优化技巧：TopN性能优化技巧：预关联性能优化技巧：外键序号化性能优化技巧：附表性能优化技巧：单边分堆性能优化技巧：有序分组…
SPL采用和SQL不同的观念看待同一个计算任务，继而可以采用不同（更低）复杂度的计算方法。
在实战中，SPL目前已经做过不少性能优化案例，少则提速数倍，多则数十倍，极端情况还有提速上千倍的，提速一个数量级基本上是常态。
比如在优化某保险公司车险保单跑批的案例（开源SPL优化保险公司跑批优从2小时到17分钟）中，使用SPL将计算时间从2小时缩短到17分钟，同时代码量减少了2/3。这里使用了SPL特有的遍历复用技术，可以在对大数据的一次遍历过程中实现多种运算，有效地减少外存访问量。这个案例涉及对一个大表进行三次关联和汇总的运算，使用SQL要将大表遍历三次，而使用SPL只需要遍历一次，并在关联运算上也采用了不同的方法，因此获得了巨大的性能提升。
还有在开源SPL将银行手机账户查询的预先关联变成实时关联的案例中，使用SPL将原本只能预关联的手机账户查询变成实时关联，同时服务器数量从6台降为1台。这里充分利用了SPL的有序存储机制，一次性读取整个账户数据时可以有效减少硬盘时间（物理存储连续），再借助区分维表和事实表的外键实时关联技术使用单机就能完成实时关联查询，性能提升明显，硬件需求也降低了许多。
这里还整理了一些常见的业务场景，可以利用SPL的算法库来实现的高性能：
如何让JOIN跑得更快？
内存数据库如何发挥内存优势？
列存数据仓库怎样更高效
高并发帐户查询怎么做？
多标签用户画像分析跑得快的关键在哪里？
双维有序结构提速大数据量用户行为分析
关于SPL高性能的原因在快出数量级的性能是怎样炼成的里也进行了详细分析，并给出了更多实际优化案例供参考。
进一步讨论
说到这里你可能会想，那是不是学会SPL语法就能把计算跑得快了？
也没这么简单！
关于算法
使用SPL可以获得更高性能不是因为SPL语法，SPL语法虽然有些特色，但并不是跑得快的根本原因。最关键的是掌握和运用高性能算法。
实现性能优化有两步：第一步设计出低复杂的计算方案，第二步用足够低的成本实现它。其中更关键的是第一步，这需要由有一定经验和知识储备的程序员来做（即掌握和运用高性能算法），第二步才是用SPL来做。换句话说，SPL并不负责设计解决问题的方法，而只是负责让解法更容易实现出来。
SPL语法很简单，比Java容易得多，两小时就能基本上手，两三周就能比较熟练了。但算法却没那么简单，需要认真学习反复练习才能掌握。反过来，只要掌握了算法，用什么语法就是个相对次要的问题了（当然用SQL这种太粗线条的语言还是不行）。这就像给病人看病，找出病理原因后，能分析出什么成分的药能管用。无论直接购买成药（使用封装过的SPL），还是上山采药（使用Java/C++硬写），都可以治好病，无非就是麻烦程度和支付成本不同。
因为实际中很少使用，有不少应用程序员工作几年后都把大学时代学过的数据结构和算法课程内容忘了，而不理解这些基础算法知识时也就没办法设计出高性能算法方案。为此，SPL设置了专门的高性能专题，不仅涵盖高性能算法与优化技巧，还有性能优化课程与性能图书来授人以渔。
高性能计算专题