1.除非是 lambda，否则链式调用不要超过三个(但仍然推荐无复杂业务的链式调用，只不过要找到合适的位置斩开)；
2.对于可能要复用的变量，把他的逻辑从链式调用中取出来，在链式调用中使用引用；
3.对于可能会出错的环节，尤其像数据库相关的持久层操作一定要单独拎出来（数据库操作是程序出错最多的地方之一），一般情况下最好还要做异常捕获处理;
4.对于可能要被重构或抽取为方法的代码片段，慎用链式调用；

2 年 中配 t470P, 16G 内存，纯固态硬盘，应该再用个 5 年没问题，但我已经想换 MBP 了。。。

spring3.0 以前的注解会有入侵，但入侵不是因为注解而是对注解的业务处理对整个系统的耦合。在 spring 5.0 以上可以放心大胆的使用，set 方法一般还是搭配 xml 配置使用，xml 配置这东西能不用还是不用的好（但其功能的强大目前诸多配置仍旧比不上，这也是目前虽然在去 xml'化但仍然效果不甚理想的原因），set 代码本身也是极其无用的代码，代码这东西越少 bug 也就越少问题也更好定位。同时不推荐使用 AutoWired 进行 field 注入，尽量使用构造器注入。

天天给我埋坑的水平。。。

@Breadykid 那二楼方案是最佳的，先把 a 和 b 的数据从数据库里取出来，然后在程序里做计算，计算量大的话大可以优化，应该能控制在比较短的时间，这个方案的可行性主要看你从数据库里取 a 和 b 的数据要多久，要是这一步都超过 3s 那就没得玩。
PS：合理的方案还是加索引，不让加索引是因为加索引的时候会锁表，会影响表的正常使用(涉及到该表的业务全都没无法使用)，时间过长的情况下可能导致更严重的问题，整个数据库崩了都有可能（几率不大），加了索引后还要清理内存碎片对表进行分析优化，不然 CBO 可能不会及时得知变更，计算执行计划的成本的时候出现失误。和 DBA 商量商量趁哪天服务升级或夜深人静了服务没什么人使用的时候把索引给加上吧。

拆呗，不过也不知道你想咋样啊，你是怕单条 sql 超时了还是怕数据库 IO 时间过长压力过大，亦或是要求必须一条 sql
搞定啊，不知道你想干啥这工作也没法开展不是。如果只是怕数据库长时间 IO 压力太大，就拆呗，搞成几条单表查询，在代码里做计算。如果必须要一条 sql 搞定，你还不准在任何列上用索引，那几乎没啥太大优化空间了，语义上的优化对你这种简单 sql 帮助不大。

把基础复习牢固了，再去研究各种中间件。像 linux 的核心函数、多路复用模型、用户态内核态的切换、锁机制，通信模型里的 OSI 或者 TCP 四层模型，中间把 TCP 捋顺了，像你做微服务，通信是极其重要的一块，spring cloud 为什么用 http，dubbo 的 rpc 又是怎么实现的，没有 TCP 的相关知识做基础你是不可能研究透的。

加在从库上，这叫多级复制，正常就应该这么干，而不是让主库负责所有从库的数据变更。

乐观锁其实不是常规意义上的锁，在编程语言中一般通过 CAS 机制去实现，在 mysql 中比较有名的是 MVCC，需要使用乐观锁的场景一般是读多写少的情况，不然一直自旋可能效果还不如悲观锁。
PS：MVCC 其实只能保证读的一致性，mysql 保证写一致性其实最后还是靠的 next-key

博客，官方文档，上手撸一遍记笔记，看视频效率太低，除非对整个知识面毫无了解不然不建议

猜一下，a 字段只有两种取值,所以扫描行数过多,导致 CBO 放弃走索引执行全表扫描(联合索引 a,b 同理,因为 mysql 索引是最左匹配原则,联合索引 a,b 你可以想象成在 B+树的分支中挑选出为 a 的子树，然后再在当前范围中找出为 b 的子树,但在熟筛选 a 的时候这个执行计划就被 CBO 放弃了)。

一般情况下当前肯定是单机的快，不过考虑到后续用户量的攀升先做好读写分离也是不错的。
ps：but 大多数系统根本不会有数据量超过系统负荷的那一天，过早优化是万恶之源。

如果你枚举数据表的权限是为了业务隔离(不同业务涉及的表的权限独立)的话，那我认为是没有必要的，首先正常的业务场景哪怕很简单的业务也不可能仅仅涉及一张表,况且在实际业务业务本身和其它业务必然是有关联的，很难找到完全独立的表，所以这时候引入这种权限维护的工作量可能大于其所带来的安全性。
至于性能问题我觉得影响并不是很大，连接器本身在执行 sql 的时候就要进行权限验证，单次 IO 中的微小差异对于性能的影响微乎其微。
如果是按功能性划分，比如权限管理，其实这时候更应该做的是分库而不是在一个数据库实例然后根据用户去区分。
只要在很多业务模块不大不小时这个问题才比较有讨论的意义。

两个原因，快还有"懒"。快是指针存在虚拟机栈里，copy 起来速度奇快，"懒"是 JVM 的实现人员觉得没必要为 1%的场景去花费太多精力，有那空不如研究研究垃圾收集器啥的。。。不过听说新版本好像有这个意向？

看看自己 maven 的版本，语法是否过期了。
ps: 更严谨的做法是 install 到自己的本地仓库中,不使用 scope 和 systemPath ；
真实工程中搭个 maven 私服吧，一个工程连自己的私服都没有也太磕碜了。

生产用 8 吧,如果用户量不大而且稳定性要求不高(项目本身就是技术升级试点)可以试试 11,类型推断还不错

1.是有 http 连接池，适用于那种频繁和外界进行 http 接口交互的场景，但不是太多，因为 http 交互是真的慢；
2.除了连接池，http 庞杂的消息头中有一个 Connection，1.1 默认使用 keep-alive 即可保持长连接；

sql 没有限制长度。而且这种批量代码你也是敢写，都超过内存最大限制了，说明一条 sql 里有太多条记录，max allowed packet 的本义就是让你拆分 sql，试想你 10w 里面有一条失败了，如果是 mysql 默认的严格模式你这 10w 条就都白插了。而且长时间 IO 可能给系统带来非常大的负荷，不谈死锁什么的，很有可能还会超时(jdbc 的超时时间, net_write_timeout 的超时时间, connect_timeout 的超时时间你都要考虑)。。。请想清楚你要干什么兄弟