我觉得缩进应该尽量用于“美化代码”，而尽量不要并且最好干脆不要参与“语法结构定义”的逻辑里。

关于“新会话就是 + 1”也表示怀疑，建议再认真测试一次，在 InnoDB 引擎的表，执行“不会放图片。。。。”后面的代码块的“COMMIT”之前，再确保开了新的会话，直接执行 select （不要 for update ）,能把图贴上来，或者语句+结果文字贴上来就行。这种试验，已经给多位新入职同事科普过了。

@BeforeTooLate 阿里云还是有 https 请求次数收费的，虽然有资源包计费模式

@Abbeyok 学会了没有门路也是白学

确实很多都无用，重点不是工具，而是资源管理和资源

内容创作就行，比如来自摄影，绘画

@CRVV

我确实一直都在用 MySQL 做项目，其他数据库甚少了解。现今中小项目使用 MySQL 依然很普遍。
对关系型数据库的学习，我一直都是以“边用边学”的方式，有尝试去“系统性进阶学习”，但很难看进去（比如《高性能 MySQL 》），或者说是还没找到适合的教材、方法吧。
产品经理的需求，我觉得技术经理需要去进行平衡，当然要优先考虑实现需求，在不是 100%实现需求的情况下，实现的方式有多种。

@CRVV 如果按你说的场景并且只能局限于此，的确只能 BigQuery 了。但我还是比较好奇在实际场景中，遇到这种 BigQuery 是几乎开放式的（多用户或多进程可同时进行请求），这时候还能这么搞？（我实际项目中反而遇到很多这种用户可能会频繁访问 BigQuery 的情景）
我理解中的“分步处理”不是为了“代码比较好懂”而是为了“不让 mysql 高负荷运行复杂查询“，维护简单的 sql 查询比较容易（比如简单的索引组合，分表之类），但 BigQuery 的查询维护就变得很难把控。
在结合一些实际业务情况，我或者会考虑这些：
1 、针对查询业务做一个汇总表，并动态更新，这相当于持久化的热缓存了；
2 、尽量减少搜素条件需求，或针对搜索条件对分步查询进行调整；
3 、慎重考虑分页。分析 BigQuery 过程其实很多情况下（特别是排序），sql 已经把相关数据全部扫描了，然后我们只取部分数据（估计考虑数据传输压力到中间层），我觉得这种情况不如“不分页查询”。数据库和中间层之间数据传输压力（如 in 查询的数量限制也算是），可以尝试在分步处理的各个步骤当中再进行”分步查询“，中间层和客户端层之间的传输压力，那就甩锅给带宽吧（ nginx 已经有数据压缩传输处理了，不想管了）
总结我对 BigQuery 的使用场景是：业务量不大，且让业务快速到位。
以上，个人鄙见

@CRVV 这类的查询业务，数据量到达亿级的话，是把整个查询业务都放在 sql 呢（比如这种面试题需要一句 sql 语句得出最终结果，或窗口函数），还是多次 sql 查询分步处理好？（比如 php 或 java 先查出销量最好三个，再根据分组 id 查分组销量情况，再拼凑）

没人推荐一下网易严选？

一定几率的随机抽取国家=投胎模拟

看了同事升级后的使用，我直接定论：如果多桌面理解为是分组的话，这个所谓的前台调用无非就是分组下面的分组

想问 JetBrains 啥时候在 ipados 应用市场上个架

你以为人家卖硬件，实际人家卖服务

@PqZS58MLPBHFpEqm Referer

用了 10 年 windows+2 年 mac （算是有份量发言了吧），其实归根到底是习惯问题。当初转用 mac 的时候，我很克制自己吐槽，警醒自己是 10 年+的 win 用户，并虚心请教旁边那些老 mac 用户。现在都习惯下来了，双手神经已经记忆了两个系统的用法，所以得出结论就是习惯问题。

CRUD 没有做前端好，前端的没有做接业务好

github 的某一方面的功能

@dzdh nginx 也有 ssl 调优方案，自己搭的话也要处理这种维护。slb 估计是把这种维护都帮你想到了（但不需要文档炫耀：）