@eason1874 0 error(s)（

@guabimian 拿楼主这个例子来说，子查询是可以拿出来单独跑的。
跑出 rm.menu_id list 以后，再做一个 m.id in (#{list})。
前者因为可以做查询缓存或者应用层缓存，只要 role 表不经常改变的话，可以减少很多无谓的查询。

@liprais 对，无非是让数据库保证一致性，还是自己重新发明一遍一致性的问题。
对于大多数应用来说，会话之间不需要保证一致性，所以靠多开应用服务器（以及在单台机器上多开线程和进程）来提升运行速度。
如果有特殊需要，那当然特殊处理，所以银行、电信那些项目都有他们自己的特殊癖好，弄个大机，搞个 Oracle 之类的扛着，这个就不多说了。

你的消费是跟着你的资产水平走的。
如果你银行存款只有一万，那你奢侈点也就是出去吃个自助火锅或者唱个 K 。
但是如果你银行存款有一千万，那你的娱乐可能就是买张机票去拉斯儿维加斯儿或者马尔代夫找个五星级宾馆待上两星期。
不是说有了一千万存款你就可以花一千年了。

FIRE 有很多不同的标准，但一般是指日常开销可以基本不需要关心价格，比如说小孩可以随便上私立学校或者有条件直接送出国读书；比如想去度假了直接打电话让秘书帮你订一个旅行计划，拎包出游，飞商务舱，睡五星级；看到喜欢的保时捷可以直接付款开回家，等等。

按照这个水准来看，一千万应该是不够的。

@chenyu8674 随遇而安的富人，开销是摆在那里的。他们不追求奢侈品，不代表他们不实际去消费奢侈品，而是可能他们对奢侈品已经没有我们对奢侈品的那种感觉了。他们买一块苹果抹布，可能比我们淘宝上买一包 9 块 9 的抹布还要随意。他们想买手提包的时候，可能就是走出小区，右转走进店里，随便挑一个几千美元的包就背走了。不是每一个富人都想要给自己的包镶满钻，但这不意味着他们的包就会便宜。

@felixcode 不是所有的数据库都能在 LEFT JOIN 和子查询上做到最高性能。
比如以前 MySQL 在子查询上的性能就稀烂，像楼主贴的这段代码，放在以前就可能会去扫全表导致性能低。
反而是合理拆分查询才能更高效率利用上缓存，同时避免稀烂的查询执行器扫全表。

当然我也不是说无脑拆，至少是要看过查询计划以后，有理有据地去拆，去改写。
除非楼主家用的 Oracle 或者 MSSQL 之类的企业级软件，什么查询喂进去都能跑的，那另当别论。

@smallparking 确实有分布式数据库，但是数据库要保证 ACID 还要做分布式，复杂性会高很多。
比如说做大型数据仓库，hadoop 或者 bigtable 就可以搞定，但是如果你要把 MySQL 搞成分布式（比如 galera 多主）你就会发现开发和运维难度直线上升。（这里开发主要指 MySQL/galera 平台开发。）你说的 GreenPlum 我没有看，但是我想，像这些方案，背后还是会有大量的开发成本，运行起来还是会有一定的非线性损耗惩罚。

但是应用服务器做横向扩展却很简单，堆一打机器，对着数据库干就是了，几乎是零惩罚的。
（比如堆 100 台机器就能有近乎 100 倍的性能。）

归根结底，技术选型还是要考虑到人力和机器成本。只要你高兴，HTML 和 CSS 都能写在存储过程里。但是不同的做法之间，消耗的人力成本完全不同。不仅仅是开发成本和运行成本，还有招人成本，学习成本，测试成本，维护成本，二次开发成本等等。

「加密」必然是双向的。
「单向」必然不是加密解密。这种叫做 Hash 哈希（或者摘要）。

加密不会丢失信息，哈希一定会丢失信息，而且大多数时候哈希都会导致碰撞（但是碰撞的几率很小）。
如果用空间比较大的哈希算法，比如 SHA256 这样的算法去处理电话号码，一般不会产生碰撞，因为空间差距太大了。

不过，「保证不同的内容加密结果不一样」，就意味着可以产生一对一映射，就意味着可以反推出原始内容。

遇到这种写法，我觉得最主要就提 3 个问题。
1. 这么写以后团队里是否有复数人有能力修改。公交车因素是很重要的，如果团队里只有一个人有能力这么写，就不能这么写。
2. 数据库是否需要横向扩展。应用服务器从 1 台变成 1000 台是比较容易的，数据库服务器从 1 台变成 2 台都比较难。这种结构能不能支撑以后的规模扩展？
3. 自动化测试能不能保证。大家都知道，自动化测试可以大幅减少工作量，降低加班时间和炸锅几率。超长 SQL 能否用足够的测试去覆盖各种情况？如果不可以，那么拆分成应用层逻辑就是值得的。我觉得存储过程不是很大的问题，但是存储过程也应该可自动化测试才行。

简单说就是，用=赋值的，就要用==来判断。
用 memcpy 复制的，采用 memcpy 来判断吧？

@pxx 跑一下 memtest ，又或者是如果有多条内存的话一次只插一条。

@retanoj 数据集最大就 100 个数字，再怎么说也不会很慢的。
但是算法从大往小跑，找到解的时间比较容易提前。

@retanoj 对，感觉会稍微快一点点。跑 leetcode 测试集，1036 ms → 480 ms 。

我们是公司内网认证以后进两层堡垒机连到服务器上。

犯傻了，Set 不需要分开记录，全合到一起就行了。改成一个 Set 以后就 AC 了。
答案更新在上面了。要看犯傻答案可以去看 Gist 提交记录。

https://gist.github.com/msg7086/744d4cf2d81b42e27cb73069ecff939d

随便写了一下，结果应该是对的，就是跑太慢了，一个大点的输入就要跑 0.1 秒，leetcode 上妥妥的 TLE 。

@pxx 测试一下内存坏点。

@dingwen07 但是你的设备并不是只有浏览器。而且浏览器不支持的原因就是专利授权。
在专利授权限制的条件下，当然只能找免费授权专利的编码，任凭 HEVC 质量再好也只能选 VP9 之流。

（反正真关心画质的人，也不会去靠网络串流。）

宝塔的技术人员懂的可能还没你多。

说个差不多的事情。之前给我装宽带的大哥，拿出全新的猫，从我家里随便拉了个变压器插上了用，然后一直莫名其妙自动断电自动重启，折腾了几个小时没解决，这大哥没耐心了，拿着全新的猫的变压器出门回家了。
后来我查了一下，这个猫要用 12V2A 的变压器，大哥从我家里拿了个 1A 的插上，还把原装的 2A 变压器当垃圾带走了。