@sillydaddy 素数那个办法太好了

用加湿器，买温度和湿度计，时刻监控温度湿度。
我也有鼻炎，我发现我鼻炎貌似和相对湿度有点关系。

洗鼻子有用，但只是临时的。

躺下就鼻子堵，侧躺重力感应，朝哪里哪个鼻子就堵。早上醒来鼻子里面干的像裂了。然后疯狂打喷嚏。换季的时候能打喷嚏到鼻子出血。
从小就有这个问题，时间长了我逐渐习惯了靠着墙半坐着睡。

用加湿器有一定缓解。

好问题，我想了想，如果是更加“本土化”和抽象的概念至少按照我目前的知识水平认为这无法做到。
我不了解小说，不知道叶文洁具体发送了什么。
除非叶文洁发了大量信息，其中包含中文语言的无线电编码模式和大量中文文本。能让外星人了解中文语法结构，还用通过统计学分析出一些信息之类的。
如果只是发几个字的话应该没法理解。熵太高了。如果在这里写一个 zsgrd 你们谁能猜出是什么意思呢？(左手乱按的)

但是数字是很好被破译和理解的。比如我们可以发送一段 3.1415926535897932.....这里可以包含足够多的数字编码模式信息。还可以带上一些别的物理常量。这样可以帮助外星人了解我们的数字编码系统进而了解我们整个无线电波编码方式。

另外定位是有可能的。如果三体人已经看懂我们的数字编码系统，我们可以发送地球和 4 颗脉冲星的频率和距离，我想应该可以定位。不同的脉冲星应该有自己的频率。这样可以识别出脉冲星的特征，然后根据三维空间 4 点定位。甚至带上一些太阳系有关的数据方便验证。

当然或许也可能三体有足够精度的设备能够定位无线电波。

我之前只是想过 4 光年的距离岂不是在眼皮底下...太阳系的奥尔特云都有两光年了。可能设计为 4 光年只是为了后续剧情吧。
当然我不是那么了解这部作品就是了。

@ryan4yin 我认为你说的有道理。这种场景这么做是有意义的。送一个感谢。

摸个大鱼，写个长文。
很多人都在说：
”多次迭代 hash 很多人都在说第二次输入范围变小“。我就不一一 at 了。

@YGHMXFAL 关于多次迭代的问题我先说，多算法嵌套的问题我下文说。
我们来做一个脑内实验：
如果我们用同一个 hash 算法，进行几乎[无穷]多次迭代，那么一定会在某一次碰撞，对吧？毕竟 hash 值域空间有限。

而且，根据鸽巢原理，随着迭代次数增加，和之前迭代过程中 hash 碰撞概率也随之增加。比如迭代了 1 亿次，
这个碰撞来临的可能比我们预想的快（生日悖论）。

我们这样写：a 经过 hash 成为 b ，b 再 hash 成 c ，我们在这里写成 a->b->c

a->b->c->d->e->f->g

到此为止，一切都好。但是在下一时刻，g 经过 hash 后发生了碰撞成了[e]
于是最后这个 hash 就成了

a->b->c->d-> e->f->g-> e->f->g-> e->f->g-> e->f->g......

你会发现这个 hash 碰撞后会不可避免地陷入了一个循环。
最后结果就在 efg 这三个结果之间，实际上的值域变小。此后再多迭代次数也没有意义。我只要知道这个环里的元素 efg ，知道迭代次数，我们就可以推算出具体哪个元素可以构成碰撞。

比如上面就是 hash(a)*8=f, 我们不知道 a, 但是我们可以 8mod3=2 ，hash(g)*8=f=hash(a)*8 这样构造出碰撞。

然而对于一个健壮的 hash 算法来说出现上述情况很难，或者说你只迭代一千次一万次完全没问题。甚至就算有碰撞，这个环也可能大到难以探测。


再说组合不同算法：
假设一个不安全 hash 叫做 weak, 只输出 1 位。不是 0 就是 1.碰撞概率五五开。
你 sha-512 然后 weak ，会怎么样？碰撞概率依旧五五开。组合 hash 算法安全性取决于最差的那个 hash 。调换顺序也没用。

@gbadge 不可以替代 salt 。多次迭代会增加算力消耗没错。salt 让彩虹表无法复用，而且在空间和计算上都制造难度。
@jim9606 长度扩展攻击...可能不会让破解变得容易。至少我不知道。因为长度扩展攻击可以在我只知道 MD5(pwd)和 salt 的情况下算出 MD5(pwd+salt)但是我的确不知道怎么算 pwd 或者 MD5(pwd)...不管怎样，反正 MD5 ，SHA-1 的确就别再用了。

其他人懒得一个个回复了。

最后好好回复给 OP：
理论上：OP 的做法意义不大。虽然应该不会更不”随机“，但是安全性取决于最差的那个算法。而且只要有一个算法有问题那整个都变弱。迭代是有意义的，代价就是可以忽略的碰撞概率增加。

实际上：OP 的做法很有意义。黑客喜欢用现成的服务比如 hash 查询。黑客看到你这种骚操作很可能骂娘后直接放弃。但是弱密码依旧有可能被破解。
把黑客恶心死，也是一种安全。

多次迭代拖慢暴力，奇葩嵌套无法查询，加盐对抗彩虹表，密码策略防止弱密码对抗字典。

（所以...为什么不用 bcrypt 这些呢?）

经常看到这种争论，我平时很少在这种争论中说话。

回复 OP 一楼：理论上，对于 SHA-256 这种成熟可靠的算法，多次迭代不会有问题。实际上很多地方有在用这种做法。
回复 OP 四楼：我也同样不认为在实践中对于普通业务 https 下还前端 hash 密码有多好的安全性，除非是某些特别场景。前端加密能保护的东西太有限了。
回复 OP10 楼：是这样的。如果服务器被 pwn 那么最重要的还是数据库里的东西。该加盐的加盐就好了。

HTTPS 后前端 hash 到底保护啥了？防止 HTTPS 被破解？还是服务器那边 https 解密后的过程？如果我都拿下服务器了我为什么不注入脚本钓鱼？

我看过 11 楼在另一个帖子里自己发明的方法，是好的想法，但有点鸡肋。拔网线了意味着黑客同时也不可能嗅探到 https 流量。只能对着之前拖的库里的 hash with salt(应该有两层 salt) 干瞪眼。但是可能只有极其极端情况下才有用。其实同样的，我曾经也想过一样的问题。但是我的对策是 pwd+salt+challenge-response 。
另外纠正一下，真正对彩虹表有完全克制作用的是 salt 而不是迭代。迭代只是减缓破解速度。

实践上呢？
黑客拖库后通常不是搞什么集群 FPGA ，ASIC 暴力破解，而是直接提交给某个老牌网站批量查。
没经验的搞不出来就放弃了，有经验的会看代码，然后发现批量破解成本太高，破半天搞出几个弱密码。
一般黑客也不会劫持 web 服务软件去读用户请求，还不如上一个 xmr 矿机搞 ddos 闷声发大财(其实基本都是 bot 在做)除非你的用户价值非常非常高，高到别人愿意花多少万来专门搞你的用户。

唉，有时候禁止用户用弱密码反而可能是一个不错的方案。

@restkhz 回复我自己
我看差了，我以为是你想 50w 里捞几百几千条...
统计一年的数据这的确不是索引的事情了。

各位不要理我之前的回复。

7 秒是太离谱了。
t_order_comprehensive_coverage_IDX 组合了哪些字段？ is_collect ，pro_removal_time ？
看 explain 只用了 t_order_stats_order_id_IDX. 如果我没理解错，这基本也是在扫全表，只不过用了 order_id 的索引然后一条一条根据 where 的条件查。
顺便一问，pro_removal_time 有单独索引吗？或者作为组合索引的第一个？

没有的话试着创建一个组合索引，只索引这两个字段。pro_removal_time 放第一位,is_collect 放第二位试试。如果 explain 看他还不用这个，force index 试试。
我怕你那个优化器直接把 is_collect 当第一个筛选条件，如果绝大多数都是 1 那会不稳定。

这个内存大小应该不存在什么问题。swap 是关了的，对吧...？

这个有点钻牛角尖，个人理解，我打个比方吼：

如果有项目组(进程)，那么至少应该有一名员工在做事(执行流)。如果要有一名员工办事，那么至少应该给他一个办公桌（栈）。一个有办公桌能拿文档的能做事的员工叫做线程。

所以 OP 的问题可以当作：
项目组有自己的办公桌吗？

楼主想的是流量不大，不就一 css 吗，通常也就传输 20 到 100kB ，其实比较教科书的说法是：延迟优化。

我有一个网站。HTML+CSS+JS 总共 300kB 需要传输.
但是我的服务器在地球的另一端，有一个自己编写的脚本，30kB. 这个请求一来一回，加载时间 500ms 。
但是有另一个 CDN 上的脚本，80kB ，可是 CDN 会就近加载，只需要 30ms ，这个脚本就已经加载完成。
更大的脚本，用 CDN 加载速度却快了十几倍。
你当然希望你的 css 能更早，更快地加载完成。少看几百毫秒的白屏，让用户体验更好。
这是很多 web 实践书里（教科书）会推荐 CDN 的原因。

另一方面，带宽真的不是问题吗？
国内的 VPS 通常只有 1-4mbps 。
我的 HTML 本体 7kB 不到，但是加上 CSS 和 HTML ，就算是 4mbps 的带宽(512kB/s)，对于 300kB 需要传输的数据来说，似乎只要有用户同时访问，那么带宽就容易成瓶颈。
所以我当然会考虑，如果我只需要传输那 7kB 的 HTML 本体，剩下的将近 300kB 的 JS 和 CSS 都扔给 CDN ，带宽不足的问题是否会有很大的缓解呢？
还有，其实我的网站已经不大了。HTML+css+js 超过 512kB 的比比皆是。楼上有人提到 1mbps 的小鸡，那么 30 到 100kB 的 CSS 是否应该节约就很显而易见了，对不对？

简而言之，CSS 用 CDN 是一种可以不花钱，让响应时间快一个数量级，还能节省带宽/流量的方法。

1. 没事。
2. 少喝咖啡多睡觉。某天喝了 4 大杯咖啡后我完全理解。
3. 如果无法控制焦虑，非常推荐找心理医生，或者检查肾上腺是否过于活跃。

Badusb?
你可以淘宝上买一个人家用 Arduino 之类的做的。
笔记本的话可能硬件上需要支持 USB OTG 才行。

支持一下，嘿嘿

@asdgsdg98 是这个样子的。其实卡巴已经很严格了，WD 就更牛逼了。


@proxytoworld 也可能是我比较菜，不过我还是想解释一下为什么我说好。

你看到的这个程序只是一个加载器，只有 196kb 。真正的恶意部分不在这里。莫名其妙混淆加壳只会增大嫌疑。
本体其实是在网络上的机器码。和 0x69 按位异或(简单加密一下)，伪装成图片被它下载下来的。这个“图”有 4.5MB 。

好，那么从哪里下载下来的？沙盒分析出来了。但是你要自己逆向的话也可以。这个 URL 没有加密，但在.data 段里故意被拆分开来。应该是为了防止直接被杀软识别出程序里打开 URL 的 API 直接有对应的 URL 。编写的人应该是有经验的。

然后这个加载器会在内存里开辟一块空间，然后把解密后的机器码放进去，加执行权限，上个函数指针，而后调用。

这个开辟空间用的函数都是动态加载的，但是也没有用 LoadLibrary ，感觉挺别致的。这个技术我真不会。

那为什么一个加载器对 dingding 和 QQ 感兴趣？
这里我没有逆向出原因，但是我猜测这是为了精确攻击的一个方法。没 QQ 或者钉钉的机器可能不是他的目标，哎，我就直接把自己删了，而后退出。防止搞到处都是被人捕捉分析。毕竟免杀马要花钱的。但是不知道为什么似乎在沙箱里没被激活这个 kill switch.当然功能上我也没有继续分析了。

简单说一下那个 4.5M 的机器码吧，解密后翻转，里面东西就很丰富了。有 C2 地址，还有很多杀软的名字和路径，还有很多预先定义好的命令......甚至有一个开票软件的下载 URL ，所以不排除在成功运行后下载一款真的增值税开票软件......

顺便，那个 c2 也下了一点功夫隐藏自己。
我不想说整个攻击链的下游水平怎么样，但是我觉得这个马是可以的。算是有花心思策划过的而不是直接上个 CS 或者什么玩意儿。
我就不继续深挖了。