数据库运行很慢的原因分析

本篇内容介绍了“数据库运行很慢的原因分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

专业领域包括网站制作、成都做网站、商城网站建设、微信营销、系统平台开发， 与其他网站设计及系统开发公司不同，成都创新互联公司的整合解决方案结合了帮做网络品牌建设经验和互联网整合营销的理念，并将策略和执行紧密结合，为客户提供全网互联网整合方案。

当你发现数据库查询特别慢的时候，并且从硬件配置、SQL优化和索引等方面都找不出原因，那你可能需要从数据库的计算引擎本身的性能找下原因。

数据库的计算引擎性能有多重要？我们可以拿汽车做个简单类比。服务器硬件配置是基础设施，相当于汽车行驶的道路，高速公路和山村土路的行驶效果肯定是不一样的；SQL的查询优化相当于驾驶水平；而数据库计算引擎就相当于汽车发动机，既是数据库性能的源动力，也是各家厂商最核心的技术壁垒。

那么，我们就从数据库计算引擎的实现技术探究下如何提高数据库性能。下图是从客户端发出一条SQL语句到结果返回给客户端的简化流程。

如果把数据库内核看成一个组织，那么优化器就位于组织的最上层，作为组织的首脑发号施令；执行器位于组织的中间，严格执行优化器下发的计划，从存储空间中读取数据进行加工处理，最终返回给客户端。

优化器

如何形象的理解优化器？以查询“知乎点赞过万的回答”为例，用户通过SQL告诉数据库“给我找出点赞过万的回答”，优化器把用户的需求转换为“如何找到点赞过万的回答”的策略和方法，即查询计划。

同一种SQL会有成千上万种不同的执行计划，而好的执行计划和差的执行计划在运行性能上会有天壤之别。

如何从成千上万种查询计划中选出最优的？早期数据库的查询优化器通常采用启发式规则进行优化RBP（Rule Based Optimization），这种优化方式不够准确，往往难以获得最优的执行计划，而基于代价的优化CBO (Cost Based Optimization)则能够针对大多数场景高效筛选出性能最好的执行计划。

因此，我们见到的高性能数据库引擎往往使用基于代价的优化器。

执行器

执行器是数据库内核最重要的部件之一。提升执行器的性能，会很大程度上提升数据库性能，因此各大数据库厂商都纷纷投入很多精力到执行器技术的研发中。

提升执行器性能的手段主要有两种技术路线，一种是向量计算（vectorized execution），另外一种是代码生成（code generation）。目前主流的数据库厂商会使用其中一种执行器优化技术，例如Snowflake使用的是向量计算，Impala使用的是代码生成, Spark两种都有使用，OushuDB使用了向量计算外加SIMD优化技术。而一些传统的数据库还未实现其中任何一种性能技术。

聪明的你可能要问了，哪种技术路线更胜一筹？关于这个问题，不少研究和论文给出了答案：两种技术侧重点不同但都可以提升性能，不同的语句也会有不同程度的性能提升，向量计算更适合并行处理数据SIMD。所以，想要在并行计算的基础上进一步提升数据库引擎性能，就可以结合并行处理数据充分利用CPU硬件指令（比如SIMD）。

SIMD

SIMD(single instruction multi-data), 即单指令多数据流，以同步的方式在同一时间内执行同一条指令。相比单指令单数据流（SISD），单指令多数据流一次性获得所有操作数进而加快了运算，特别是数据密集型运算。

如上图所示，使用标量运算一次只能执行一对数据的乘法操作，而采用SIMD乘法指令则可以一次同时执行四对数据的乘法操作。作为向量体系结构的一种，SIMD使用一条向量指令开启一组数据操作，其中数据的加载、存储以及数据计算以流水线的形式进行。

通过在国际标准数据集TPCH上的测试，我们发现OushuDB 4.x的速度比最新版本的SparkSQL 3.x快大约一个数量级。

基于以上的分析，如果从提升数据库性能的角度，我们可以采用基于代价的优化+向量计算+ SIMD的技术路径，作为提升数据库性能的首选方法。

“数据库运行很慢的原因分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！