前言

关于前面讲过的知识点我就不再赘述了，还没看过的朋友可以进入我的首页进行查阅（前言部分附赠飞机票）。这篇文章将是整个专题的总结，而且也是面试官会问到的最高频率的一个问题——“你对 MySQL 的性能优化有什么想法？”

很多出去面试的朋友应该基本上都会被问到这个问题，但是可能能够回答得尽善尽美的比较少，看过我专题且能够消化成自己肚子里的东西的朋友应该可以吊打面试官了哈哈哈哈（针对中高级），希望今天这篇文章之后大家能够对自己脑海中零散知识点进行整合整理，我盼着你们能回来给我报喜（当然吐苦水也可以），也盼着能跟大家一起不断进步。

回到正题，关于这次的 MySQL 性能优化的知识点，我会分成两篇幅的文章来输出，关于 SQL 语句的性能优化我会以单独的篇幅来进行编写，语句优化在实操中是属于性能优化的最高级别的优化点，希望大家也能好好消化。

这个 MySQL 专题是我从年前就一直在准备的，刚好过年在家也没事就一直在思考着要怎么去发表这部分的文章，让大家能够看的时候思路比较清晰，记忆能够更加深刻，最后我是通过先发布脑图，然后再根据脑图的方向进行专题知识点的发表，之后应该也会是这种形式，毕竟，这样我写文章思路清晰，大家看文章的时候思路也清晰嘛，复习知识点的时候也可以根据脑图来。

博文是我从去年开始写的，之前是自己在云笔记上做笔记比较多。我觉得做笔记写总结对自我提升有很大的帮助，而分享出来，也是希望大家能够从中学到新的知识，同时也能帮助我一起不断改进，给我提一些建议，让我在给大家分享总结的东西的同时自己也能查缺补漏（再次感谢一直以来支持我的朋友们 Thanks♪(･ω･)ﾉ）

关于下一个专题我还没想好要写什么，大家如果有什么想法的话可以在公众号给我留言。

这个篇章是性能优化篇章兄弟篇，SQL语句优化，在面试中也是重中之重，希望各位小伙伴重视。

老规矩，先上飞机票：

1. MySQL相关（一）- 一条查询语句是如何执行的
2. MySQL相关（二）- 一条更新语句是如何执行的
3. MySQL相关（番外篇）- innodb 逻辑存储结构；
4. MySQL相关（三）- 索引数据模型推演及 B+Tree 的详细介绍；
5. MySQL相关（四）- 性能优化关键点索引
6. MySQL相关（五）- 事务特性及隔离级别的详细介绍
7. MySQL相关（六）- 事务隔离级别的实现方案（MVCC）
8. MySQL相关（七）- innodb 锁的介绍及使用
9. MySQL相关（八）- innodb行级锁深入剖析
10. MySQL相关（九）- 死锁的发生和避免

前面提到的脑图如下，想要完整高清图片可以到微信我的公众号下【6曦轩】下回复 MySQL 脑图获取：

在这里插入图片描述

正文

优化器——SQL 语句分析与优化

优化器就是对我们的 SQL 语句进行分析，生成执行计划。

我们做项目的时候，有时会收到 DBA 的邮件，里面列出了我们项目上几个耗时比较长的查询语句，让我们去优化，这些语句是从哪里来的呢？

我们的服务层每天执行了这么多 SQL 语句，它怎么知道哪些 SQL 语句比较慢呢？首先，我们要把 SQL 执行情况记录下来。

慢查询日志 slow query log

官网说明：https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html

打开慢日志开关

因为开启慢查询日志是有代价的（跟 binlog、optimizer-trace 一样），所以在 MySQL 中，它默认是关闭的：

show variables like 'slow_query%';

在这里插入图片描述

除了这个开关，还有一个参数，控制执行超过多长时间的 SQL 才记录到慢日志，默认是 10 秒。

show variables like '%slow_query%';

可以直接动态修改参数（重启后失效）。

set @@global.slow_query_log=1;  -- 1 开启，0 关闭，重启后失效

set @@global.long_query_time=3; -- mysql 默认的慢查询时间是 10 秒，另开一个窗口后才会查到最新值

show variables like '%long_query%';

show variables like '%slow_query%';

或者修改配置文件 my.cnf。

以下配置定义了慢查询日志的开关、慢查询的时间、日志文件的存放路径。

slow_query_log = ON

long_query_time=2

slow_query_log_file =/var/lib/mysql/localhost-slow.log

模拟慢查询：

select sleep(10);

查询 user_innodb 表的 500 万数据（检查是不是没有索引）。

SELECT * FROM `user_innodb` where phone = '136';

慢日志分析

1. 日志内容

show global status like 'slow_queries'; -- 查看有多少慢查询 show variables like '%slow_query%'; -- 获取慢日志目录

cat /var/lib/mysql/ localhost-slow.log

在这里插入图片描述

有了慢查询日志，怎么去分析统计呢？比如 SQL 语句的出现的慢查询次数最多，平均每次执行了多久？

2. mysqldumpslow

通过官网的说明来看一下：https://dev.mysql.com/doc/refman/5.7/en/mysqldumpslow.html

MySQL 提供了 mysqldumpslow 的工具，在 MySQL 的 bin 目录下。

mysqldumpslow --help

例如：查询用时最多的 20 条慢 SQL：

mysqldumpslow -s t -t 20 -g 'select' /var/lib/mysql/localhost-slow.log

Count 代表这个 SQL 执行了多少次；

Time 代表执行的时间，括号里面是累计时间；

Lock 表示锁定的时间，括号是累计；

Rows 表示返回的记录数，括号是累计。

除了慢查询日志之外，还有一个 SHOW PROFILE 工具可以使用。

SHOW PROFILE

https://dev.mysql.com/doc/refman/5.7/en/show-profile.html

SHOW PROFILE 是谷歌高级架构师 Jeremy Cole 贡献给 MySQL 社区的，可以查看SQL 语句执行的时候使用的资源，比如 CPU、IO 的消耗情况。

在 SQL 中输入 help profile 可以得到详细的帮助信息。

查看是否开启

select @@profiling;

set @@profiling=1;

查看 profile 统计

show profiles;//命令最后带一个 s

在这里插入图片描述

查看最后一个 SQL 的执行详细信息，从中找出耗时较多的环节（没有 s）。

show profile;//没有 s

在这里插入图片描述

6.2E-5，小数点左移 5 位，代表 0.000062 秒。

也可以根据 ID 查看执行详细信息，在后面带上 for query + ID。

show profile for query 1;

除了慢日志和 show profile，如果要分析出当前数据库中执行的慢的 SQL，还可以通过查看运行线程状态和服务器运行信息、存储引擎信息来分析。

其他系统命令

show processlist 运行线程

https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html

show processlist;

这是很重要的一个命令，用于显示用户运行线程。可以根据 id 号 kill 线程。

也可以查表，效果一样：

select * from information_schema.processlist;

在这里插入图片描述

show status 服务器运行状态

https://dev.mysql.com/doc/refman/5.7/en/show-status.html

SHOW STATUS 用于查看 MySQL 服务器运行状态（重启后会清空），有 session

和 global 两种作用域，格式：参数-值。

可以用 like 带通配符过滤。

SHOW GLOBAL STATUS LIKE 'com_select'; -- 查看 select 次数

show engine 存储引擎运行信息

https://dev.mysql.com/doc/refman/5.7/en/show-engine.html

show engine 用来显示存储引擎的当前运行信息，包括事务持有的表锁、行锁信息；

事务的锁等待情况；线程信号量等待；文件 IO 请求；buffer pool 统计信息。

例如：

show engine innodb status;

如果需要将监控信息输出到错误信息 error log 中（15 秒钟一次），可以开启输出。

show variables like 'innodb_status_output%';

--开启输出：

SET GLOBAL innodb_status_output=ON;

SET GLOBAL innodb_status_output_locks=ON;

我们现在已经知道了这么多分析服务器状态、存储引擎状态、线程运行信息的命令，如果让你去写一个数据库监控系统，你会怎么做？

其实很多开源的慢查询日志监控工具，他们的原理其实也都是读取的系统的变量和状态。

现在我们已经知道哪些 SQL 慢了，为什么慢呢？慢在哪里？

MySQL 提供了一个执行计划的工具（在架构中我们有讲到，优化器最终生成的就是一个执行计划），其他数据库，例如 Oracle 也有类似的功能。

通过 EXPLAIN 我们可以模拟优化器执行 SQL 查询语句的过程，来知道 MySQL 是怎么处理一条 SQL 语句的。通过这种方式我们可以分析语句或者表的性能瓶颈。

explain 可以分析 update、delete、insert 么？

MySQL 5.6.3 以前只能分析 SELECT; MySQL5.6.3 以后就可以分析 update、delete、 insert 了。

EXPLAIN 执行计划

官方链接：https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

我们先创建三张表。一张课程表，一张老师表，一张老师联系方式表（没有任何索引）。

DROP TABLE IF EXISTS course;

CREATE TABLE `course` (
    `cid` int(3) DEFAULT NULL,
    `cname` varchar(20) DEFAULT NULL,
    `tid` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DROP TABLE IF EXISTS teacher;

CREATE TABLE `teacher` (
    `tid` int(3) DEFAULT NULL,
    `tname` varchar(20) DEFAULT NULL,
    `tcid` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DROP TABLE IF EXISTS teacher_contact;

CREATE TABLE `teacher_contact` (
    `tcid` int(3) DEFAULT NULL,
    `phone` varchar(200) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

​INSERT INTO `course` VALUES ('1', 'mysql', '1');

INSERT INTO `course` VALUES ('2', 'jvm', '1');

INSERT INTO `course` VALUES ('3', 'juc', '2');

INSERT INTO `course` VALUES ('4', 'spring', '3');

INSERT INTO `teacher` VALUES ('1', 'jerry', '1');

INSERT INTO `teacher` VALUES ('2', 'jack', '2');

INSERT INTO `teacher` VALUES ('3', 'mic', '3');

INSERT INTO `teacher_contact` VALUES ('1', '13688888888');

INSERT INTO `teacher_contact` VALUES ('2', '18166669999');

INSERT INTO `teacher_contact` VALUES ('3', '17722225555');

explain 的结果有很多的字段，我们详细地分析一下。

先确认一下环境：

select version();
show variables like '%engine%';

id

id 是查询序列编号。

id 值不同

id 值不同的时候，先查询 id 值大的（先大后小）。

--查询 mysql 课程的老师手机号

EXPLAIN SELECT tc.phone FROM teacher_contact tc WHERE tcid = (
    SELECT tcid FROM teacher t WHERE t.tid = ( SELECT c.tid FROM course c WHERE c.cname = 'mysql')
);

查询顺序：course c——teacher t——teacher_contact tc。

在这里插入图片描述

先查课程表，再查老师表，最后查老师联系方式表。子查询只能以这种方式进行，只有拿到内层的结果之后才能进行外层的查询。

id 值相同

--查询课程 ID 为 2，或者联系表 ID 为 3 的老师

EXPLAIN
SELECT t.tname,c.cname,tc.phone
FROM teacher t, course c, teacher_contact tc WHERE t.tid = c.tid
AND t.tcid = tc.tcid AND (c.cid = 2 OR tc.tcid = 3);

id 值相同时，表的查询顺序是从上往下顺序执行。例如这次查询的 id 都是 1，查询的顺序是 teacher t（3 条）——course c（4 条）——teacher_contact tc（3 条）。

teacher 表插入 3 条数据后：

INSERT INTO `teacher` VALUES (4, 'james', 4);

INSERT INTO `teacher` VALUES (5, 'tom', 5);

INSERT INTO `teacher` VALUES (6, 'seven', 6);

COMMIT;

--（备份）恢复语句

DELETE FROM teacher where tid in (4,5,6);

COMMIT;

id 也都是 1，但是从上往下查询顺序变成了：teacher_contact tc（3 条）——teacher t（6 条）——course c（4 条）。

在这里插入图片描述

为什么数据量不同的时候顺序会发生变化呢？这个是由笛卡尔积决定的。

举例：假如有 a、b、c 三张表，分别有 2、3、4 条数据，如果做三张表的联合查询，当查询顺序是 a→b→c 的时候，它的笛卡尔积是：234=64=24。如果查询顺序是 c →b→a，它的笛卡尔积是 432=122=24。

因为 MySQL 要把查询的结果，包括中间结果和最终结果都保存到内存，所以 MySQL 会优先选择中间结果数据量比较小的顺序进行查询。所以最终联表查询的顺序是 a→b→ c。这个就是为什么 teacher 表插入数据以后查询顺序会发生变化。

（小表驱动大表的思想）

既有相同也有不同如果 ID 有相同也有不同，就是 ID 不同的先大后小，ID 相同的从上往下。

select type 查询类型

这里并没有列举全部（其它：DEPENDENT UNION、DEPENDENT SUBQUERY、MATERIALIZED、UNCACHEABLE SUBQUERY、UNCACHEABLE UNION）。

下面列举了一些常见的查询类型：

• SIMPLE

简单查询，不包含子查询，不包含关联查询 union。
EXPLAIN SELECT * FROM teacher;

在这里插入图片描述

再看一个包含子查询的案例：
--查询 mysql 课程的老师手机号
EXPLAIN SELECT tc.phone FROM teacher_contact tc WHERE tcid = (SELECT tcid FROM teacher t WHERE t.tid = ( SELECT c.tid FROM course c WHERE c.cname = 'mysql'));

在这里插入图片描述

• PRIMARY

子查询 SQL 语句中的主查询，也就是最外面的那层查询。

• SUBQUERY

子查询中所有的内层查询都是 SUBQUERY 类型的。

• DERIVED

衍生查询，表示在得到最终查询结果之前会用到临时表。例如：
--查询 ID 为 1 或 2 的老师教授的课程
EXPLAIN SELECT cr.cname FROM (SELECT * FROM course WHERE tid = 1UNIONSELECT * FROM course WHERE tid = 2 ) cr;

在这里插入图片描述

对于关联查询，先执行右边的 table（UNION），再执行左边的 table，类型是DERIVED。

• UNION

用到了 UNION 查询。同上例。

• UNION RESULT

主要是显示哪些表之间存在 UNION 查询。<union2,3>代表 id=2 和 id=3 的查询存在 UNION。同上例。

type 连接类型

https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-join-types

所有的连接类型中，上面的最好，越往下越差。

在常用的链接类型中：system > const > eq_ref > ref > range > index > all

这 里 并 没 有 列 举 全 部 （ 其 他 ： fulltext 、 ref_or_null 、 index_merger 、unique_subquery、index_subquery）。

以上访问类型除了 all，都能用到索引。

• const

主键索引或者唯一索引，只能查到一条数据的 SQL。

DROP TABLE IF EXISTS single_data;
CREATE TABLE single_data(
  id int(3) PRIMARY KEY,
  content varchar(20)
);
insert into single_data values(1,'a');
EXPLAIN SELECT * FROM single_data a where id = 1;

在这里插入图片描述

• system

system 是 const 的一种特例，只有一行满足条件。例如：只有一条数据的系统表。
EXPLAIN SELECT * FROM mysql.proxies_priv;

在这里插入图片描述

• eq_ref

通常出现在多表的 join 查询，表示对于前表的每一个结果,，都只能匹配到后表的一行结果。一般是唯一性索引的查询（UNIQUE 或 PRIMARY KEY）。

eq_ref 是除 const 之外最好的访问类型。

先删除 teacher 表中多余的数据，teacher_contact 有 3 条数据，teacher 表有 3 条数据。

DELETE FROM teacher where tid in (4,5,6);
commit;

--备份
INSERT INTO `teacher` VALUES (4, 'james', 4);
INSERT INTO `teacher` VALUES (5, 'tom', 5);
INSERT INTO `teacher` VALUES (6, 'seven', 6);
commit;

为 teacher_contact 表的 tcid（第一个字段）创建主键索引。
--ALTER TABLE teacher_contact DROP PRIMARY KEY; ALTER TABLE teacher_contact ADD PRIMARY KEY(tcid);
为teacher 表的 tcid（第三个字段）创建普通索引。
--ALTER TABLE teacher DROP INDEX idx_tcid; ALTER TABLE teacher ADD INDEX idx_tcid (tcid);
执行以下 SQL 语句：
select t.tcid from teacher t,teacher_contact tc where t.tcid = tc.tcid;

在这里插入图片描述

此时的执行计划（teacher_contact 表是 eq_ref）：

在这里插入图片描述

小结：

以上三种 system，const，eq_ref，都是可遇而不可求的，基本上很难优化到这个状态。

• ref

查询用到了非唯一性索引，或者关联操作只使用了索引的最左前缀。
例如：使用 tcid 上的普通索引查询：
explain SELECT * FROM teacher where tcid = 3;

在这里插入图片描述

• range

索引范围扫描。
如果 where 后面是 between and 或 <或 > 或 >= 或 <=或 in 这些，type 类型就为 range。
不走索引一定是全表扫描（ALL），所以先加上普通索引。
--ALTER TABLE teacher DROP INDEX idx_tid; ALTER TABLE teacher ADD INDEX idx_tid (tid);
执行范围查询（字段上有普通索引）：
EXPLAIN SELECT * FROM teacher t WHERE t.tid <3;
--或
EXPLAIN SELECT * FROM teacher t WHERE tid BETWEEN 1 AND 2;

在这里插入图片描述

IN 查询也是 range（字段有主键索引）
EXPLAIN SELECT * FROM teacher_contact t WHERE tcid in (1,2,3);

在这里插入图片描述

• index

Full Index Scan，查询全部索引中的数据（比不走索引要快）。
EXPLAIN SELECT tid FROM teacher;

在这里插入图片描述

• all

Full Table Scan，如果没有索引或者没有用到索引，type 就是 ALL。代表全表扫描。

• NULL

不用访问表或者索引就能得到结果，例如：
EXPLAIN select 1 from dual where 1=1;

小结：

一般来说，需要保证查询至少达到 range 级别，最好能达到 ref。

ALL（全表扫描）和 index（查询全部索引）都是需要优化的。

possible_key、key

可能用到的索引和实际用到的索引。如果是 NULL 就代表没有用到索引。 possible_key 可以有一个或者多个，可能用到索引不代表一定用到索引。反过来，possible_key 为空，key 可能有值吗？表上创建联合索引：

ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

执行计划（改成 select name 也能用到索引）：

explain select phone from user_innodb where phone='126';

在这里插入图片描述

结论：是有可能的（这里是覆盖索引的情况）。

如果通过分析发现没有用到索引，就要检查 SQL 或者创建索引。

key_len

索引的长度（使用的字节数）。跟索引字段的类型、长度有关。

rows

MySQL 认为扫描多少行才能返回请求的数据，是一个预估值。一般来说行数越少越好。

filtered

这个字段表示存储引擎返回的数据在 server 层过滤后，剩下多少满足查询的记录数量的比例，它是一个百分比。

ref

使用哪个列或者常数和索引一起从表中筛选数据。

Extra

执行计划给出的额外的信息说明。

using index

用到了覆盖索引，不需要回表。

EXPLAIN SELECT tid FROM teacher ;

using where

使用了 where 过滤，表示存储引擎返回的记录并不是所有的都满足查询条件，需要在 server 层进行过滤（跟是否使用索引没有关系）。

EXPLAIN select * from user_innodb where phone ='13866667777';

在这里插入图片描述

Using index condition（索引条件下推）

索引下推，在前面的文章中已经讲解过了。

https://dev.mysql.com/doc/refman/5.7/en/index-condition-pushdown-optimization.html

using filesort

不能使用索引来排序，用到了额外的排序（跟磁盘或文件没有关系）。需要优化。（复合索引的前提）

ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);

EXPLAIN select * from user_innodb where name ='青山' order by id;

（order by id 引起）

在这里插入图片描述

using temporary

用到了临时表。例如（以下不是全部的情况）：

1、distinct 非索引列

EXPLAIN select DISTINCT(tid) from teacher t;

2、group by 非索引列

EXPLAIN select tname from teacher group by tname;

3、使用 join 的时候，group 任意列

EXPLAIN select t.tid from teacher t join course c on t.tid = c.tid group by t.tid;

需要优化，例如创建复合索引。

总结一下：

模拟优化器执行 SQL 查询语句的过程，来知道 MySQL 是怎么处理一条 SQL 语句的。

通过这种方式我们可以分析语句或者表的性能瓶颈。

分析出问题之后，就是对 SQL 语句的具体优化。

比如怎么用到索引，怎么减少锁的阻塞等待，在前面两次课已经讲过。

SQL 与索引优化

当我们的 SQL 语句比较复杂，有多个关联和子查询的时候，就要分析 SQL 语句有没有改写的方法。

举个简单的例子，一模一样的数据：

--大偏移量的 limit

select * from user_innodb limit 900000,10;

--改成先过滤 ID，再 limit

SELECT * FROM user_innodb WHERE id >= 900000 LIMIT 10;

对于具体的 SQL 语句的优化，MySQL 官网也提供了很多建议，这个是我们在分析具体的 SQL 语句的时候需要注意的，也是大家在以后的工作里面要去慢慢地积累的（这里我们就不一一地分析了）。

https://dev.mysql.com/doc/refman/5.7/en/optimization.html

存储引擎

存储引擎的选择

为不同的业务表选择不同的存储引擎，例如：查询插入操作多的业务表，用 MyISAM。

临时数据用 Memeroy。常规的并发大更新多的表用 InnoDB。

分区或者分表

分区不推荐。

交易历史表：在年底为下一年度建立 12 个分区，每个月一个分区。

渠道交易表：分成当日表；当月表；历史表，历史表再做分区。

字段定义

原则：使用可以正确存储数据的最小数据类型。

为每一列选择合适的字段类型：

整数类型

在这里插入图片描述

INT 有 8 种类型，不同的类型的最大存储范围是不一样的。

性别？用 TINYINT，因为 ENUM 也是整型存储。

字符类型

变长情况下，varchar 更节省空间，但是对于 varchar 字段，需要一个字节来记录长度。

固定长度的用 char，不要用 varchar。

非空

非空字段尽量定义成 NOT NULL，提供默认值，或者使用特殊值、空串代替 null。

NULL 类型的存储、优化、使用都会存在问题。

不要用外键、触发器、视图

降低了可读性；

影响数据库性能，应该把把计算的事情交给程序，数据库专心做存储；

数据的完整性应该在程序中检查。

大文件存储

不要用数据库存储图片（比如 base64 编码）或者大文件；

把文件放在 NAS 上，数据库只需要存储 URI（相对路径），在应用中配置 NAS 服务器地址。

表拆分

将不常用的字段拆分出去，避免列数过多和数据量过大。

比如在业务系统中，要记录所有接收和发送的消息，这个消息是 XML 格式的，用 blob 或者 text 存储，用来追踪和判断重复，可以建立一张表专门用来存储报文。

后话

MySQL 专题到这个篇章就正式结束了，基本上是按照脑图的方向来，所以大家可以对着脑图以及我的博文来进行 MySQL 的复习，基本上面试的问题都有涉及，编写一个专题确实是费脑又费精力费时间的事情，我还是需要大家的关注和点赞来支撑一下哈哈哈~

如果大家觉得写得还有点东西的话帮忙关注一下我的公众号，并且在后台给我留言希望我写哪个专题的东西（现学现卖的如果有什么不对的地方也请帮忙指正，万分感谢），人多的话马上安排上~

还是那样，修整一段时间后会先在公众号推送脑图，然后根据脑图来拟专题的提纲，这样我写得不会云里雾里，大家也会比较有方向地看我的博文，再次感谢大家的支持~

By the way

有问题？可以给我留言或私聊
有收获？那就顺手点个赞呗~

当然，也可以到我的公众号下「6曦轩」，

回复“学习”，即可领取一份
【Java工程师进阶架构师的视频教程】~

回复“面试”，可以获得：
【本人呕心沥血整理的 Java 面试题】

回复“MySQL脑图”，可以获得
【MySQL 知识点梳理高清脑图】

由于我咧，科班出身的程序员，php，Android以及硬件方面都做过，不过最后还是选择专注于做 Java，所以有啥问题可以到公众号提问讨论（技术情感倾诉都可以哈哈哈），看到的话会尽快回复，希望可以跟大家共同学习进步，关于服务端架构，Java 核心知识解析，职业生涯，面试总结等文章会不定期坚持推送输出，欢迎大家关注~~~

在这里插入图片描述