@lldld 试了，原来顺序是先 user 先 join 订单表 order 再 join 日志表 log，3.5 秒，顺序调整了一下，返回结果行数一致，时间变成 1.5 秒。
Good ！！！

@zhzy0077 大神大神，搜了一下 tp 和 ap，的确是这样的，我的场景下慢不是不能接受的，但是我一开始 sql 怎么写也不确定，问一下也是怕自己错误导致的那种慢

午休回来，感谢各位的回复，我早上也查资料并尝试，简单总结一下：
1. 可以的话，尽量是保存到到单表，用索引，这样最快；
2. 确定要用到 join 的，用小表驱动大表；这个还有个技巧，就是小表不仅指总行数小的表，如果可以用 where 筛选减少行数，时间也是会降低的。
3. 和 2 类似，join 的时候会生成临时表，用 on 过滤条件应该能减少临时表的行数？这个和 @nonoyang 说的不一样，我还没弄懂。
4. 我本意是问 join 有没有其他写法的，看到有些文章建议不用 join 而是把 sql 拆成多条语句，但那种业务场景和我的不一样（比如查一个用户有多少订单，这个是可以拆成两个 sql ）；我就没想到我的场景下可以怎么拆（或者说有没有其他不用 join 的写法），现在结论应该是我的场景是可以用 join 的（而且结果不是给前端实用，没有要求一定要几秒完成查询）。

@harde 懂你的意思。user 表有会员标记，但是没有过期时间，而且订单更新的时候也没有更新会员状态；更麻烦是订单表现在数据也不全（只保留了最新的订单）；我们后面计划是先去改造订单表。但现在需求实现依赖已有的表结构，显得很奇怪。

感谢回复！

@cedoo22 实际上 user 表是有会员标志的，但是过期了没有更新，而且现在订单表也有问题（只保存最新的订单）；后续判断还可能扩展，有些字段可以考虑放到一个 user 表，但多个表 join 无法避免了（需求还可能加入其他表的条件来判断）。
@jtwor 这个说的应该是让 user 表的结果行数先减少？我试了增加 where 条件过滤 user 表，时间的确降下来了（ 4 秒），也在往这个方向试。最终结果不是给前端展示的，而是生成文件保存下来，所以分页了总时间还是在的

@zzfer 你说的有道理，不过需求就包括不同的条件，比如还可能要最近 10 天启动了 3 次以上的用户，这个就要关联了。因为给的是简化版，有些字段我的确已经放到了 user 表

@nonoyang ‘这个是筛选条件，并非关联条件。where 条件和是不是主表字段没关系’
我刚刚的说法应该不准确，应该是 where 过滤的是最终的字段（ select 的结果字段），我理解放到 on，可以判断 join 的时候就直接过滤了，不需要把结果再放到最后 where 的时候再判断，只有应该快一点？

@nonoyang “其次 log.createdAt > '2021-10-01 00:00:00' 应该放在 where 里面”
这个原因是？我看了 join on 条件 where 都区别，log.createdAt 这个条件属于 join on 的表的，我理解应该放在这里；属于 user 表的才放在 where （我这个场景下）

@harde 订单里面我加一个 expireTime，超过这个时间就表示过期。比如买了一个月会员，一个月后就过期了
@Martin9 这个我也看资料也是这样说的（连接字段上加索引），不过我试了一下，增加前后时间都差不多 15 秒
@nonoyang 现在最新订单会覆盖会覆盖旧的订单（就是只有一个订单），我们也在计划修改这个，把所有历史订单都存下来

试一下冥想（闭目养神）

广州的房东怎么都装修啊...
直接走街串巷看, 我的经验是手写的一般是一手房东. 还有二手房东. 中介一般网上遇到多.
不出钱只能出力, 多逛几圈打几个电话, 看一下. 一般不是本楼的就不要去了, 不知道多远. 这个好处是可以在想要的地方找到房子, 不过累一点.

兴趣转移了而已...我近来老想着买个钓竿去学钓鱼, 周六看到江边钓鱼贼有意思

认知是有误差的.
你以为面试低端岗位的是: 科班出生基础扎实也许太深的不懂干活也不行但是值得培养的好苗子
实际上来面试的是: 三个月培训会套框架也许还能干活但是不懂原理也不敢说三年经验的老实人

@mmrx PUA，全称“Pick-up Artist”，原意是指“搭讪艺术家”. 这点上应该不符合.
现在许多人按内核理解"打一打再揉一揉就"是 PUA. 这个看个人理解.
更多的, 我倾向至少要这个领导知不知道自己是在"PUA"? 我觉得领导可能都不知道这几个字母什么意思.

哪个领导不是人精? 可能我接触的领导段位比较低

我觉得不要什么都往 PUA 上扯, 大部分领导都没那水平. 如果你觉得说话让你难受了又圆回来, 理解对方就是说话水平 la 低 ji, 不过后面看了你脸色不好又说几句好话而已.
只要没有炒了你, 你在当前岗位的工作能力就没问题. 反证法证明这个很容易.

朴素的善良...
我建议先让自己"失业", 然后"降薪".
告诉家人自己失业了, 等几个月换一个"低一点"的工作, 实际薪资就不要告诉家人朋友了.
把自己位置摆低一点, 也许更容易谈, 这也能顺便了解父母的用途. 直接说不想给或问用途, 关系容易爆炸.

最近几次要下载都不行, 看到这个帖子后又重新试了一下. 最后解决的方法是参考这个帖子, https://www.v2ex.com/t/696735 用 ApkPure 更新了 Google Play, 可以正常下载了

需要指出一个误区, 许多人都注意到做菜的被说菜不好吃容易暴走, 但是不要以为这个是因为煮菜付出的劳动得不到认可, 后面还要隐藏的线.
偶尔煮一顿菜, 重点在"煮", 但是每天都煮菜, 选择 /决定每天吃什么菜, 怎么搭配是一件很消耗的事, 而且很容易陷入"无解"的境地. 比如说肉, 鸡鸭鱼肉四种, 每天一个四天就得重复一轮, 就算你加上虾蟹腊肉也只能稍缓一轮. 一个月下来, 买菜就足够消耗精力了. 新的菜式是需要学习的, 也就是说, 家常菜要做到每天有花样, 基本就是 996 的活.
就算你是发工资的老板, 也要被怼. 何况只是一洗碗打下手的?

如果你觉得"独处"利大于弊, 那就开开心心接受弊;
如果你觉得"独处"弊大于利, 那就想一下改变.
如果只是夜里"独处"失眠瞎想, 建议找方法解决自己的失眠.

利益相关:
喜欢独处, 也沉默寡言. 但是周末回家带娃出门娃看到随便一个人都有兴趣, 还带着我穿了门(知道但是从来没去过不怎么熟的阿姨家), 发现带娃才是第一交际力, 只要是都带娃, 不管年龄性别兴趣爱好都能聊几句.

@exc 用硬编码理解 Root 权限应该是不准确的，更应该把 Root 看做一个协议。
在需求上，既然能明确分权限是有意义的，那么把总的权限命名为 Root 还是 Admin 还是其他，都是偏好而已。把初始化交给用户，是一种选择。默认初始化为 Root，也是一种商定好的协议。