7个工程应用中数据库性能优化经验分享

Posted 2023-05-26 华为云开发者社区

摘要：此篇文章分别从sql执行过程、执行计划、索引数据结构、索引查询提速原理、聚焦索引、左前缀优化原则、自增主键索引这些角度谈一谈我们对数据库优化的理解。

本文分享自华为云社区《工程应用中数据库性能优化经验小结》，作者： 叶工 。

1、前言

现阶段交付的算法产品，绝大多数涉及到数据库的使用。它承载的内容包括：用户权限管理、数据集信息、异步推论的结果、个性化配置等等。

在OCR场景下，数据集体量通常较大（一个数据集几十万张图片），而数据库往往部署在客户共享数据库中（同时运行大量其他业务），甚至只能和算法镜像共享同一台服务器，因此在后台研发中尤其要关心数据库性能瓶颈。

此篇文章分别从 sql执行过程、执行计划、索引数据结构、索引查询提速原理、聚焦索引、左前缀优化原则、自增主键索引这些角度谈一谈我们对数据库优化的理解。

2、ORM场景下如何获得完整SQL语句

1. 线上环境可以通过连接池进行慢SQL拦截，并发出告警通知

2. 测试阶段，因为使用预编译语句或ORM框架，无法获取完整SQL时可以使用数据库日志方式获取

set global general_log=on;
show variables where Variable_name="general_log_file"；

2.1 SQL执行过程

分析器：分析SQL，需要使用哪些表，使用哪些条件（知道要干什么）

优化器： 对各种执行过程做性能评估，挑选代价最小的执行过程，代价只是优化器认为的，不一定正确 （怎么样做最快）

执行器：调用引擎接口，返回数据，引擎是插件式，类似编程时多态，在创建表时可以选择相应的存储 引擎

2.2 执行计划

SQL前加explain关键词可以得到SQL的执行计划，根据执行计划可以判断执行过程是否符合预期

explain
SELECT
 db_dataset.uuid AS db_dataset_uuid,
  db_dataset.NAME AS db_dataset_name,
 db_dataset.updated_at AS db_dataset_updated_at,
 db_dataset.created_at AS db_dataset_created_at,
 db_dataset.volume_dir AS db_dataset_volume_dir,
 db_dataset.max_data_count AS db_dataset_max_data_count,
 db_dataset.description AS db_dataset_description
FROM
 db_dataset
  LEFT OUTER JOIN db_manifest ON db_manifest.dataset_id = db_dataset.id AND
 db_manifest.dataset_version = \'annotation_v0\'
  LEFT OUTER JOIN db_ai_data ON db_manifest.id = db_ai_data.manifest_id AND
 db_ai_data.deleted = \'0\'
WHERE
 db_dataset.deleted = 0
GROUP BY
  db_dataset.id

执行计划反馈列的解释：

select_type详解：

type详解：

查询使用了何种类型，它在 SQL优化中是一个非常重要的指标，以下性能从好到坏依次是：
system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery >
index_subquery > range > index > ALL

system ：当表仅有一行记录时（系统表），数据量很少，往往不需要进行磁盘 IO，速度非常 快。

const ：表示查询时命中 primary key 主键或者 unique 唯一索引，或者被连接的部分是一个常量 （const）值。这类扫描效率极高，返回数据量少，速度非常快。

eq_ref ：查询时命中主键 primary key 或者 unique key 索引， type 就是 eq_ref。

ref ：区别于 eq_ref，ref 表示使用非唯一性索引，会找到很多个符合条件的行。

ref_or_null ：这种连接类型类似于 ref，区别在于 MySQL 会额外搜索包含 NULL 值的行。

index_merge ：使用了索引合并优化方法，一个查询使用了两个以上的索引。

EXPLAIN SELECT * FROM user_robot_relate WHERE id > 1 AND user_id = 2;

unique_subquery ：替换下面的 IN 子查询，子查询返回不重复的集合。

value IN (SELECT primary_key FROM single_table WHERE some_expr)

index_subquery ：区别于 unique_subquery，用于非唯一索引，可以返回重复值。

value IN (SELECT key_column FROM single_table WHERE some_expr)

range ：使用索引选择行，仅检索给定范围内的行。简单点说就是针对一个有索引的字段，给定 范围检索数据。在 where 语句中使用 bettween...and、<、>、<=、in 等条件查询 type 都是 range。 从结果中看到只有对设置了索引的字段，做范围检索 type 才是 range。

EXPLAIN SELECT * FROM user_robot_relate WHERE id BETWEEN 2 AND 3;

index ：Index 与 ALL 其实都是读全表，区别在于 index 是遍历索引树读取，而 ALL 是从硬盘中 读取。

ALL ：将遍历全表以找到匹配的行，性能最差。

Extra ：不适合在其他列中显示的信息，Explain 中的很多额外的信息会在 Extra 字段显示。

Using index：我们在相应的 select 操作中使用了覆盖索引，通俗一点讲就是查询的列被索引覆盖，使 用到覆盖索引查询速度会非常快，SQL 优化中理想的状态。

Using where：查询时未找到可用的索引，进而通过 where 条件过滤获取所需数据，但要注意的是并不 是所有带 where 语句的查询都会显示 Using where。

Using temporary：表示查询后结果需要使用临时表来存储，一般在排序或者分组查询时用到。

Using filesort：表示无法利用索引完成的排序操作，也就是 ORDER BY 的字段没有索引，通常这样的 SQL 都是需要优化的。

Using join buffer：在我们联表查询的时候，如果表的连接条件没有用到索引，需要有一个连接缓冲区 来存储中间结果。

2.3 索引

索引时帮助MySQL高效获取数据的排好序的数据结构

索引数据结构：

二叉树

红黑树

HashTable

B-Tree

一般不用二叉树的原因：有序数据将退化成链表，深度不可控，如下图所示

通常也不能用红黑树的原因：虽然压缩了深度，但深度还是不可控，海量数据查找复杂度极高

Hash表：仅支持IN查新，不支持RANGE查询。使用hash算法将内容进行hash处理 hash(aaaa) = 2 hash(bbbb) = 2 hash(cccc) = 4

B+ 树：主流的索引结构

查找过程：

1. 读取根节点所有元素，因为是有序的，可以利用二分查找，高效查找到指定区间

2. 根据指定区间文件地址找到二级节点，读取所有元素。

3. 找到叶子节点中指定元素位置。

2.4 索引查询提速原理

以B+树索引为例，

如果要查找数据项目29

1、首先进入1号块，1号块数据加载如内存，发生一次I/O

2、在内存中进行二分查找，发现29在17和35之前，于是锁定P2指针，将3号块数据加载到内存，又发生一次I/O

3、同理在3号块中走P2指针锁定8号数据块，将8号数据块加载到内存，最后发生一次I/O

4、遍历8号块的数据就能找到29号数据

如果没有索引，最坏的情况是整个表格的数据块都需要加载到内存，然后遍历出结果，将产生大量的I/O开销和对整表数据的遍历。

2.5 聚焦索引

聚焦索引尤其适合需要进行RANGE查找的列，这是因为他的叶子节点存放的是有序的数据行。在查询过程中可以根据WHERE的条件定位到两端叶子节点，然后将他们之间的整个链表结构取出。

2.6 左前缀优化原则

工程应用中经常有一些核心表需要按照多种形式查询，如果为每一种查询方式都建一个索引会影响表插入和更新的性能。

考虑到联合索引在创建时每个子列都是排好序的，比如数据表A上有一个联合缩影（a, b, c) , 那么查询where a = xxx ； where a = xxx and b = xxx都将命中缩影，因此可以利用这种特性按照业务需求设置少量联合索引覆盖多种查询需求。

假设有表A, 有如下3种高频查询

select xx from A where a = xxx；
select xx from A where b = xxx；
select xx from A where a = xxx and b = xxx；

最简单的办法是 分别给a b (a, b) 建索引，但这就过于啰嗦。按照左前缀原则，最合理的索引建法应该是 b 和 (a， b)。

2.7 自增主键索引

1、InnoDB所有数据都是基于B+Tree存储的，如果没有主键mysql会在所有列中选择可能唯一的列用作索 引id，如果查找不到会默认增加rowid列。

2、索引查找过程中会有大量数据比对的场景，如果使用uuid会逐位比对，效率会非常低，占用空间也会非 常大，占用过多ssd空间，存储费用增大。

3、b+tree是有序树，自增索引数据可以一直向后插入性能高，如果使用非自增索引，可能导致插入过程中 带来树分裂及平衡问题，带来额外的性能损失。

3、常规数据库优化顺序

1、检查SQL，查看执行计划，是否命中索引？是否存在大量大表关联？查询的每个字段都是必须的？...

2、加索引

3、分区

4、分表

5、改表结构，减少查询种的关联，增加冗余字段

6、加服务器，弹性主机加U加内存换SSD...

 

点击关注，第一时间了解华为云新鲜技术~

Java Agent场景性能测试分析优化经验分享

摘要：本文将以Sermant的SpringBoot 注册插件的性能测试及优化过程为例，分享在Java Agent场景如何进行更好的性能测试优化及在Java Agent下需要着重注意的性能陷阱。

作者：栾文飞 高级软件工程师

一、背景介绍

Sermant是一个主打服务治理领域的Java Agent框架，在服务治理中难免会有针对业务流量进行解析和处理的过程，此类服务治理能力将会对微服务的服务能力产生一定的性能影响，作为一个基于Java Agent技术做服务治理的框架，我们需要在保证服务治理能力生效的同时，极小的影响微服务原有的服务性能。

虽然基于Java Agent的服务治理和基于SDK的服务治理在其原理上有所不同，但也避免不了微服务治理过程中产生对微服务原有性能的影响，基于Java Agent服务治理方式的相较于SDK的服务治理方式免去了侵入式的代码开发，是一种运行时技术，所以还需要考虑更多方面性能优化问题，例如在启动时间，运行时增强性能开销等，本文将以Sermant的SpringBoot 注册插件的性能测试及优化过程为例，分享在Java Agent场景如何进行更好的性能测试优化及在Java Agent下需要着重注意的性能陷阱。

SpringBoot 注册插件为SpringBoot应用提供服务注册发现能力，可用于在不修改原有代码的前提下快速从ESB架构演进为微服务架构，在该插件中包含针对域名的替换能力，服务注册发现能力，请求的超时重试等，为架构的成功演进，原有架构中基于域名的请求调用，将会被基于注册信息的请求调用（通过该插件的服务注册发现能力，获取服务提供者注册的信息）所取代，如下图所示：

在域名处理的过程是必然会参与到调用过程中的，这是服务治理能力对业务性能影响的典型场景。

二、测试方案

众所周知，Java Agent程序和被增强应用运行时同进程，Java Agent程序最重要的是不能对被挂载的应用产生异常影响，导致应用不可用，所以Sermant在运行时的处理性能及稳定性等做多方面的测试考量。在针对微服务进行测试的过程中，我们往往只需要关注该微服务的性能即可，通过压力测试来检验微服务的服务提供能力，由于服务治理能力并不直接提供服务，我们更多地需要关注在开启服务治理能力时，对微服务本身服务提供能力的影响，所以我们在测试方案中需要进行对比测试来评估服务治理能力的好坏。

本对照测试中，我们通过压力测试让系统达到极限场景（consumer端的CPU已经到达瓶颈），来分析携带Sermant并启用服务治理能力时，对应用原有服务提供能力的影响，此处采用两种部署方案

• 不携带Sermant，基于网关的场景，是架构改造前的运行模式
• 携带Sermant的场景，是迁移后的微服务架构运行模式

注：在这种对比测试中，基于Java Agent的服务治理只需要对携带Java Agent程序和不携带Java Agent程序的场景进行对照测试即可，无需两套代码进行对照测试。

由于Java Agent程序和被增强应用处于统一进程，资源共享，基于上述两种部署方案进行测试，以不携带Java Agent程序作为测试分析的对照组，就可以很清晰的看出引入Java Agent程序后产生的影响，并可根据对照结果进行优化，应用于Sermant上，就可以很容易的分析出Sermant的服务治理能力对微服务本身服务提供能力带来的影响。

三、性能分析

由于需要针对应用发起的请求通过字节码增量的方式做域名的替换，SpringBoot 注册插件通过对HttpClient、Openfeign、Okhttp等http客户端进行了字节码增强，我们根据上一章节中的测试方案对该插件提供的服务治理能力进行了测试，下面我们以HttpClien为例通过CPU火焰图来讲述如何在Java Agent场景下分析性能瓶颈：

在性能调优过程中，我们可通过CPU火焰图来分析性能瓶颈，火焰图可以称之为性能问题分析的"X光"，可以很一针见血的看出在程序运行中哪些代码片段产生了异常的CPU占用。可以参考《使用火焰图(FlameGraph)分析程序性能》进行学习，当然，采集CPU火焰图的方式很多，我们只需要学会如何看懂火焰图即可。

分析步骤

1. 找到字节码增强逻辑的CPU占用

在分析过程中，首先需要找到字节码增强时选中的被增强方法（本文场景增强方法为InternalHttpClient::doExecute），字节码增强需要被增强程序的原有方法调用触发，所以也可以很清晰的在CPU火焰图中可以看到，Sermant实现的逻辑调用栈在被增强方法之上，在字节码增强逻辑执行结束后，被增强方法还会继续执行。

所以除被增强方法执行的调用栈及CPU时间片占用外，皆为字节码增强所引入逻辑，在性能优化中需着重关注。

2. 分析异常占用

根据CPU火焰图原理，找出字节码增强部分，找出异常占用CPU时间片的调用栈，并进行程序的优化，如下图所示红框选择部分，皆为字节码增强中引入的逻辑，占用了非常多的CPU时间片，由于字节码增强程序和被增强程序，这种异常的占用，将会严重影响原程序的性能，在针对Java Agent场景的优化中可着重优化

通过上述步骤，我们可以一目了然的看到我们通过Java Agent程序引入的CPU额外占用，具体占用原因本文就不一一分析。

四、性能陷阱

基于上述两个章节的测试和分析方法，在本文的最后，列举出在Java Agent开发过程中经常会遇到的性能陷阱，这里也给出解决方式，可以在开发中注意：

减少反射使用

在字节码增强开发过程中，很多情况下，如果类加载器不同，针对被增强应用的类和方法往往需要通过反射去获取并使用，在我们的性能分析中，反射是一个CPU占用的巨大陷阱，在有些被BootstrapClassLoader加载的类增强时，甚至反射占用了一个方法调用30%以上的CPU事件片。

下图选中方法中，反射占用该方法调用中的大部分CPU时间片:

但是由于类加载器的限制，有些反射是必须要使用的，我们也可以通过一定的手段进行优化，比如缓存通过反射获取的类和方法，在字节码增强中，多次触发增强逻辑时减少反射占用CPU时间片非常有效。

Method method = METHOD_CACHE.get(methodKey);  
if (method != null)   
 return Optional.of(method);  
  
method = clazz.getDeclaredMethod(methodName, paramsType);  
METHOD_CACHE.put(methodKey, method);  

通过上述步骤优化后，通过火焰图来看，效果是非常显著的：

注意字节码增强插桩选择

在做字节码增强时的增强点选择很重要，字节码增强添加Transformer后运行时分为两种情况：

• transform：针对尚未被类加载器加载的类，如果添加Transformer，在类被加载时就会触发字节码的转换。
• retransform：针对已经被类加载器加载的类，如果添加了Transformer，则需要被重新加载后再进行字节码的转换。

Java中被BootstrapClassLoader加载的类，如果想要进行字节码增强，就需要使用第二种字节码转换的方式，可想而知，如果重新加载类再进行转换必然没有在类第一次加载时就进行转换的效率高。

除上述原因之外，在增强启动类加载器加载的类时，由于双亲委派机制的限制（只能向上委托，不能向下委托），往往都是需要大量使用反射（用于调用其他类加载器加载的类）来实现增强逻辑。

上文中也讲到，不加节制的使用反射将会通过Java Agent程序严重影响被增强应用的性能，所以在开发Java Agent时，需要谨慎选择增强的类，非必要不增强被启动类加载器加载的类。

上述两点是在Java Agent开发过程中最容易发生的向被增强应用引入的性能陷阱，除此之外，Java Agent也是由Java所开发，在开发过程中也需要注意不要引入常见的性能陷阱。

结束语

Sermant作为专注于服务治理领域的字节码增强框架，致力于提供高性能、可扩展、易接入的服务治理体验，并会在每个版本中做好性能、功能、体验的看护，广泛欢迎大家的加入。

Sermant官网：Sermant

GitHub仓库地址：GitHub - huaweicloud/Sermant: Sermant, a proxyless service mesh solution based on Javaagent.

点击关注，第一时间了解华为云新鲜技术~