@SuperMild 这个暂时还没发现，不过就算有类似问题也对我影响不大，我是每天一个版本都会备份，即使少数出现问题，也问题不大，毕竟还有 nas 保障

个人隐私风险控制在本地、敏感信息、隐私照片、可能因违规而被扫描或删除的文件等，都可以安心备份
是如何实现的，有加密 /混淆机制？
我目前就是数据都放 nas 然后备份到百度云，重要数据 zip 加密压缩

这种简单功能，不想第三方就自己写代码调用 api 吧也就几行

执行力真强
不过作为一个 git 患者 想吐槽下 commit msg

用指针应该有办法判断，但并不是好办法，最好还是听楼上的意见自己处理关闭

酒路 wineflow

别搞那么多花样 SSL 是最稳的 诞生的目的就是为了解决不可信网络的可信通信
如果不支持 SSL 那就自己网络层加上公私加密 毕竟是经过全球验证的可靠通信算法

@xtf2009 难以相信会有这样大的区别，可能其他问题导致的可能性更大，磁盘 IO 性能是否同一水平，另外低版本 mysql 可能会存在索引失效的情况，如果能在同一机器重建相关表测试下可能更有说服力

所以我不放心中心化的密码管理，选择自己再次额外 encode 密码才交给第三方，虽然麻烦，但安全第一

https://github.com/del-xiong/lastpass_dopass

我也反对一楼的看法，怯场和是否有准备毫无关系，完全 2 码事,拿着演讲稿瑟瑟发抖的人可不少，而厉害的人临场发挥从来也不差，怯场我觉得主要是在心态和经验方面欠缺。
经验只能慢慢补，心态可以通过阅读一些厚黑伦书籍调整好
可以从这里的心灵鸡汤开始 https://www.ximalaya.com/qinggan/6072012/27786312
当你真正想通和理解这篇文章的中心思想，已经走出了第一步

fastapi 吗

我们单表最大就在 x 千万级，配个 1w 多的机器毫无压力，朋友的 mysql 也有在亿级使用的，不过由于特殊查询的原因，已经在考虑换数据库
如果还担心 hold 不住，直接上云，阿里 polar 入门级一年也就几千，我们也在使用感觉挺棒，感觉普通亿级数据支撑应该问题不大

可以自己维护一套连续 id 序列来优化

但是意义不大，深度分页并没有什么实际存在意义，至少目前来说我还没遇到过太有意义的场景

发现一个 clue，首页针对用户和爬虫访问做了区分展示

没有任何经验能适用任何情况，这个篮子理论应该是指在对风险了解不多不可控的情况下应分摊风险，但反之如果你对每个渠道风险都极了解可能有更好的方案
附一个案例
```
美国海军有这样一种观点，即舰队规模越小越好。这样，遭遇德国潜艇造成的损失是有限的。因此，美国海军参谋部让每个舰队分成尽可能多的编队，并按顺序出海。然而，数学家们在使用概率论分析后发现这个理论是不正确的。

舰队和敌人的潜艇可能会相遇，也可能不会相遇。这是一个随机事件。舰队布置得越多，遇到敌人的可能性就越大。因此，美国海军接受了数学家的建议，命令舰队在指定海域集合，然后集体通过危险海域，然后分别驶往指定港口。结果，运输船队沉没的概率从 25 %降低到 1 %，大大减少了损失，确保了材料的及时供应。

```

50w 总数据 即使 18w 我觉得还是偏慢了 考虑磁盘性能不足

作为对比 我测试下我这边的速度 2000w 数据表 查询 20w 记录的一个单字段 也不过才 2 秒左右

重建索引试试？低版本 mysql 有可能索引失效 bug

另外磁盘是什么型号，测试下，大概率磁盘导致

索引不正常吧 单字段查询 5 千万都不会这么慢