SQL及存储过程跑得太慢怎么办？
发布时间：2022-09-11 10:36:23 所属栏目：动态 来源：互联网
导读：SQL 作为目前最常用的数据处理语言，广泛应用于查询、跑批等场景。当数据量较大时，使用 SQL（以及存储过程）经常会发生跑得很慢的情况，这就要去优化 SQL。优化 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 和高性能 开源 SPL（Structured Process Language），一个专门面向结构化数据处理的程序语言。使用 SPL 可以让原本 SQL 跑得慢的计算变快。 为什么 SPL 能跑得快？是拥有了什么改变硬件性能的黑科技吗？ 那倒没有。软件改变不了硬件的计算性能，SPL 也一样。简单来说，SPL 快就是上面说的，要使用更高性能的算法。SPL 中提供了大量基础的高性能算法类库，基于这些算法库实现的代码可以有效减少计算量，而我们做计算就是组合运用这些算法，每种计算都快一些，那整体上就会快很多，从而达到提升计算性能的目的。 SPL 设计的这些高性能算法，像遍历复用、有序归并、外键预关联、标签位维度、并行计算等，都已经封装好。这其中有很多算法都是 SPL 独创的，在业内也是首次出现。 （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
