大家好，我是二哥呀。
昨天有位前同事找我吐槽说：“害，对一位下属推心置腹，把他作为嫡系培养，结果他在偷偷面试却不告诉我，瞬间觉得自己的用心都被白费了。”
我安慰他说，别这样兄弟，人家面试可能只是对公司不满意，对事不对人。
你的一番好意，他肯定是知道的，也会怀着感恩的心态在未来的某一刻回报你，相信我，你绝对是他在职业生涯中为数不多的伯乐之一。
我当初离开公司也不是因为对咱们领导有任何不满，只是需要换个城市工作，迫不得已，这事你也知道。
想开一点。
天底下没有不散的宴席，有时候默默的离开，反而对你和他都有好处。
他找到一份更好的工作，以后你也想跳槽的时候，他肯定也会毫不犹豫的出手内推。
就像咱们，已经“分手”这么多年了，不是有事没事都会聊一嘴嘛（🤣）。
就这样你一嘴我一嘴，聊了快一个小时，前同事也释怀了。
我也一直给大家强调，
面试期间能保密尽量保密，不仅 leader 不能讲，最好同事也不要讲，等一切都尘埃落定了，再透露出风声
。
道理很简单，你提前和 leader 说了，他可能觉得这么认真在培养你，你怎么还不懂得感恩，还要去看外面的风景。
提前和同事说了，如果他是那种铁哥们，那没什么。但如果并不是你想象中的那么铁，给你背刺一下，受不了的。
最坏的情况就是你面试结果不理想，这边的工作也不受重视了，很有可能年底绩效就背 C 了，两方面受挫。
作为一名牛马打工人，一份相对满意的工作不容易，不要轻易毁了它。
工作党跳槽的话，建议直接上手做项目，在做项目的过程中去补充基础知识。
假如我们来制定一个短期的 3 个月学习计划吧。
第一个月，复盘之前做过的项目，尤其是量化数据，记得扒拉下来写到简历上。
然后沉淀一套自己的知识库模板，把项目中可能涉及到的知识库串讲一遍，做到心中有数。
第二个月，假如你还没有微服务的开发经验，那可以学一下 PmHub，代码也是完全开源的。
涉及到 Redis 缓存、RocketMQ 消息队列、Docker 容器化、Jenkins 自动化部署、Spring Security 安全框架、Nacos 服务注册和发现、Sentinel 熔断限流、Seata 分布式事务、Spring Boot Actuator 服务监控、SkyWalking 链路追踪、OpenFeign 服务调用等等。
深入代码，借助阿里的通义灵码、字节的 MarsCode 等等，系统化的学习。
第三个月，开始背八股（大厂的话就附件上算法这一趴），把面渣逆袭上高频的题目过一遍，然后和公司的项目、微服务 PmHub 项目结合起来，形成一套自己的口述表达。
不要怕，大多数工作党都是 SQL boy 和 CURD boy，甚至技术还不如校招时期。
相信你一定能行，给自己一个机会，偷偷面一次试试水。
三分恶面渣逆袭
JOIN 代替子查询有什么好处？
第一，JOIN 的 ON 条件能更直接地触发索引，而子查询可能因嵌套导致索引失效。
第二，JOIN 的一次连接操作替代了子查询的多次重复执行，尤其在大数据量的情况下性能差异明显。
----这部分是帮助大家理解 start，面试中可不背----
比如说我们有两个表 orders 和 customers。
CREATE TABLE orders (
order_id INT PRIMARY KEY,
customer_id INT,
amount DECIMAL(10,2),
INDEX idx_customer_id (customer_id) -- customer_id字段有索引
);
CREATE TABLE customers (
customer_id INT PRIMARY KEY,
name VARCHAR(100)
);
子查询的写法：
SELECT o.order_id, o.amount,
(SELECT c.name
FROM customers c
WHERE c.customer_id = o.customer_id) AS customer_name
FROM orders o;
JOIN 的写法：
SELECT o.order_id, o.amount, c.name AS customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id;
|
|
|
|
|
|
内层子查询
WHERE c.customer_id = o.customer_id
每次执行时，可能无法直接利用 orders 表的 customer_id 索引。
|
JOIN 的 ON 条件
o.customer_id = c.customer_id
可以直接利用 orders 的 idx_customer_id 索引，加速连接过程。
|
|
|
子查询会被重复执行（每次外层 orders 行都会触发一次子查询），导致全表扫描。
|
优化器可能选择通过索引快速关联两张表，减少数据扫描量。例如，先通过 orders 的索引找到 customer_id，再与 customers 主键快速匹配。
|
|
|
当 orders 表数据量大时，子查询可能因重复执行导致性能急剧下降。
|
JOIN 的一次连接操作通常更高效，尤其在大数据量时。
|
对于子查询，执行流程是这样的：
-
外层 orders 表的每一行都会触发一次子查询。
-
如果 orders 表有 1000 条记录，则子查询会执行 1000 次。
-
每次子查询都需要单独查询 customers 表（即使 customer_id 相同）。
而 JOIN 的执行流程是这样的：
-
-
通过索引（如 orders.customer_id 和 customers.customer_id）快速关联数据。
-
来看一下子查询的执行计划：
EXPLAIN SELECT o.order_id,
(SELECT c.name FROM customers c WHERE c.customer_id = o.customer_id)
FROM orders o;
二哥的 Java 进阶之路：子查询的执行计划
子查询（DEPENDENT SUBQUERY）类型表明其依赖外层查询的每一行，导致重复执行。
再对比看一下 JOIN 的执行计划：
EXPLAIN SELECT o.order_id,
(SELECT c.name FROM customers c WHERE c.customer_id = o.customer_id)
FROM orders o;
二哥的 Java 进阶之路：JOIN 的执行计划
JOIN 通过 eq_ref 类型直接利用主键（customers.customer_id）快速关联，减少扫描次数。
----这部分是帮助大家理解 end，面试中可不背----
ending
一个人可以走得很快，但一群人才能走得更远。
二哥的编程星球
已经有 7800 多名球友加入了，如果你也需要一个良好的学习环境，
戳链接 🔗
加入我们吧。这是一个
编程学习指南 + Java 项目实战 + LeetCode 刷题
+
简历精修
的私密圈子，你可以阅读星球专栏、向二哥提问、帮你制定学习计划、和球友一起打卡成长。
两个置顶帖「球友必看」和「知识图谱」里已经沉淀了非常多优质的学习资源，
相信能帮助你走的更快、更稳、更远
。
欢迎点击左下角
阅读原文
了解二哥的编程星球，这可能是你学习求职路上最有含金量的一次点击。
最后，把二哥的座右铭送给大家：
没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟
。共勉 💪。
