当前没必要引入时序数据库，less is more。
mysql 的话就按一分钟一条数据存储好了，如果后期数据量真的大起来，那就把近来七天的数据作为热点数据放到缓存里，过期时间设为七天，性能这方面完全不会有啥问题。

以前 mysql 性能差的一笔，各种 bug 乱飞，Oracle 则是著名的商业数据库，只要给钱一条龙服务 。现在 mysql 优化的越来越好了，从 5.7 开始性能又上了台阶，再加上免费开源所以越来越流行，但是大公司很少直接使用 mysql，基本上都是做二次开发，比如淘宝的 DRDS，美团的 DBproxy，Mycat

优点：
1.可以用来做分布式 id 更方便；
2. 具有唯一性, 可以让数据分布的更均匀；
3.字符串可以屏蔽掉 java 和 js 的一些数据类型差异，比如使用 Long 时如果数字过大会产生问题；
缺点：
1.太长了，主键会被用作聚簇索引，每次插入都要损耗不少性能，bigint 也才 8 个字节；
2.临近的数据没有相关性，不能有效利用局部性原理节省性能；
3.进行范围查询时会扫描过多的页，性能不好，这点和 2 类似。
优先推荐 Twitter 的 snowflake，但需要记得在最外层和前端交互时使用 String

@ilumer 索引覆盖是比较理想的情况，在实际中一般还要根据指针再去找聚簇索引获取整个行。我的疑惑点在于这些二级索引此时是如何处理的，如果是和其他行共有的二级索引也不可能直接删除吧？但是如果二级索引没有指向聚簇索引的记录了此时是不是会删除？删除是当前线程去操作还是异步 purge 线程去清理。

@vino2014zly 走了之后并找不到聚簇索引，不影响结果集，但是对性能会有影响。

作为开发人员，平时主要涉及的设计文档基本上是功能的详细设计和概要设计，对于它们的态度我认为是必须要有，工期紧也要先有概设，后期再补详设。但是在实际过程中不写文档的人比比皆是，但这是有问题的。正规的开发流程是先写概设然后找业务人员确认，然后写详设，叫上开发组长评审，最终把详设中的设计付诸代码，你管不了别人但你可以约束自己。

看本身学历还有心理期望。第一点是现在行行转 IT，没个本科学历都没人看，至于想进大厂，非科班 211 以下的希望就很渺茫了。第二点是你如果希望在培训班混几个月就年薪三十、四十万，我告诉你是不可能的，而且 IT 行业的起薪也不高，只是基本每年都有比较稳定的增长，但又面临一个天花板的问题，如果进不了大厂，很可能干个七八年也才 20 多 k，不过你要是觉得这样就够了就当我没说。

没有固定选型，中小项目使用 Eureka 的多，因为是默认集成，简单省事，直接堆业务代码就好了。大型项目的话各种 RPC 框架乱飞，dubbo 使用确实不少(淘宝内部是 hsf 居多，dubbo 本身使用较少)，但是其它如 grpc、thrift(可以跨语言)等也很多，还有自定义 RPC 协议的。

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 帮助不大。