1.数据库在初始化的时候没有进行连接的建立;
2.数据库连接报错了，只不过日志中没有输出；
3.日志输出了, 只不过被 console 屏蔽掉了;
4.console 没有屏蔽, 只是你没找到。

1.最简单的就是改 sql, 可以区分或者不区分大小写，比如 mybatis 中的 if 标签;
2.把生产环境设置为不区分大小写，但这样对于需要区分大小写的场景不太友好，需要对返回的结果集进行筛选;
3.对检索字段的字符进行全排列, 每个都去查一次, 这种方式唯一的好处就是不动数据库, 但是贻害无穷。

这个没有严格限定，在图中的 Null、Robot、NullRobot 都是开发自定义的接口或类，他们都是由 AppClassLoader 加载(Tomcat 比较特殊，有自定义的 WebClassLoader)，所以实际上它们必然由同一个 ClassLoader 加载(如果你没有自定义 ClassLoader 并使用其加载)

@wysnylc 正是为了强制注入，不然实际运行时注入失败还可以正常启动但业务代码还会报 npe, 当然在前期开发中使用 field 也无可厚非，相互之间可以独立，因为注入本身此时也变动的十分频繁，但当项目进入正常的迭代周期了，就不应该使用此种方式。构造器注入使得注入的服务不可变, 在实际的代码运行可以规避很多问题, 此外 5 个以上的依赖使得代码过于臃肿, 这时候应该考虑下设计模式了，为什么你会有这么多的服务要注入, 是不是拆分的不够细, 一个拥有 5 个注入以上的类大概率本身就很臃肿。当然在传统行业中业务本身确实及其复杂，但实际中仍不应该随意复用，举个极端的例子，我有一个列表查询, 我已经有了一个单个的查询，此时要不要复用是有待商榷的而不是无脑复用, 我见过有人为了复用竟然单个的查询也用列表查询查出来然后再取出来，完全罔顾了列表查询中不必要的操作和数据库更大的耗时。

又不是打游戏，办公电脑写代码的时候我觉得 thinkpad 的键盘敲起来是最舒服的。

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%的场景去花费太多精力，有那空不如研究研究垃圾收集器啥的。。。不过听说新版本好像有这个意向？