现在的那些大牛里，初高中没有玩过编程，大学才起步的人多，还是初高中已经开始入门，到了大学开始深造的人多？

入门语言，放在以前的话无脑 Pascal，现在的话可以从 Python 或者 Ruby 起手，基础学扎实以后开始学 C 。

C++可以稍微碰一下，搞点基础的 STL 玩玩，但是不要钻得太深。
这玩意儿无底洞，给你十年都不见得能玩得顺风顺水。

这配置耗电又不大…插满硬盘以后硬盘耗电比平台耗电还高呢…

@sarvatathagata 按位或还是挺难优化的，要消除运算量必然要加入分支，而现代处理器上跑分支并不见得更快，所以很大可能编译器不会去尝试这些不会提速的优化。

都写了 safe 了，防止侧信道攻击当然要完整对比完了。

@tesorouo #3
每一次替换操作的时间复杂度是 logm，这里 m 相当于是题目给定的数字，算是常量，所以 logm 也是常量。
n+nlogm 的复杂度就等于是 O(n)了。

@Daath 1060 按理是能支持 8K 回放的，至于为什么只有 1080P，你可能需要自己折腾一下，比如装个新驱动或者装个 Windows 10 试试。

小顶堆？

chrome://gpu/

一路往下翻到 Video Acceleration Information 看看你那边写的是什么？

刚刚用 Chrome 跑了一下 4K，完美支持。CPU 5%，显卡 60%。

是不是你显卡太弱了所以浏览器放弃了？

> 可以再买两块 2T

现在你可能很难买到非 SMR 的 2T 了。

只看标题就知道是 ballooning 。
这东西开着一般也不影响什么，反正虚拟机里跑程序的时候宿主会把内存还回去的。

你可以尝试 dd 硬盘。不过先提醒一句，正版换成盗版是违法行为。

这功能多少年之前就实现了。文件系统实现过，数据库实现过，说简单点你直接 MySQL InnoDB 上开个事务就行了，断电的时候下次启动自动滚回去。

「就是某些人写个百科，发个分享就直接复制粘贴」
都复制粘贴了为什么要怪网站呢，人家明明就支持短链直达的。

至于埋点为什么要放在 URL，当然是因为不放白不放啊。URL 本来就是 URL，能到达资源就行了，设计出 URL 这个功能的人也没把美观作为卖点。

你说目标页面加载完提交，怎么提交？不得用 JavaScript 吗。
你能保证用户的 JavaScript 就一定开着而且一定会运行？
以前做统计还有一种是用一个透明像素点来做，然而你也不能保证浏览器一定会加载这个像素点。

@dawniii 更换技术栈一样有学习成本和招人成本。NoSQL 也不是就没缺点的。对很多公司来说，这种折中的操作更方便。

像我们写 Rails 的其实只需要操作上层模型就行了，下层 ORM 会自动选用 join 或者单句查询，你改成 NoSQL 的话很多现成的工具都没法用，又要重新做技术储备，重新找类库，甚至重新写组件，我觉得没有太大的优势。

@dawniii 几百 GB 的数据表，做过滤查询的时候只查出一部分不是很正常吗？
如果你用 JOIN，能保证充分利用索引做高速连接，我觉得是没有问题的。
不过这里主要讨论的是不做连接的时候性能会受到多大影响的问题。
实际开发环境中有很多查询，在使用 JOIN 时无法充分利用索引，或者至少 MySQL 会比较笨不去用索引，这种时候做简单查询然后手动去处理，可能会比依赖数据库内部查询优化速度更快一些。毕竟查询优化并不一定能洞悉你最终的意图，并不一定能给出最佳的查询计划。

楼上#187 里也举了很多相关的例子，提到的这些其实也就是我们上面提到的，服务器更容易扩展，更容易利用查询缓存，减少锁等等。我个人并不反对使用简单的 JOIN 查询，但是对于应用层简单而数据库层复杂的查询，我是绝对会放在应用层做的。

冒号前面是 key 冒号后面是 value，你再帮他说一遍，你等于……（走错片场了

一般用 2 就行了，如果 key 重复的话也可以用[[k1, v1], [k2, v2]]这样的结构。

@hackingwu #173 你说得没错，很多公司写项目是提前考虑读写分离数据延迟的。
但是反过来看，没有提前考虑数据延迟的项目，在遇到数据库瓶颈的时候就要抓瞎了，得返工回去重新做结构。
这种把数据库当 KV 表的做法，可以看成是缓解数据库瓶颈的「另一种」做法。

@dawniii 所以你还是没说为什么呀。
「然后要在内存里组装一个巨大的 sql 出来吗」
所以就让数据库在内存里组装两个巨大的 joined dataset 出来吗？
一个 ID 撑死也就几字节，几万个 ID 也就占用巨大的几十 KB 内存。
几百 GB 的数据表，几十 MB 的索引，放在数据库内存里组装数据集你一点不心疼，几十 KB 反倒是那么心疼？

「如果数据量更大呢」
如果数据量更大，你会发现 MySQL 做 JOIN 或者子查询会更慢……

子查询也好，JOIN 也好，能用上索引和查询缓存的情况只会比单句查询更少。如果是 Oracle 或者 Postges 这些质量比较高的数据库引擎，可能还靠谱点。如果是 MySQL，放在几年前，你查询稍稍写偏一点，或者索引建得让引擎不舒服了，立马 扫·全·表。现在其实也没好到哪里去，但是因为 MySQL 本身速度还挺快的，所以扫全表就扫全表吧，眼不见为净了。