等一个 mhy 杭州分部

其实你帖的那个官方回复已经解释了，只是你缺乏了一些基础知识的理解，建议看下 MySQL 技术内幕这本书里有介绍的。
当某一行存储的数据过大时，InnoDB 就不会把所有数据都存放在数据页，而是将数据存放在 Uncompressed BLOB Page 或者 Compressed BLOB Page 当中，在数据页中通过指针指向 BLOB Page，这种现象叫做行溢出。
因为 MySQL 之前的版本默认行格式都是 compact，text 场景很大概率你数据页要使用的字节数量肯定多，这样每一页可以存的行数变少，索引效率自然也低了

用 ProcessBuilder，把 sh 和 xxx.sh 作为两个参数传入即可
或者还是 RunTime 的话改成"/bin/bash", "-c", "xxx.sh"

作为规范没啥问题，做工程就是这样，不能太学院派，规范是人定的，可以根据实际需求变更。
不准用 PathVariable 最直接的原因就是访问量上去后影响匹配性能

并不是异步 IO，同步非阻塞

只有新服务能用，最关键的 jdbc 那块还是只能放到单独线程里去执行，起码要等 R2DBC 成熟了，只是用 redis 或者 mongodb 的话还是比较不错的
然后最头大的是调用链埋点，直接配套用 sleuth 还好，其他框架要集成就比较困难了

@meteor957 虽然我不是微博的，但是这块数据量大后肯定是用 Redis 集群来做，Redis 的好几种数据结构都很适合这种业务场景，而且对一致性要求不高

需要 compact，但是这个操作要谨慎，会影响业务

酷家乐了解一蛤

不过因为 httponly 其实也在 path 里，所以其实直接用 proxy_cookie_path path replacement;就可以了，这里支持变量和正则的

Nginx 只提供了改 domain 和 path 的参数，你要改 httponly 的话只能把后端返回的 response 里的 Set-Cookie 过滤掉，然后自己再根据 upstream 返回的这个 cookie 重新创建一个了

楼上也很多人说了，这个没有彻底的解决方案，jvm 特性导致
只能是想办法减少启动时间，这里主要分两块，一块是 JIT 导致的，只能像阿里那样从 jvm 层面去改
还有一块是 spring 导致的，因为 spring 的依赖注入，创建 bean 和扫描非常耗时，所以使得 java 应用启动更慢，这个目前业界的思路是把依赖注入放到编译构建阶段去做，对应的框架是 micronaut，但是这个要取代 spring 有点困难。

我猜你的 Nginx 没有设置到 upsteam 的 keepalive，所以主要耗时都在创建 tcp 连接上了

add_header Strict-Transport-Security "max-age=0;";

在服务端进行 pattern 匹配查找时有性能瓶颈，比如 springMVC 的默认实现就是逐个遍历，虽然可以改用 radixtree 优化，不过还是不如不用效率高，这个问题在接口数量较多，访问量比较大的情况下非常明显。所以我们现在规范都不建议用 RESTful，互联网行业很多方面都不会按照规范来做，搞工程的都是结果导向为主，还有个最典型的例子就是反范式设计

建立生态，让用户更依赖于他们提供的服务，你关注下阿里云某些产品就明白了

第一阶段是排查问题需要，对框架实现比较清楚的话有些问题很迅速就能定位到
第二阶段是要会用框架，光看官方文档你可能并不知道一些隐藏机巧和细节，源码了解过在有些场景下你可能有更好的解决方案
第三阶段是在框架基础下做扩展，有些需求就需要自己对框架的实现做扩展，这种情况也需要读懂框架相应功能的实现
第四阶段是改框架实现了，有些情况下开源框架无法满足一些特殊的需求，而又没有提供相应的扩展的话就需要自己去改对应的实现了，这种情况下不了解框架实现根本没法改

很多人在第一阶段就没兴趣看下去了，一般看到框架报错多数都是弃疗，有的至少还会去搜索引擎里找下解决方案，但是真正对自己解决问题和编程能力提升的还是得要啃源码才行

你想就靠单机解决这个问题的话就只能不用 spring 这套了，micronaut 那套就是为了优化这个问题，在编译时完成了依赖注入

充钱才能变强，买高速通道吧，不然肯定会受墙的影响