手痛：
热水泡可以缓解，用针灸按摩仪，两三次就好

肩膀酸：
椅子高度和桌子不匹配，手打字时不要悬在半空，长期肌肉紧张。按摩仪可以缓解，但是优先解决桌、（主要）椅子高度问题

@syc001
@thqw0925
感谢。在一个知乎帖子里看到推荐三星 970 的，发给行政了。收到再看怎么装

作为过来人，我觉得你需要的不是安慰，而是建议：
1. 感受一下自己的身体。我猜你应该很久没有做运动，建议做适量的运动（而不是激烈的运动），走路十几分钟这种最好，刺激一下身体。
2. 找个有目标的事情做，找个事情至少是几个月、一年的计划，让自己忙起来。该上班上班、改学习学习。
3. 学习一下冥想，感受自己的身体变化、情绪变化，感受周围的变化。

不要想着大道理，去生活，去实践。

假设两万就能多活一天，顶级富豪估计都不是病死的，全是笑死的

钻牛角尖没有必要

1. 要先知道为什么有主线程（ UI 线程），这个前提下再讨论其他问题
2. “对于这种单独起一个线程执行耗时任务，为啥耗时任务执行完的后续收尾代码( showPic )非要放到任务队列中让主线程执行，为啥不干脆在自己的线程中执行” --》把图片下载放到单独线程，就是把耗时任务从主线程摘除来。但是因为只能主线程更新 UI ，所以最后还要回到主线程刷新界面。这里经常遇到的一个问题是：下载后图片解析成 Bitmap 也是耗时的，经常遇到在主线程再解析，更好的方式是在下载线程解析。
3. “万一主线程执行很慢”--》这个万一出现了，就是要解决的问题。主线程要定时刷新页面，60 帧下刷新间隔是 16 毫秒，而且还有 90 帧、120 帧，时间要求更短，执行慢一点就掉帧。如果主线程卡一下，可能不是问题；一直卡，就是要解决的问题。正确情况下，图片的显示间隔不差这么几毫秒，要优化也是下载时间、解析时间。

@wnarutou 你的意思是墙面 10A-》公牛电线（ 10A/16A ）-〉即热 10A
你看一下公牛的面板，后面有些功率（ 2500 或 4000 ），计算公式就是 电压（ 250 ）乘以电流 10A （或 16A ）。
这个功率是按满载算的（比如电磁炉），实际上运行中很多电器不会一直满载（比如空调）。
安全性就体现在这里了，扛不住的体现就是发热，有异味。你的即热应该不是一直满载的（不然 3000W 不应该是 10A ），使用时闻到味道注意。
另外，转换头只是解决插头大小兼容问题，并不解决安全问题，10A 转 16A 还存在风险。

这里有个冗余设计问题，也就是为什么有些会烧，有些不会烧的原因。
要支持 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 的行数多，从而导致时间增加。