MySQL性能优化浅析及线上案例-低调大师

MySQL性能优化浅析及线上案例

2023-01-18 397

作者：京东健康孟飞

1、数据库性能优化的意义

业务发展初期，数据库中量一般都不高，也不太容易出一些性能问题或者出的问题也不大，但是当数据库的量级达到一定规模之后，如果缺失有效的预警、监控、处理等手段则会对用户的使用体验造成影响，严重的则会直接导致订单、金额直接受损，因而就需要时刻关注数据库的性能问题。

2、性能优化的几个常见措施

数据库性能优化的常见手段有很多，比如添加索引、分库分表、优化连接池等，具体如下：

3、 MySQL底层架构

首先了解一下数据的底层架构，也有助于我们做更好优化。

一次查询请求的执行过程

我们重点关注第二部分和第三部分，第二部分其实就是Server层，这层主要就是负责查询优化，制定出一些执行计划，然后调用存储引擎给我们提供的各种底层基础API，最终将数据返回给客户端。

4、MySQL索引构建过程

目前比较常用的是InnoDB存储引擎，本文讨论也是基于InnoDB引擎。我们一直说的加索引，那到底什么是索引、索引又是如何形成的呢、索引又如何应用呢？这个话题其实很大也很小，说大是因为他底层确实很复杂，说小是因为在大部分场景下程序员只需要添加索引就好，不太需要了解太底层原理，但是如果了解不透彻就会引发线上问题，因而本文平衡了大家的理解成本和知识深度，有一定底层原理介绍，但是又不会太过深入导致难以理解。

首先来做个实验：

创建一个表，目前是只有一个主键索引

CREATE TABLE `t1`(

a int NOT NULL,

b int DEFAULT NULL,

c int DEFAULT NULL,

d int DEFAULT NULL,

e varchar(20) DEFAULT NULL,

PRIMARYKEY(a)

)ENGINE=InnoDB

插入一些数据：

insert into test.t1 values(4,3,1,1,'d');

insert into test.t1 values(1,1,1,1,'a');

insert into test.t1 values(8,8,8,8,'h');

insert into test.t1 values(2,2,2,2,'b');

insert into test.t1 values(5,2,3,5,'e');

insert into test.t1 values(3,3,2,2,'c');

insert into test.t1 values(7,4,5,5,'g');

insert into test.t1 values(6,6,4,4,'f');

MYSQL从磁盘读取数据到内存是按照一页读取的，一页默认是16K，而一页的格式大概如下。

每一页都包括了这么几个内容，首先是页头、其次是页目录、还有用户数据区域。

1）刚才插入的几条数据就是放到这个用户数据区域的，这个是按照主键依次递增的单向链表。

2）页目录这个是用来指向具体的用户数据区域，因为当用户数据区域的数据变多的时候也就会形成分组，而页目录就会指向不同的分组，利用二分查找可以快速的定位数据。

当数据量变多的时候，那么这一页就装不下这么多数据，就要分裂页，而每页之间都会双向链接，最终形成一个双向链表。

页内的单向链表是为了查找快捷，而页间的双向链表是为了在做范围查询的时候提效，下图为示意图，其中其二页和第三页是复制的第一页，并不真实。

而如果数据还继续累加，光这几个页也不够了，那就逐步的形成了一棵树，也就是说索引B-Tree是随着数据的积累逐步构建出来的。

最下边的一层叫做叶子节点，上边的叫做内节点，而叶子节点中存储的是全量数据，这样的树就是聚簇索引。一直有同学的理解是说索引是单独一份而数据是一份，其实MySQL中有一个原则就是数据即索引、索引即数据，真实的数据本身就是存储在聚簇索引中的，所谓的回表就是回的聚簇索引。

但是我们也不一定每次都按照主键来执行SQL语句，大部分情况下都是按照一些业务字段来，那就会形成别的索引树，例如，如果按照b,c,d来创建的索引就会长这样。

推荐1个网站，可以可视化的查看一些算法原型：

https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

B+树

https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html

而在MySQL官网上介绍的索引的叶子节点是双向链表。

关于索引结构的小结：

对于B-Tree而言，叶子节点是没有链接的，而B+Tree索引是单向链表，但是MySQL在B+Tree的基础之上加以改进，形成了双向链表，双向的好处是在处理> <，between and等'范围查询'语法时可以得心应手。

5、MySQL索引的一些使用规范

1、只为用于搜索、排序或分组的列创建索引。

重点关注where语句后边的情况

2、当列中不重复值的个数在总记录条数中的占比很大时，才为列建立索引。

例如手机号、用户ID、班级等，但是比如一张全校学生表，每条记录是一名学生，where语句是查询所有’某学校‘的学生，那么其实也不会提高性能。

3、索引列的类型尽量小。

无论是主键还是索引列都尽量选择小的，如果很大则会占据很大的索引空间。

4、可以只为索引列前缀创建索引，减少索引占用的存储空间。

alter table single_table add index idx_key1(key1(10))

5、尽量使用覆盖索引进行查询，以避免回表操作带来的性能损耗。

select key1 from single_table order by key1

6、为了尽可能的少的让聚簇索引发生页面分裂的情况，建议让主键自增。

7、定位并删除表中的冗余和重复索引。

冗余索引：

单列索引：（字段1）

联合索引：（字段1 字段2）

重复索引：

在一个字段上添加了普通索引、唯一索引、主键等多个索引

6、执行计划

其中常用的是：

possible_keys: 可能用到的索引

key: 实际使用的索引

rows：预估的需要读取的记录条数

7、线上案例

案例1：

在建设互联网医院系统中，问诊单表当时量级23万左右，其中有一个business_id字符串字段，这个字段用来记录外部订单的ID，并且在该字段上也加了索引，但是'根据该ID查询详情'的SQL语句却总是时好时坏，性能不稳定，快则10ms，慢则2秒左右，SQL大体如下：

select 字段1、字段2、字段3 from nethp_diag where business_Id = ?

因为business_id是记录第三方系统的订单ID，为了兼容不同的第三方系统，因而设计成了字符串类型，但如果传入的是一个数字类型是无法使用索引的，因为MySQL只能将字符串转数字，而不能将数字转字符串，由于外部的ID有的是数字有的是字符串，因而导致索引一会可以走到，一会走不到，最终导致了性能的不稳定。

案例2：

在某次大促的当天，突然接到DBA运维的报警，说数据库突然流量激增，CPU也打到100%了，影响了部分线上功能和体验，遇到这种情况当时大部分人都比较紧张，下图为当时的数据库流量情况：

相关SQL语句：

select count(1)

from jdhe_medical_record

where status = 1 and is_test = #{isTest,jdbcType=INTEGER} and electric_medical_record_status in (2,3)

<if test="patientId != null">

and patient_id = #{patientId,jdbcType=BIGINT}

</if>

<if test="doctorPin != null">

and doctor_pin = #{doctorPin,jdbcType=VARCHAR}

</if>

and created >#{dateStart,jdbcType=TIMESTAMP};

</select>

当时的索引情况

当时的执行计划

其实在patientId和doctor_pin两个字段上是有索引的，但是由于线上情况的改变，导致test判断没有进入，这样的通用查询导致这两个字段没有设置上，进而导致了数据库扫描的量激增，对数据库产生了很大压力。

案例3：

2020年某日上午收到数据库CPU异常报警，对线上有一定的影响，后续检查数据库CPU情况如下，从7点51分开始，CPU从8%瞬间达到99.92%，丝毫没有给程序员留任何情面。

当时的SQL语句：

select rx_id, rx_create_time from nethp_rx_info where rx_status = 5 and status = 1 and rx_product_type = 0 and (parent_rx_id = 0 or parent_rx_id is null) and business_type != 7 and vender_id = 8888 order by rx_create_time asc limit 1;

当时的索引情况:

PRIMARY KEY (`id`), UNIQUE KEY `uniq_rx_id` (`rx_id`), KEY `idx_diag_id` (`diag_id`), KEY `idx_doctor_pin` (`doctor_pin`) USING BTREE, KEY `idx_rx_storeId` (`store_id`), KEY `idx_parent_rx_id` (`parent_rx_id`) USING BTREE, KEY `idx_rx_status` (`rx_status`) USING BTREE, KEY `idx_doctor_status_type` (`doctor_pin`, `rx_status`, `rx_type`), KEY `idx_business_store` (`business_type`, `store_id`), KEY `idx_doctor_pin_patientid` (`patient_id`, `doctor_pin`) USING BTREE, KEY `idx_rx_create_time` (`rx_create_time`)

当时这张表量级2000多万，而当这条慢SQL执行较少的时候，数据库的CPU也就下来了，恢复到了49.91%，基本可以恢复线上业务，从而表象就是线上间歇性的一会可以开方一会不可以，这条SQL当时总共执行了230次，当时的CPU情况也是忽高忽低，伴随这条SQL语句的执行情况，从而最终证明CPU的飙升是由于这条慢SQL。当线上业务逻辑复杂的时候，你很难第一时间知道到底是由于那条SQL引起的，这个就需要对业务非常熟悉，对SQL很熟悉，否则就会白白浪费大量的排查时间。

最后的排查结果：

在头天晚上的时候添加了一条索引rx_create_time，当时没事，但是第二天却出了事故。

加索引前后走的索引不同，一个是走的rx_status（处方审核状态）单列索引，一个是走的rx_create_time(处方提交事件)单列索引，这个就要回到业务，因为处方状态是个枚举，且枚举范围不到10个，也就说线上29,000,000的数据量也就是被分成了不到10份，rx_status=5的值是其中一份，因而通过这个索引就可以命中很多行，这是业务规则，再套用MySQL的特性，主要是以下几条：

1、没加新索引rx_create_time的时候，由于order by后边没有索引，就看where条件中是否有合适的索引，查询选择器选定rx_status这个单列索引，而rx_status=5这个条件下限制的数据行在索引中是连续，即使需要的rx_id不在索引中，再回主键聚簇索引也来得及，由于order by后边没有索引，所以走磁盘级别的排序filesort，高峰积压的时候处方就1万到2万，跑到了100ms,白天低谷的时候几百单也就20ms。

2、新加索引之后，就分两种情况：

2.1、加索引是在晚上，当前命中的行数比较少，由于当天晚上的时候待审核的处方确实很少，也就是rx_status=5的确实很少，查询优化器感觉反正没多少行，排序不重要，因而就还是选择rx_status索引。

2.2、第二天白天，待审核的处方数量很多了（rx_status=5的数据量多了），当时可以命中几万数据，如果当前命中的行数比较多，查询优化器就开始算成本，感觉排序的成本会更高，那就优先保排序吧，所以就选择rx_create_time这个字段，但是这个索引树上没有别的索引字段的信息，没办法，几乎每条数据都要回表，进而引发了灾难。

8、推荐用书

这本书以一种诙谐幽默的风格写了MySQL的一些运行机制，非常适合阅读，理解成本大幅降低。

https://item.jd.com/13009316.html

https://item.jd.com/10066181997303.html

9、一些感悟

关于数据库的性能优化其实是一个很复杂的大课题，很难通过一篇帖子讲的很全面和深刻，这也就是为什么我的标题是‘浅析’，程序员的成长一定是要付出代价和成本，因为只有真的在一线切身体会到当时的紧张和压力，对于一件事情才能印象深刻，但反之也不能太过于强调代价，如果可以通过一些别人的分享就可以规避一些自己业务的问题和错误的代价也是好的。

微信关注我们

原文链接：https://my.oschina.net/u/4090830/blog/6337911

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

【提升团队运营效率】交易履约之订单中心实践

本文作者：京东科技-市场与平台运营中心-平台研发部，晏银喜、张学君、袁宝龙、高传江、杨迎心、游斌平、付达。特别感谢：杨广兴、张然、姬英泽、赵宁、张彤，在系统建设过程中的贡献。 1、概述 1.1 交易履约是什么？首先定义下什么是交易履约，交易履约是在甲乙双方达成交易产生订单后，乙方按照订单条款为甲方提供服务或交付约定物的行为。 1.2 交易履约订单中心是个什么系统？交易履约订单中心为履约行为提供必要的系统能力支撑，交易履约订单中心记录了交易流通的过程和状态，包括交易主体、产品信息、成交金额、计费、支付、业务信息等全流程信息，为上下游提供数据标准化、全集数据查询和串联流程的功能。目前已接入的场景有：京音业绩匹配、交易数据看板、京音线上化结算、交易流程串联等。目前交易履约订单中心年订单量 1.5 亿+，在电销、企微、金店、开放平台、用户增长等场景下，有效支持了消金、财富、保险、支付、分期商城等各大业务线的线上、线下的业务发展。 2、名词解释数据来源：交易数据的来源，包含业务信息、联系人、数据接入协议等。订单模版：交易履约订单中心采用泛化的格式存储交易数据，针对每个交易场景配置一个...

2023-01-18

397

作者@lingsamuel，API7.ai 云原生技术专家，Apache APISIX Committer。作者@林志煌，API7.ai 技术工程师，Apache APISIX contributor。服务网格是一种技术架构，它用于管理微服务系统中各个服务之间的通信，旨在处理微服务间的流量（也称为东西向流量）。在云原生应用中，一个应用的背后可能存在着成百上千个服务，各个服务可能又有着若干个实例，各个实例的状态也一直在变化。在如此复杂的服务运行环境中，如何保障用户的可靠访问以及维持业务的平稳运行成为一个很大的挑战，服务网格的治理方案便应运而生。服务网格就像是微服务间的 TCP/IP，负责服务间的网络调用、限流限速、监控等。服务网格目前主要应用在 Kubernetes 平台上，其最经典的一种实现模式是 Sidecar 模式：将一些通用功能抽象到 Sidecar 容器中，并将 Sidecar 容器与服务容器挂载在同一个 Pod 里。由于 Sidecar 容器与服务容器并行，且各个 Sidecar 间相互通讯，共同构成了网格形式的网络，因此称之为服务网格。当然，Sidecar 并非唯一...

2023-01-18

417

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。