Tech on 奥力手记

关于接口 mock 的技术实现

Mon, 11 Sep 2023 20:50:00 +0000

最近在做接口 mock 的功能，用到了一些新的技术，主要有 OpenAPI 规范、JsonSchema 和 mockjs。这里简单的记录下技术方案，以及过程中曾踩到的坑。

原理

整个的原理比较简单，首先 OpenAPI 定义了一套接口规范，按照这个规范我们可以准确的描述一个接口，比如接口的方法类型、出入参格式和内容描述。这是 OpenAPI 规范中文版的文档地址。Apifox、Postman 等接口管理工具对接口的定义也是以这个规范进行存储的。我们可以通过这个地址很直观的观察一份 OpenAPI 规范的接口数据是什么样的。

当我们拥有了接口定义之后，我们就知道了接口的返回体的结构，大部分的服务接口通常将数据以 JSON 的格式进行返回，而描述这个 JSON 格式的就是 JSON Schema。JSON Schema 是 JSON 数据的模式描述语言，用来定义 JSON 数据结构和格式约束。JSON Schema提供了一套验证 JSON 数据有效性的规则集。这是 JSON Schema 规范中文版的文档地址。如果你仔细看的话，就会发现 OpenAPI 规范里面对 JSON 类型的请求体或返回体的就是用 JSON Schema 进行描述的。

最后要做的事情，就是解析 JSON Schema 的定义，将其转换成 mockjs 的模板，让 mockjs 能够 mock 出对应的 JSON。当然我们 Java 微服务要使用 mockjs，需要使用到 ScriptEngine。

踩坑

OpenAPI 扩展字段的存储

为了前端能够直接使用 mockjs 的预制变量，我们对接口定义增加了一个名为 mock 的属性，用以存储预制变量。后面联调的时候发现 mock 属性虽然能够转换到 OpenAPI 格式中，但是读取不出来。最后排查是因为 OpenAPI 的扩展字段需要增加 x- 前缀，且通过 OpenAPIV3Parser.java 解析出来的时候，结构会有变化，不会放在存储的层级结构下，而是放在 extensions 属性字段下面。

【DevOps】使用 Docker 搭建 MySQL 主从复制架构

Wed, 28 Jun 2023 18:30:00 +0000

这篇文章介绍一下如何使用 Docker 搭建 MySQL 主从复制架构，文中的架构中包含一个主节点 master，一个从节点 slave。

创建 docker 网络

在 Docker 中，容器之间如果需要可以相互访问，那么你需要把这些容器添加到同一个 Docker 网络中。创建一个叫 mysql-net 的 Docker 网络，命令如下：

`1`	`docker network create mysql-net`

搭建 master 节点

配置文件

配置 master 节点的配置文件 my.conf，注意修改 server-id，这里我们将 server-id 设置为 1。MySQL 复制过程中，主服务器和从服务器需要具有不同的 server id。配置文件内容如下：

[mysqld]
server-id=1
user=mysql
character-set-server=utf8
collation-server=utf8_unicode_ci
default_authentication_plugin=mysql_native_password
secure_file_priv=/var/lib/mysql
expire_logs_days=7
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
max_connections=1000

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

启动容器

在本地创建 master 节点的 logs、data、conf 挂载到 Docker 容器，启动容器的命令如下：

docker run --name mysql-master \
-v /Users/orechou/docker/mysql-cluster/master/logs:/var/log/mysql \
-v /Users/orechou/docker/mysql-cluster/master/data:/var/lib/mysql \
-v /Users/orechou/docker/mysql-cluster/master/conf:/etc/mysql \
--network=mysql-net \
-p 3306:3306 \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql/mysql-server:latest

注意我们将本机的 3306 端口映射到容器的 3306 端口，并将容器加入到 mysql-net 网络中。

【DevOps】使用 Grafana 和 Prometheus 做服务监控

Tue, 27 Jun 2023 15:45:00 +0000

最近需要对自己的一些服务做监控，于是想要动手实践使用一下 Grafana 和 Prometheus。这篇文章就主要介绍搭建 Grafana 和 Prometheus 对 MySQL 做监控的过程。

工具介绍

Prometheus 是一个开源的系统监控和警报工具包，由 SoundCloud 启动。它的设计目标是对大规模的服务容器和微服务体系结构提供稳健的可靠性和实时的度量。Prometheus 提供了多种数据收集机制，包括通过 HTTP 拉取目标应用程序暴露的 metrics，通过服务发现或者静态配置去发现新的目标，或者接受推送的时间序列数据。Prometheus 还提供了一种灵活的查询语言（PromQL），以便在其数据上进行切片和切块，生成聚合，预测等操作。 Prometheus 服务器以一个独立的服务器形式运行，它从被配置的位置定期拉取度量数据，将数据存储在它的时间序列数据库中，并运行定义的警报规则以生成新的警报。它的核心组件是一个多维数据模型和一套灵活的查询语言。在数据收集方面，它主要采用了一种拉模式的设计，也支持推模式的数据收集。

Grafana 是一个开源的度量分析和可视化套件。它通常被用于时间序列数据的可视化，这种数据通常来源于如今在软件开发中广泛使用的实时监控系统，如 Prometheus。Grafana 主要用于可视化和探索度量数据。它可以通过一种查询编辑器（这种编辑器支持数据源特定的语言）来创建可视化的图表，并通过一种灵活的方式将这些图表组织在一个或多个"仪表板"上。此外，Grafana 还支持警报和通知功能，以及丰富的插件生态系统。 Grafana 是一个前后端分离的 Web 应用程序。其前端部分使用 AngularJS 和 Later.js 构建，后端部分则使用 Go 语言编写。在运行时，Grafana 服务器将请求时间序列数据，然后运行查询并将结果绘制成图表。

搭建过程

docker 运行 MySQL

首先，我们用 docker 启动一个 MySQL 8.0 的容器，来充当我们需要被监控的服务。

创建 MySQL 8.0 配置文件 my.conf，该配置文件需要放在 conf 文件夹下，配置如下：

[mysqld]
user=mysql
character-set-server=utf8
collation-server=utf8_unicode_ci
default_authentication_plugin=mysql_native_password
secure_file_priv=/var/lib/mysql
expire_logs_days=7
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
max_connections=1000

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

docker 命令如下：

docker pull mysql/mysql-server

docker run -p 3306:3306 --name mysql-8.0 \
-v /Users/orechou/docker/mysql8/logs:/var/log/mysql \
-v /Users/orechou/docker/mysql8/data:/var/lib/mysql \
-v /Users/orechou/docker/mysql8/conf:/etc/mysql \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql/mysql-server:latest

注意，你需要把命令中的本地挂载路径改成你自己机器上的路径。容器启动起来之后，远程连接 MySQL 的时候出现如下异常：HY000][1130] null, message from server: “Host ‘172.17.0.1’ is not allowed to connect to this MySQL server”. 则是需要配置mysql对外开放连接权限，操作如下：

JUC 工具：LockSupport

Fri, 09 Jun 2023 17:00:00 +0000

简介

LockSupport 是 Java 并发工具包 java.util.concurrent 中的一个用于创建锁和其他同步类的基本线程阻塞原语。LockSupport 提供了 park() 和 unpark() 方法来停止和恢复线程。这些方法比低级的 wait/notify 和 notifyAll 方法更容易使用，并且与 java.util.concurrent 的高级同步工具更好地互相配合。

示例

在下面这个例子中，我们定义了两个线程。t1 打印数字，t2 打印字母。我们想要实现的效果是 t1 和 t2 交替打印，即输出结果为 “1A2B3C4D5E6F7G”。使用 LockSupport 的 park() 和 unpark() 方法，我们可以精确地控制线程的执行顺序，实现线程间的同步。

import java.util.concurrent.locks.LockSupport;

public class LockSupportDemo {
    static Thread t1 = null, t2 = null;

    public static void main(String[] args) {
        char[] a1 = "1234567".toCharArray();
        char[] a2 = "ABCDEFG".toCharArray();

        t1 = new Thread(() -> {
            for (char c : a1) {
                System.out.print(c);
                LockSupport.unpark(t2); // 叫醒t2
                LockSupport.park(); // 阻塞t1
            }
        }, "t1");

        t2 = new Thread(() -> {
            for (char c : a2) {
                LockSupport.park(); // 阻塞t2
                System.out.print(c);
                LockSupport.unpark(t1); // 叫醒t1
            }
        }, "t2");

        t1.start();
        t2.start();
    }
}

答疑

Q1：park 方法中的 blocker 的作用

这个 blocker 参数实际上是一个与该挂起操作关联的对象，这个对象会在调用 park() 方法后被设置到该线程，用于后续诊断和监控工具查看。它并不参与 park() 方法的工作逻辑，也不会影响挂起或者恢复线程的操作。这个对象通常是执行该操作的同步抽象（例如锁）。在调用 park 方法之后，可以使用 getBlocker(Thread) 方法来检索和清除该对象。

Kafka 消息大量积压的一些总结

Sat, 03 Jun 2023 16:30:00 +0000

本文主要总结一些 Kafka 作为消息队列使用时，当线上出现消息大量积压后的处理方法以及平时使用时应该注意的点。一般从三个方向排查分析问题，消费者的问题、分区设计的问题和网络问题。

消费者导致

大部分消息积压基本都是消费者出现了状况，消费者处理的速度慢、或者消费者出现了故障。确认消费者出现问题后，我们首先要做的就是恢复或者提高消费速度。

提高消费速度

一般来说，我们会对消息队列里面消息数量做监控，当消息到达一定阈值的时候，自动化地去对消费者的数量扩容。但是因为 Kafka 的 Topic 的 Partition 数量是有限制的，当消费者的数量扩容到 Partition 数量之后，再对消费者数量进行增加就没有作用了。如果这时并没有解决消费者速度的问题，我们需要能够快速把消费的能力再放大，相应的步骤如下：

问题修复: 先解决消费者的问题，以恢复消费速度，随后停止所有消费者。
新建 Topic: 创建一个新 Topic，其 Partition 数量是原先的 10 倍，并且创建相应数量的队列。一般不直接对原 Topic 的分区进行调整，因为分区增加之后没有办法去缩小。
数据分发: 编写并部署一个临时的消费者程序，此程序将积压的数据消费后，不进行耗时处理，而是均匀分发至新创建的队列中。
并发消费: 临时增加 10 倍的消费者机器，每一批消费者消费一个临时队列的数据，相当于以原本的10倍速度消费数据。
架构恢复: 在积压数据消费完后，恢复原始架构，重新用原先的消费者机器来消费消息。

上面的方法能够快速地解决线上堆积了大量的消息。除此之外，我们对消费者的设计也会影响到消费的速率。

其他的注意点

控制消费者获取消息的数量

Kafka 支持批量消费数据。在消费者端，可以通过修改配置参数来改变每次从 Kafka 服务器获取的消息数量。这主要通过以下两个配置参数控制：

fetch.min.bytes: 消费者从服务器获取的最小数据，如果不满足这个值，消费者会等待直到满足此值。
fetch.max.wait.ms: 消费者等待 Kafka 服务端积累数据的最长时间。还有一个与之相关的参数：
max.poll.records：它能够控制消费者每次调用 poll() 时返回的最大记录数。

以上三个参数都是在实时性和吞吐量之间进行权衡的，你可以根据业务需求，对这些参数进行适当的调整。在调整这些参数之前，最好先在测试环境中进行性能测试，以确定最佳的参数设置。

如果你的业务场景对实时性要求较高，即希望消息一生成就能尽快被消费，那么 fetch.min.bytes 可以设置得较小，fetch.max.wait.ms 也可以设置得较小，这样可以确保消费者能够更快地获取到新的消息。
如果你的业务场景对吞吐量要求较高，即希望消费者能够以较高的速度处理大量的消息，那么 fetch.min.bytes 可以设置得较大，fetch.max.wait.ms 也可以设置得较大，这样可以通过增加每次获取的消息数量，提高消费者的处理效率。
max.poll.records 参数用于控制每次调用poll()时返回的最大记录数。如果你希望消费者每次能处理更多的消息，可以增大这个值。但是，这个值的增大可能会增加消费者处理消息的延迟。

优化消费者的处理逻辑

对于消费者的处理代码，优化其代码逻辑。有以下的点可以考虑：

是否能够使用多线程来加快业务逻辑的处理速度；
是否能够减少数据库的调用次数；
是否能够减少下游 PRC 调用的次数。

分区设计不合理导致

观察 Kafka 的消费在不同的 Partition 上的消息堆积情况，如果消息主要分布在部分 Parition 上，那么我们也许要确认是否是分区设计不合理导致。如果是的话，可能需要重新设计分区策略。比如，考虑使用更细粒度的key进行分区，或者增加总的分区数。

Bcrypt 加密算法详解

Sun, 12 Feb 2023 18:00:00 +0000

最近在回顾中台系统的用户权限设计，在用户密码落库这块使用了 Bcrypt 算法来保证安全性，这篇文章是对该算法的一个详细介绍。

什么是 Bcrypt 加密算法

Bcrypt 是一种密码哈希函数，用于加密用户密码。它是一种强大且安全的算法，用于存储用户密码，并在用户登录时进行验证。 Bcrypt 算法使用了 Blowfish 加密算法，它在对用户密码进行加密时需要一个随机的盐值，这样就可以避免暴力破解。此外，Bcrypt 算法还具有慢哈希的特性，即在加密过程中使用的复杂度可以通过 cost 参数来控制，从而使用户的密码更加安全。

加密的过程

生成 Salt

首先，Bcrypt 会生成一个随机的 salt，这个 salt 会被用于密码加密过程。

对密码和 salt 进行加密

然后，密码和 salt 会被结合在一起，并使用密码哈希函数进行加密。

增加复杂度

在加密的过程中，Bcrypt 会使用指定的 cost 参数进行加密，这个参数代表加密的次数。通过增加 cost 参数，可以使加密过程更加复杂，从而提高密码的安全性。

生成密文

Bcrypt 加密后的密文是一个长度为 60~100 个字符的字符串。它包含了以下几部分信息：

版本标识：Bcrypt 的密文开头一般以 “$2y$” 或 “$2a$” 开头，这代表了 Bcrypt 的版本信息。
cost 参数：密文的下一个字符是数字，代表了 Bcrypt 加密过程中使用的 cost 参数。
salt：接下来的 22 个字符代表了随机生成的 salt。使用 Base64 编码。
哈希值：最后的字符串是加密后的哈希值，代表了密码的密文形式。使用 Base 64 编码。一个加密后的密文可能如下所示："$2a$10$S8U6dsEjvAUtf7XuUzK8.eDmI.xMh7OJj0s8Q7WuOvZDz9XBk1PM2"。

与 SHA-256 算法的对比

Bcrypt 和 SHA-256 都是常用的哈希算法，但它们的安全性是有所不同的。Bcrypt 有如下的优点：

关于 PriorityOrdered 和 Ordered 的使用

Thu, 09 Feb 2023 23:00:00 +0000

背景

在调试某个 Springboot 项目业务代码的时候发现了一个现象：Bean 通过实现 Ordered 或 PriorityOrdered 接口来定义优先级，然后用 AnnotationAwareOrderComparator 对些 Bean 进行排序的时候，其顺序并没有按照 order 的大小进行排序。相关的代码如下：

public class A implements PriorityOrdered {
	
    @Override  
    public int getOrder() {  
        return 0;  
    }
	
}

public class B implements Ordered {
    @Override  
    public int getOrder() {  
        return -1;  
    }
}

public class C implements Ordered {

    @Override  
    public int getOrder() {  
        return -2;  
    }
	
}

public class Test {

    public void sort() {
        List<Object> list = new ArrayList();
        list.add(new A());
        list.add(new B());
        list.add(new C());

        // 排序的结果为: A->C->B，而不是第一反应认为的 C->B->A
        AnnotationAwareOrderComparator.sort(list);
    }
	
}

原因

跟一下源码可以很快查到原因，AnnotationAwareOrderComparator 是继承的 OrderComparator，而 OrderComparator 的比较是这样的：

自定义 Spring Security 鉴权

Wed, 01 Jun 2022 17:00:00 +0000

背景

当我们使用 Spring 技术栈搭建单体的系统或服务时，若系统涉及到登录鉴权等功能，一般会使用 SpringSecurity 搭配一个 RBAC 的权限模型，很容易实现一套 OAuth2 鉴权、授权的流程。随着业务扩展，单体的服务作为一个微服务并入一个大的系统之后。我们为保证其他业务能够调用该单体服务，但是又无法让其他系统来使用该服务已有鉴权，从而引入其他微服务都用基础的鉴权服务。根据业务场景的区分，当单体服务内部使用的时候走 SpringSecurity 的鉴权，单体服务外部调用的时候使用基础鉴权服务鉴权。

基础

要根据不同的场景启用或绕过 SpringSecurity。我们可以首先想到能否通过 URL 来区分不同的场景，使用 HttpSecurity 的 permitAll() 和 authenticated() 来让不同路径的接口是否需要走鉴权。除此之外，可以去修改 SpringSecurity 的 Filter ，使用自定义 Filter 或者用动态代理对 Filter 进行增强。

实现

@Aspect
@Component
@Slf4j
public class AuthorizationHeaderAspect {

    /**
     * 基础鉴权服务 Feign 调用业务
     */
    @Autowired
    private OauthFeignBiz oauthFeignBiz;

    @Pointcut("execution(* org.springframework.security.oauth2.provider.authentication.OAuth2AuthenticationProcessingFilter.doFilter(..))")
    public void securityOauth2DoFilter() {
    }

    @Pointcut("execution(* org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(..))")
    public void securitySecurityInterceptor2DoFilter() {

    }

    @Around("securityOauth2DoFilter()")
    public void enhanceSecurityOauth2DoFilter(ProceedingJoinPoint joinPoint) throws Throwable {
        Object[] args = joinPoint.getArgs();
        if (args == null || args.length != 3 || !(args[0] instanceof HttpServletRequest && args[1] instanceof javax.servlet.ServletResponse && args[2] instanceof FilterChain)) {
            joinPoint.proceed();
            return;
        }

        HttpServletRequest request = (HttpServletRequest) args[0];
        String accessToken = request.getHeader("Authorization");

        if (StringUtils.isNotBlank(request.getParameter("sceneId")) && StringUtils.isNotBlank(request.getParameter("sceneType"))) {
            // 这里我们可以根据业务场景确定走哪种鉴权方式
            SecurityUtils.setBaseAuth(true);
        } else {
            SecurityUtils.setBaseAuth(false);
        }

        if (SecurityUtils.isBaseAuth()) {
            Response<CheckTokenResponse> checkTokenResponse = oauthFeignBiz.checkToken(accessToken);
            if (checkTokenResponse.getCode() == 0) {
                SecurityUtils.setBaseAuth((true));
                ((FilterChain) args[2]).doFilter((ServletRequest) args[0], (ServletResponse) args[1]);
            } else {
                throw new Exception("鉴权失败");
            }
        } else {
            // 让原 Filter 的逻辑继续执行
            joinPoint.proceed();
        }
    }

    @Around("securitySecurityInterceptor2DoFilter()")
    public void enhanceSecuritySecurityInterceptor2DoFilter(ProceedingJoinPoint joinPoint) throws Throwable {
        Object[] args = joinPoint.getArgs();
        if (args == null || args.length != 3 || !(args[0] instanceof HttpServletRequest && args[1] instanceof javax.servlet.ServletResponse && args[2] instanceof FilterChain)) {
            joinPoint.proceed();
            return;
        }

        if (!SecurityUtils.isBaseOauth()) {
            joinPoint.proceed();
            return;
        }
        ((FilterChain) args[2]).doFilter((ServletRequest) args[0], (ServletResponse) args[1]);
    }

}

使用 SwiftUI 在地图中绘制坐标轨迹

Sun, 27 Mar 2022 17:43:00 +0000

一直有想做属于自己的 App 的想法，零零散散地有学习一些内容，现在决定开启一个记录学习过程的系列博文，以此来巩固自己所学到的 iOS 开发知识和激励自己把第一个 App 实现出来。脑海中一直有个做地图类应用的想法，本科做移动轨迹相关的毕业设计。此类应用主要包括地图（Map）、坐标点（Location）、绘制轨迹（Polyline）几个要素。这篇博文将会使用 SwiftUI 在地图上连接坐标点绘制出轨迹。GPS 坐标数据可以在 microsoft 上下载。效果如下：首先创建一个 SwiftUI 工程的项目，项目的文件组织如下：先定义坐标点的数据结构，代码如下：

import Foundation

struct Location: Hashable, Codable, Identifiable {
    var id: Int
    // 经度
    var longitude: Double
    // 纬度
    var latitude: Double
    var isValid: Bool
}

坐标数据的 ViewModel，我们将从 location.json 中加载所有的坐标点，代码如下：

【MySQL】实现列表数据置顶

Mon, 16 Aug 2021 14:46:00 +0000

有的列表获取的业务场景，需要根据一些条件将数据置顶。

例如有一张表有 id 和 name 两个字段。数据表如下。

id	name
1	1_name
2	2_name
3	3_name
4	4_name
5	5_name
6	6_name
7	7_name
8	8_name
9	9_name
10	10_name

若需要将 id 为 5 和 7 的数据置顶，并且分页的 size 是 5 的话，我们的 SQL 可以这样写：

SELECT * FROM goods ORDER BY 
	CASE 
		WHEN id = 5 THEN -10000
		WHEN id = 7 THEN -9999 
		ELSE id 
	END
LIMIT 0, 5

【MySQL】慢 SQL 分析

Tue, 10 Aug 2021 12:30:00 +0000

慢查询日志分析

设置慢查询

可以通过修改命令设置：

设置开启：SET GLOBAL slow_query_log = 1; #默认未开启，开启会影响性能，mysql重启会失效
查看是否开启：SHOW VARIABLES LIKE ‘%slow_query_log%’;
设置阈值：SET GLOBAL long_query_time=3;
查看阈值：SHOW 【GLOBAL】 VARIABLES LIKE ’long_query_time%’; #重连或新开一个会话才能看到修改值

也可以通过修改配置文件设置，配置文件 my.conf 会一直生效，在[mysqld]下配置：

    [mysqld]
    slow_query_log = 1;　　#开启
    slow_query_log_file=/var/lib/mysql/atguigu-slow.log　　　#慢日志地址，缺省文件名host_name-slow.log
    long_query_time=3;　　  #运行时间超过该值的SQL会被记录，默认值>10
    log_output=FILE

获取慢 SQL 信息

查看慢查询日志记录数：SHOW GLOBAL STATUS LIKE ‘%Slow_queries%’;

模拟语句：SELECT SLEEP(4);

查看慢查询日志：

    $ cat /usr/local/var/mysql/OreChoudeMacBook-Pro-slow.log
    /usr/local/Cellar/mysql/8.0.25_1/bin/mysqld, Version: 8.0.25 (Homebrew). started with:
    Tcp port: 3306  Unix socket: /tmp/mysql.sock
    Time                 Id Command    Argument
    # Time: 2021-08-10T06:29:53.513752Z
    # User@Host: root[root] @ localhost [127.0.0.1]  Id:    11
    # Query_time: 4.003605  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1
    use test;
    SET timestamp=1628576989;
    select sleep(4);

使用 mysqldumpslow 分析

使用样例：

【MySQL】Explain

Fri, 06 Aug 2021 17:00:00 +0000

MySQL Explain

Explain 是 MySQL 自带的查询优化器。

使用 Explain + SQL 可查询出执行的相关信息，主要包含以下 10 个属性： id, select_type, table, type, possible_key, key, key_len, ref, row, filtered, Extra

数据库性能瓶颈，主要关注 CPU 和 IO。

id

反映的是表的读取顺序，或者查询中 SELECT 的执行顺序。

小表永远驱动大表，三种情况：（1）id 相同，执行顺序是由上至下的（2）id 不同，如果是子查询，id 序号会递增，id 值越大优先级越高，越先被执行（3）id 存在相同的，也存在不同的，所有组中，id 越大越先执行，如果 id 相同的，从上往下顺序执行

select_type

反映的是 MySQL 理解的查询类型，有几下几种：

SIMPLE：简单的 SELECT 查询，查询中不包含子查询或 UNION
PRIMARY：查询中若包含任何复杂的字部分，最外层查询标记为 PRIMARY
SUBQUERY：SELECT 或 WHERE 列表中的子查询
DERIVED：在 FROM 列表中包含的子查询，MySQL 会递归执行这些子查询，把结果放在临时表里
UNION：若第二个 SELECT 出现在 UNION 后，则被标记为 UNION，若 UNION 包含在 FROM 字句的子查询中，外层 SELECT 将被标记为 DERIVED
UNION RESULT：UNION 后的结果集

table

反映的是数据从哪张表中读取出来。