共计 4857 个字符，预计需要花费 13 分钟才能阅读完成。
| 导读 | SQL 作为目前最常用的数据处理语言，广泛应用于查询、跑批等场景。当数据量较大时，使用 SQL（以及存储过程）经常会发生跑得很慢的情况，这就要去优化 SQL。如果一个计算的实现过于复杂，其开发代价已经远远超过性能优化本身，那也就没有优化的意义了。 |
SQL 作为目前最常用的数据处理语言，广泛应用于查询、跑批等场景。当数据量较大时，使用 SQL（以及存储过程）经常会发生跑得很慢的情况，这就要去优化 SQL。优化 SQL 有一些特定的套路，通常先要查看执行计划来定位 SQL 慢的原因，然后针对性改写来优化 SQL，比如对于连续数值判断可以用 between 来替代 in，select 语句指明字段名称，用 union all 替代 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（Structured Process Language），一个专门面向结构化数据处理的程序语言。使用 SPL 可以让原本 SQL 跑得慢的计算变快。
为什么 SPL 能跑得快？是拥有了什么改变硬件性能的黑科技吗？
那倒没有。软件改变不了硬件的计算性能，SPL 也一样。简单来说，SPL 快就是上面说的，要使用更高性能的算法。SPL 中提供了大量基础的高性能算法类库，基于这些算法库实现的代码可以有效减少计算量，而我们做计算就是组合运用这些算法，每种计算都快一些，那整体上就会快很多，从而达到提升计算性能的目的。
SPL 设计的这些高性能算法，像遍历复用、有序归并、外键预关联、标签位维度、并行计算等，都已经封装好。这其中有很多算法都是 SPL 独创的，在业内也是首次出现。
基于这些封装好的算法库，再写程序会就很方便，拿来直接用而不需要从头自己开发，不仅性能高，开发也快。从这个角度来看，跑得快和写着简单其实是一回事，就是能高效率地编写高性能算法。反观 Java、C++、Python、Scala 由于缺少这些算法库，想要实现高性能也就很难了。
SPL 采用和 SQL 不同的观念看待同一个计算任务，继而可以采用不同（更低）复杂度的计算方法。
在实战中，SPL 目前已经做过不少性能优化案例，少则提速数倍，多则数十倍，极端情况还有提速上千倍的，提速一个数量级基本上是常态。
比如在优化某保险公司车险保单跑批的案例（开源 SPL 优化保险公司跑批优从 2 小时到 17 分钟）中，使用 SPL 将计算时间从 2 小时缩短到 17 分钟，同时代码量减少了 2/3。这里使用了 SPL 特有的遍历复用技术，可以在对大数据的一次遍历过程中实现多种运算，有效地减少外存访问量。这个案例涉及对一个大表进行三次关联和汇总的运算，使用 SQL 要将大表遍历三次，而使用 SPL 只需要遍历一次，并在关联运算上也采用了不同的方法，因此获得了巨大的性能提升。
还有在 开源 SPL 将银行手机账户查询的预先关联变成实时关联 的案例中，使用 SPL 将原本只能预关联的手机账户查询变成实时关联，同时服务器数量从 6 台降为 1 台。这里充分利用了 SPL 的有序存储机制，一次性读取整个账户数据时可以有效减少硬盘时间（物理存储连续），再借助区分维表和事实表的外键实时关联技术使用单机就能完成实时关联查询，性能提升明显，硬件需求也降低了许多。
说到这里你可能会想，那是不是学会 SPL 语法就能把计算跑得快了？
也没这么简单！
使用 SPL 可以获得更高性能不是因为 SPL 语法，SPL 语法虽然有些特色，但并不是跑得快的根本原因。最关键的是掌握和运用高性能算法。
实现性能优化有两步：第一步设计出低复杂的计算方案，第二步用足够低的成本实现它。其中更关键的是第一步，这需要由有一定经验和知识储备的程序员来做（即掌握和运用高性能算法），第二步才是用 SPL 来做。换句话说，SPL 并不负责设计解决问题的方法，而只是负责让解法更容易实现出来。
SPL 语法很简单，比 Java 容易得多，两小时就能基本上手，两三周就能比较熟练了。但算法却没那么简单，需要认真学习反复练习才能掌握。反过来，只要掌握了算法，用什么语法就是个相对次要的问题了（当然用 SQL 这种太粗线条的语言还是不行）。这就像给病人看病，找出病理原因后，能分析出什么成分的药能管用。无论直接购买成药（使用封装过的 SPL），还是上山采药（使用 Java/C++ 硬写），都可以治好病，无非就是麻烦程度和支付成本不同。
因为实际中很少使用，有不少应用程序员工作几年后都把大学时代学过的数据结构和算法课程内容忘了，而不理解这些基础算法知识时也就没办法设计出高性能算法方案。为此，SPL 设置了专门的高性能专题，不仅涵盖高性能算法与优化技巧，还有性能优化课程与性能图书来授人以渔。
高性能计算专题
http://c.raqsoft.com.cn/article/1647044897121
性能优化图书
http://c.raqsoft.com.cn/article/1613911172557
性能优化课程
http://www.raqsoft.com.cn/wx/course-performance-optimizing.html
和算法密切相关的，高性能计算还有一个关键点是数据存储，高性能计算离不开合理的数据存储方式。使用 SPL 实施高性能计算时也不能再基于数据库来做，需要将数据从数据库里搬出来重新组织。
为什么呢？
慢的数据计算任务可以分为计算密集型和数据密集型两大类。单纯的计算密集型任务涉及的数据量不大而只是计算量很大，计算量大并不是由于数据量大造成的，这样不用改变存储方式，只要实施了好的计算方法也能大幅提升性能，也就是说，可以继续在原有的存储方式（比如数据库）上使用 SPL 来优化性能。而数据密集型任务涉及的计算量也很大，但计算量大主要是由数据量大造成的，这时候如果不改变存储方式，数据读取时间很可能会很长，即使能把计算时间优化到 0，整体运算时间也不能得到有效的优化。
遗憾的是，我们面临的计算慢的场景绝大部分属于数据密集型计算。如果数据还存在数据库中，而数据库取数接口（如 JDBC）通常又非常慢，将数据读出就要消耗很长时间（IO 效率很低），经常远远超过后续 SPL 计算的时间，这也就不可能达到优化效果了。而且，SPL 中有相当多的算法也对存储组织有要求，比如单边分堆算法就要求有序的存储方式，而常规关系数据库无法满足这个前提，这些算法也无法实施了。
为了解决这个问题，SPL 提供了自有的存储机制，直接采用文件系统，将数据从数据库导出到特定格式的文件中，不仅可以获得更高的 IO 存取效率以及文件系统灵活的管理能力，还可以充分利用自有格式的列存、有序、压缩、并行分段等数据存储优势，从而高效地发挥高性能算法效力。
使用文件存储数据还可以有效减少数据入库的时间，进一步提升计算性能。有些计算场景不仅要从数据源读，还要将计算结果落地，存入数据库以方便后续计算使用。像 ETL 就是典型的读写并存的计算，还有某些大数据计算或复杂计算需要将中间结果暂存，后续计算还需要再使用的情况。我们知道，数据库写入是非常慢的动作，伴随写入的计算场景性能自然低下。这时就可以将原本需要入库的数据存储在文件中（虽然这是工程方面的优势，但仍可获得接近数量级的读写性能提升），再利用 SPL 的文件计算能力直接计算，从而实现高性能。
如果把数据都移到数据库外，那么是不是就无法完成实时数据计算了？毕竟数据总是在不断地产生。
没有问题。
对于全量 T+0 实时查询，SPL 提供了多源混合计算的能力以满足这类场景。冷数据量大且不再变化使用 SPL 的高性能文件存储，这样可以获得更高地计算性能；热数据量小仍然存放在原有数据源中，SPL 直接读取计算（支持多样性数据源），由于热数据量并不大，直接基于生产数据源查询也不会对其造成太大影响，访问时间也不会太长。冷热数据混合计算，就可以获得针对全量数据的 T+0 实时查询。我们只要定期将变冷的数据固化到 SPL 的高性能存储中，原数据源只需要保持少量近期新产生的热数据即可。整体架构如下：
从前面的分析可以知道，完成性能优化任务必须熟悉高性能算法和存储机制，但从上面的课程图书也可以看出来，这些内容并不少，都要融会贯通也不是很容易的事。特别是很多程序员都习惯了 SQL 的思维方式，很难跳出这个窠臼。面对一个性能优化任务，即使有了开源 SPL 这样的有利武器，也常常有点无从下手。打个比方，一个赶马车的高手想跑得更快时，会习惯于寻找缰绳和鞭子，而对于初次见到的汽车上的方向盘和油门却会感到一头雾水。
为此，SPL 团队也提供相应的咨询服务：你可以把遇到的性能问题拿过来与我们一起讨论和设计优化方案，必要的时候还可以进行 POC。
我们通常关心这样一些必要的问题信息：业务场景、面临痛点、当前计算的数据量和并发量以及响应时间，如果还能提供 SQL 脚本、表结构和测试数据就更好了。
相信我们，从不失手！
经历过一两个案子，程序员们就会熟悉 SPL 的思维方式（理解了方向盘和油门），以后再自己做性能优化就不是问题了。
天下武功，唯快不破，但只有掌握了快的本质和方法才能所向无敌。你说是不是？
