看着不错，这名字一看就挺 diao 的。
但是网址呢？

这个几乎是肯定的。我在好几年之前也听人说过这种问题。
另外用加密消息用 QQ 微信之类的一段时间，听说也有人被封。(未确认)

OP 有空可以试试控制几个变量：
1. 文件头
2. 后缀(和文件头配合或不配合)
3. 文件名

我觉得百度网盘应该会为了节约算力/时间会只检查文件头。比如你存成.zip 加上 PK 文件头，只要文件够大，他们应该不至于一个个解压。
所以 OP 可以试试，加上文件头和对应后缀后说不定可以逃过？
我没有百度网盘不方便自己测试就是。
如果楼主有兴趣的话。

挂后台听反而要求比较高。
强烈推荐 天豪公开课。偏学院派的历史主题，偶尔擦边时政。大多数时候不需要看屏幕，听就好。
英语可以的话，kurzgesagt 这些。但是缺了画面不太行。
对生物感兴趣可以听 芳斯塔芙(感觉是 B 站搬运/偷过来的)

其他基本上不看视频就听不下去。

老高经常胡扯...虽然说故事类的你听着乐就行了，但是如果讲的东西你了解，他说的又是错的，你会听着难受。

你这个需求可能更需要播客或者听书之类的。

1. 试着和摆摊的老头老太聊聊。想想话题，理解一下别人人生。
2. 有能力(财力)就出国看看，一两年能改变你很多。
3. 找个有点挑战的证书考考。你会发现你还是在某个时间段拼尽全力。没考上你会学很多，考上了那更好。

@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. 如果无法控制焦虑，非常推荐找心理医生，或者检查肾上腺是否过于活跃。