rookiedev

首先声明，由于 Dubbo 目前一直在不断迭代更新中，尤其对于一些比较老的版本实现方式可能完全是不一样的，就算新的版本之间也有一些细微的差别，而我下面的源码分析用的是 Dubbo 官方的消费端发起请求调用服务端接口的一个例子来进行源码分析，而且是基于 Dubbo 3.2.0-beta.4 的版本。

服务端定义和实现

这里用的是 Dubbo 官方最简单的一个 dubbo 接口请求的例子，服务端接口定义如下：

Dubbo 是什么

官方术语是这样来定义 Dubbo 的：

Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑，以改变框架的默认行为来满足自己的业务需求。

延迟队列或许大家都听过，可能也用过，一种比较常见的应用场景就是用户下单后，超过 10 分钟未支付将用户订单取消，这种其实就可以通过延迟队列来实现，这里先不考虑订单数量特别大的情况。大概流程就是用户下单后，订单服务创建订单保存后同时将这笔订单信息放入延迟队列中，设置延迟时间为 10 分钟，10 分钟后从队列中取出来判断支付状态，未支付则将这笔订单取消。

join 联表查询的性能

有时候可能会听说尽量不要使用 join 联表查询，或者更直接一点就禁止使用 join 联表查询，这时如果我们要查询的数据分布在两张关联表中，就不得不先去一张表里面查出要查询的数据，然后再根据关联字段去另一张表里面查出数据，但你有想过从查询性能上来说，这样做的查询速度就一定比 join 联表查询速度要快吗？不妨来看一个具体的例子，下面是活动表和城市编码表的表结构，活动表里面的 city_code 对应于城市编码表中的 code 字段:

上篇文章中从整体上介绍了 explain 的使用以及 explain 执行得到的这些字段含义和常见的值，那得到这些字段信息后，对于这个 SQL 要不要优化，又该怎么优化，这个似乎没有什么固定的标准，但总体来说的话，要尽量让我们的查询使用上索引，然后在使用上索引之后再进一步看有没有优化的空间，当然对于实在没法用上索引或者说业务上能接受没必要多建一个索引的查询，我们也可以尝试在用不上索引的情况下去看看还有没有进一步优化的空间。

SQL 执行速度评估

假如现在有一张活动表，表结构如下:

索引字段的查询方式

上篇文章我们介绍了什么是索引，索引的结构以及一些关于索引的细节问题，那 MySQL 又是怎么利用索引进行查询的，来看一个具体的查询示例，下面是 users 表的建表语句:

什么是索引

在日常开发中，如果遇到一个 SQL 查询比较慢的时候，我们可能会说给这个 SQL 的查询字段加个索引，那为什么给字段加个索引查询就变快了，索引到底是什么？或许只有清楚的知道索引是什么我们才能明白为什么加上索引之后查询就变快了。

change buffer 介绍

在介绍 change buffer 之前，先来看一个 SQL 的执行时涉及索引树的更新过程，比如下面的这个插入语句，

1

insert into users(id, identity) values(1, 4504);

对于 MySQL 事务，可能我们大家都不陌生，事务是对数据库中数据操作保证数据逻辑一致的最小操作单位，一个事务中可能包含多条语句，但这些语句作为一个整体，由事务来保证这个整体的操作要么都成功，要么都失败，不存在部分成功部分失败的情况。