这里有个冗余设计问题，也就是为什么有些会烧，有些不会烧的原因。
要支持 16A ，插座从电线到面板都要支持，电线是按粗细，面板看质量。为什么有些线、面板贵，这也是一个原因，质量好，用的铜多。
重点来了，有些地方 10A 的面板，线路、面板是支持 16A 电流的，可以转换。但是如果没有。。。而且没有说明书

人际关系，最大的原因是人。比如我妈给我带娃，前年广州，现在惠州。整个小区的人都认识，顺带我交际也好一点，有点事人家也会看在我妈面子上帮一下（我觉得

jar 是 Java 的格式，Android 的依赖格式是 aar

宅家里，看电影，准备好零食、饮料
和对方说：
“看电影是吗？我之前看 XXX 电影贼好看、贼感动。电影院没得看，我下载了一起看？”
“XXX 经典电影贼好看、贼感动。电影院没得看，我下载了一起看？”
“你看过哪个电影 XXX 贼好看、贼感动。电影院没得看，我下载了一起看？”
XXX 我觉得可以是穿鞋子的猫，冰河世纪，功夫熊猫。

把 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 现在最新订单会覆盖会覆盖旧的订单（就是只有一个订单），我们也在计划修改这个，把所有历史订单都存下来

试一下冥想（闭目养神）