把 chain 的赋值去掉，改写一下容易看。这是啥写法啊，脑筋急转弯呢
```
let chain = Promise.resolve()
.then(() => {
this.project = new Project(argv.cwd);
})
.then(() => this.configureEnvironment())
.then(() => this.configureOptions())
.then(() => this.configureProperties())
.then(() => this.configureLogging())
.then(() => this.runValidations())
.then(() => this.runPreparations())
.then(() => this.runCommand())
```

win 10 蓝屏（应该前后的版本都有）有日志，记下蓝屏时间去系统找日志文件，然后找官方的日志查看工具看。再搜索错误基本就能确定问题了（问题是解决不了）
我笔记本蓝屏最后确定是独显问题，升级也没法解决。禁用掉显卡就没有出现过了。具体操作忘了

@lldld 现在的测试数据里用户表 700 万条，订单表 10 万，日志表 150 万（后面这个表会增加比较快）。
你给的先 select distinct 应该是有效的，但是和我另外用的 where 优化貌似冲突了。
因为给的表和实际不一样（我去掉了多余的字段），而且我昨天发完贴优化的时候，试了一下最后用 where 过滤 user，这样才得到 3 秒的结果（因为这里最大的耗时是 join 导致的，而且最后的 where 需要在 join 之后计算，按照 join on where 的执行顺序我理解加 where 是会在 join 之后增加更多时间）；实际是加了 where 之后结果集少了，同时时间也变少了，3 秒多；不加 where 需要大概 7 秒甚至更高；而你给的 select distinct 可以做到 5 秒，但是加上 where 后时间又涨回去了（ 7 秒）。
我猜测 where+join 可能是把 user 表的条件先做优化，减少 user 表参与 join 的行数；而用 log 做主表后这个 where 的优化没有了，而 logged 的行数已经比 user 通过 where 的行数多，从而导致时间增加。

@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, 不过后面看了你脸色不好又说几句好话而已.
只要没有炒了你, 你在当前岗位的工作能力就没问题. 反证法证明这个很容易.