从你给的 explain 图来看，走的是 [idx_orders_create_time] 索引，假设这个索引只有 create_time 这一个字段，这意味着它在底层查询实际上是这样的：

从创建时间开始降序查询，每条数据都去回表，查询是否满足条件为 [ WHERE user_id = 10 AND order_status IN ('PROCESSED') AND status = 'pending_orders' AND shop_id IN ('123456')] 的数据，捞够 20 条才停止。

某种意义上来说，跟全表扫描差不多……

@quicksand #13 这种无差别开火的面试官，一般只会问常见的八股文，像老掉牙 hashmap 什么的，其他的对方可能自己都不知道。当然这种面试体验会很差，让人感觉自己像个问答机器，还有如果遇到刻意往刁钻问 + pua 的，那就没办法了

感觉面试基本是简历上精心准备几个亮点，再根据亮点涉及到的知识去深入，最后在面试时尽量把话题往这方面引，漫无目的去背八股文，永远背不完的……

@stillsilly #259 救命，不要给我看拼音变量名……

@k9982874 是的，11 楼的答案是之前没想到的新思路，完全可行且不复杂，正是我想要的那种

感谢上述各位的讨论与回复 _(:з」∠)_

@546L5LiK6ZOt 是的，最纯粹的做法就是唯一索引，只是原先表的业务逻辑不支持……不过确实新增一个中间表就能解决，并且比起各种加锁要简单得多，操作只需要批量插入和删除，性能也只是多一两次 SQL 操作。非常感谢，这是新思路！

@k9982874 背景就是 sku 只能是商家自定义的，要原模原样，不能再在上面改东西……

@xwayway 这种操作是会同步返回结果的，从同步改成异步，这逻辑变化有点大了

@alexleee 锁店铺粒度大但只锁一个，锁 sku 粒度小但需要连续锁多个（假设按最差的情况为 200 ），我还没实际遇过连续锁这么多次只为单个商品的创建，总觉得不太对劲，这性能正常吗……

@leonshaw 对，我那个方案其实就相当于等效的加锁操作，但不确定这种单次操作中，包含了几十甚至上百次 redis 请求的性能如何

@546L5LiK6ZOt 有考虑过，但要解决该问题，锁只能加在店铺维度，粒度有点大

@hhjswf 用爬虫爬别人商品，然后批量创建到自己店铺，那个内部服务直接用多线程打过来时发现的问题……

@Chad0000 但检测数据库那里只是一条 SQL ，而这里校验时连续调用 200 次 RSet.add ，这个性能会不会有点夸张？我对这块没啥概念……

@alexleee 有考虑过，但这个锁是 SKU 维度，那加锁次数是跟 SKU 数量一致的，而商品与 SKU 是一对多的整体关系，不能说一个个 SKU 单独校验和保存，所以单个商品可能加上几十甚至上百个锁……

@kwh 自增是商品通过校验，还是 SKU 通过校验？它们是一个整体的，并且是一对多的关系……MySQL 行锁应该不行吧，问题不是保存操作，而是校验操作那里的高并发

上面这个 1 年或不到 1 年一跳，还需要看是不是连续几年都这样，如果不是连续的应该还好

当然，上面只是我个人看法，感觉如果自身技术够硬，这些也不算事……

@KedaArray 1 年或者不到 1 年一跳。
待没多久就换一家公司，代表着不稳定，从招聘和培训的成本考虑，一般会 pass 掉

大概总结了下，问题点是频繁跳槽和降薪

1 、频繁跳槽算是个简历雷点
2 、降薪后，若不跳槽就可能长时间处于该价位，基本只能靠下次跳槽来突破

至于接不接受这份工作，在自身没有经济压力的背景下，可以先思考下性价比，即从薪资、工作强度、工作时长、公司氛围、技术架构等方面，跟上家公司做一个对比，等对比完了后抿心自问，自己内心有没疙瘩，基本结果就出来了

顺带再问一下，对于空窗期，大家是怎么看的？

我在网上找了很多关于空窗期的帖子，目前有个模糊的观点，就是对于国内而言，空窗期要尽量控制在 3 个月内，因为很多 HR 在筛选简历时会过滤掉空窗期长的，认为空窗期越长，代表越不稳定，越不容易受控和压榨？

在目前这个恶劣的大环境下，感觉空窗期几个月的比比皆是，现在还会将其视作雷点吗？

@aw2350 坐标深圳，至少 4k 往上，不过并不是我面临这个抉择，只是对这块没啥认知，所以想问下大家的看法。

目前看是骑驴找马者居多，先上车再到车上跳，但频繁跳槽 + 降薪，下份想再往上跳不会更难吗？

我理解是频繁跳槽的容易在简历时就被筛，降薪再往上要则容易被卡涨薪幅度。

还是说这两点对于在职来说根本不算事，找不到就继续找，反正是在职的，只要有一家找到就行？

https://s2.loli.net/2023/02/20/nj27OqbSkJmsVAi.png
应该就跟 3 楼说的一样，因为是 Backward index scan 所以找到第一个不满足条件的不是 25 ，而是 10 （个人猜测因为是倒序的，所以这里的间隙锁应该为 (10,5] ，前开后闭区间），把排序去掉后间隙锁就是 (20,25] 了
Backward index scan 是 MySQL8.0 后才出现的，可以用 5.7 版本试试会不会一样的结果

Feign 底层实际上是 HTTP 请求的封装实现
RPC 本质上不算是协议，而是一种调用方式，并且 HTTP 协议只是 RPC 的一种实现

从群里看到截图后摸过来了，果然截图是断章取义

https://i.v2ex.co/504J5BO2.png 我怀疑你在钓鱼